Question about pps and i1-start about bngblaster HOT 6 CLOSED

Assuming config below:

   "session-traffic": {
        "ipv4-pps": 1,
        "ipv6-pps": 1,
        "ipv6pd-pps": 1
    },
    "streams": [
        {
            "stream-group-id": 1,
            "name": "S1",
            "type": "ipv4",
            "direction": "both",
            "priority": 256,
            "length": 256,
            "pps": 10
        }
    ]

Each session would have 6 session traffic flows with 3 PPS per direction (up/down) plus two additional streams (S1 up/down) with 10 PPS each, resulting in 13 PPS per direction (up/down).

Yes the last username would be [email protected], my fault.

Yes the address iterator will span the octet boundary.

from bngblaster.

Hi @xuoguoto,

thanks for your valuable feedback!

PPS

If session traffic is enabled, the BNG Blaster automatically generates bidirectional traffic streams between the dynamically learned access client addresses and the selected network interface. This is used to quickly verify if forwarding is working correctly.

Example:
Assuming a PPPoE session which negotiates an IPv4 and IPv6 address via PPP NCP and a delegated IPv6 prefix via DHCPv6 and the following configuration.

{
    "session-traffic": {
        "autostart": true,
        "ipv4-pps": 1,
        "ipv6-pps": 1,
        "ipv6pd-pps": 1,
    }
}

This causes the BNG Blaster to generate 6 traffic streams for IPv4, IPv6 and IPv6PD (delegated prefix) in both directions (up/down), each with 1 packet per second (3 PPS up/3PPS down). Now you could configure additional traffic streams in advance with their own rate in PPS.

Iterator

The iterators i1 and i2 are applicable to the following configuration attributes:

• username
• password
• agent-circuit-id
• agent-remote-id
• cfm-ma-name

Assuming we have "i1-start": 100, "i1-step": 2 and "username": "user{i1}@test.de", the result will be:

• [email protected]
• [email protected]
• [email protected]

The address iterators are applicable to static IP addresses, to allow defining the step between each session created.

Monkey

The configuration monkey enables the new experimental monkey testing feature, currently supported for PPPoE only. I plan to add a dedicated chapter here in future.

If enabled, sessions will randomly flap by different reasons. This is used for BNG robustness tests. I found already some BNG bugs by setting up max PPPoE sessions with monkey enabled and leave this flapping for a few hours. After test has stopped, the BNG should fully recover, no crash, no hanging sessions, no memory leaks, ...

from bngblaster.

Thanks @GIC-de for detailed explanation, If I may can I ask couple of followup questions?

{
    "session-traffic": {
        "autostart": true,
        "ipv4-pps": 1,
        "ipv6-pps": 1,
        "ipv6pd-pps": 1,
    }
}

This causes the BNG Blaster to generate 6 traffic streams for IPv4, IPv6 and IPv6PD (delegated prefix) in both directions (up/down), each with 1 packet per second (3 PPS up/3PPS down). Now you could configure additional traffic streams in advance with their own rate in PPS.

This part is understood, I can individually control each traffic stream's PPS.

But if the config contains session-traffic and streams how will the total PPS be computed? For example in the config below:

   "session-traffic": {
        "ipv4-pps": 1,
        "ipv6-pps": 1,
        "ipv6pd-pps": 1
    },
    "streams": [
        {
            "stream-group-id": 1,
            "name": "S1",
            "type": "ipv4",
            "direction": "both",
            "priority": 256,
            "length": 256,
            "pps": 10
        }
    ]

Assuming we have "i1-start": 100, "i1-step": 2 and "username": "user{i1}@test.de", the result will be:

• [email protected]
• [email protected]
• [email protected]

Shouldn't the last value be [email protected]?

The address iterators are applicable to static IP addresses, to allow defining the step between each session created.

Will the address iterators span the octet boundary in the case of IPv4? It would be great if an example for IP address is given.

If enabled, sessions will randomly flap by different reasons. This is used for BNG robustness tests. I found already some BNG bugs by setting up max PPPoE sessions with monkey enabled and leave this flapping for a few hours. After test has stopped, the BNG should fully recover, no crash, no hanging sessions, no memory leaks, ...

Yes, this is very useful for testing robustness!

Thanks for your time and patience in answering these questions!

from bngblaster.

Sorry for bothering again, but I am playing with address-iter and its not quite working the way I thought it will work. In the sample config I am expecting bngblaster to create 4 sessions with IP address 172.164.165.8 - 172.164.165.12, but its only creating one. The IP address of the created session is 172.164.165.8. What could be wrong here?

{   
    "interfaces": {
        "network": {
            "interface": "enp1s0f0",
            "address": "192.168.180.163",
            "gateway": "192.168.180.164"
        },
        "access": [
            {   
                "interface": "enp1s0f1",
                "type": "ipoe",
                "vlan-mode": "N:1",
                "outer-vlan-min": 70,
                "outer-vlan-max": 70,
                "address": "172.164.165.8",
                "address-iter": "0.0.0.4",
                "gateway": "172.164.165.1"
            }
        ]
    },
    "dhcp": {
        "enable": false
    },
    "dhcpv6": {
        "enable": false
    },
    "ipoe": {
        "ipv6": false
    },
    "session-traffic": {
        "ipv4-pps": 1
    }
}

Blaster screen shows:

Sessions               1 (0 PPPoE / 1 IPoE)  
  Established          1 [############################################################]
  Outstanding          0 [                                                            ]
  Terminated           0 [                                                            ]
  Setup Time           2 ms
  Setup Rate      500.00 CPS (MIN: 500.00 AVG: 500.00 MAX: 500.00)
  Flapped              0

Traffic Flows Verified
  Session            2/2 [############################################################]

from bngblaster.

The number of sessions is default set to one and must be specified in the section sessions:
https://rtbrick.github.io/bngblaster/configuration/index.html#sessions

{
    "sessions": {
        "count": 4
    }
}

This value can be also dynamically specified with the command line argument -c 4. The command line argument will have priority over the configuration.

Using the 172.164.165.8with iterator 0.0.0.1 results in: 172.164.165.8, 172.164.165.9, 172.164.165.10, ...

The iterator 0.0.0.4would result in: 172.164.165.8, 172.164.165.12, 172.164.165.16, ...

Meaning the iterator defines the step between two sessions IP addresses.

from bngblaster.

Thank you. I have made the changes as suggested and now it's working as expected. Resolving this ticket as all questions in this thread has been answer

from bngblaster.