Slowing down the rate of session creation per second

[knhojrm]

I'm working with a IPOE BNG that seems to require that the rate of sessions started and stopped needs to be reduced from the defaults. I've attempted to slow down the rate of creation with the configuration block below, but it doesn't seem to slow it down. The stop-rate does appear to function as expected though. Is there another way to slow down the rate of session creation per second?

		"sessions": {
        	"count": 1000,
        	"session-time": 0,
        	"max-outstanding": 1000,
        	"start-rate": 100,
        	"stop-rate": 100
    	},

Thanks. Great tool.

[GIC-de]

Start rate should work as well.

Internally, there is a job triggered every second which starts start-rate number of sessions but only up to max-outstanding session. Outstanding is a global value counting all sessions started but not established.

I would reduce the number of outstanding sessions here, typically I recommend to set outstanding to double of start-rate. Meaning start-rate 100 and max-outstanding 200.

What is the expected rate for your device under test? The rate should be around double. So if you expect 50 session per second, start-rate 100 with max-outstanding 200 should be fine.

[knhojrm]

I have experimented with "max-outstanding", but have experienced that the number of sessions created comes to the number in this field (very rapidly; as if there is no rate per second limit) and stops without resuming up to the full subscriber count subsequently. I'll continue to experiment with these setting a bit more though.

As for what is an expected rate for the device under test, that is what we are trying to determine via stress testing various configurations. This is part of our effort to find the limits of its capabilities. At least we know that it cannot keep up with the default settings that BNG Blaster comes with. Testing the same 1000 subscriber model with another tool we wrote in-house that goes slower works fine though.

[GIC-de]

I have some idea, if you start the BNG Blaster in interactive mode (-I) you should see a nice courses interface with some progress bar about established and outstanding. If subscriber does not become established from BNG Blaster point of view, it may end up in such situation. Can you try with interactive mode and maybe share screenshoot?

[knhojrm]

I started BNG Blaster with these CLI options:
bngblaster -C dhcpn1_example2.json -c 1000 -L test.log -l ip -J report.json -j sessions -j streams -P test.pcap -S run.sock -I

with this configuration:

{
        "interfaces": {
                "access": {
                        "interface": "ens224",
                        "type": "ipoe",
                        "vlan-mode": "N:1",
                        "outer-vlan-min": 0,
                        "outer-vlan-max": 0,
                        "inner-vlan-min": 0,
                        "inner-vlan-max": 0,
                        "ipv4": true,
                        "ipv6": false,
                        "dhcp": true,
                        "dhcpv6": false
                }
        },
        "sessions": {
                "count": 1000,
                "session-time": 0,
                "max-outstanding": 200,
                "start-rate": 100,
                "stop-rate": 100
        },
        "ipoe": {
        },
        "dhcp": {
                "enable": true,
                "timeout": 5,
                "retry": 30,
                "broadcast": true
        },
        "dhcpv6": {
                "enable": false,
                "timeout": 5,
                "retry": 30,
                "access-line": true,
                "rapid-commit": true,
                "ia-na": false,
                "ia-pd": true
        }

[GIC-de]

As expected, the sessions are not established (0 sessions established) but DHCPv4 is done, so reason could be that ARP failed. After DHCP session establishment, the Blaster will resolve the gateway MAC address via ARP and only after this has succeeded, session is marked as established.

You can easily capture with single session to check what's going on bngblaster -C config.json -c 1 -P test.pcap. You can also post capture here so I can check. Please also ensure that DHCP server is returning a default gateway.

[knhojrm]

Thanks for your insight about the ARP resolution requirement to establish the session with BNG Blaster. In observing the traffic between the elements, I can see the DHCP offers, requests and ACKs that include a gateway router IP address. All this happens over broadcast. I also see the subsequent ARP requests that goes out over broadcast. The ARP request is answered by the BNG interface itself via unicast, however this ARP reply does not make its way back to BNG Blaster in the user space it occupies. Similarly, if I don't set the DHCP to 'Broadcast', unicast traffic fails to get back to BNG Blaster and DHCP fails. My tcpdump of the interface facing BNG Blaster does see the ARP reply though.
==== Update ====
Problem solved! Since the machine running BNG Blaster is a virtual machine on a ESXi host. The vswitch in the ESXi host needed to be changed to promiscuous mode and everything works much better now.