Traffic streams topology

[marthin-vandyk]

Hi guys,

We have a good setup for bngblaster working to test all control plane protocols and their scale. Next up would be have a look at load-testing a proposed new BNG deployment, however the topology for the traffic streams eludes me so far.

Is it possible to have traffic streams both directions (tx/rx) without a 'network' type interface? Is it a requirement to have the streams 'loop' through the DUT and back to the bngblaster?

many thanks

[hannesgredler]

The notion of 'network' interface means that this is where DUT is connected to the core and BNG Blaster may simulate the core with IS-IS and BGP and or a more static setup with no routing protocols at all, albeit with a static 0/0 route from DUT to blaster.
The notion of an 'access' interface means that this is where DUT is connected to the subscriber side (e.g. OLT, MSAN, Eth-DSLAM)
So yes its absolutely possible to validate traffic streams in both directions. We typically test six streams (ipv4, ipv6, ipv6-delegated) up and downstream.

[marthin-vandyk]

Thanks Hannes,

Have been looking if I can't get traffic streams via the access (PPPoE) connected to an upstream http server and do downloads.

Understand clearer now, traffic streams assumes a topology where the DUT sits between the access and network interfaces of bngblaster.

thanks again

[marthin-vandyk]

The notion of 'network' interface means that this is where DUT is connected to the core and BNG Blaster may simulate the core with IS-IS and BGP and or a more static setup with no routing protocols at all, albeit with a static 0/0 route from DUT to blaster. The notion of an 'access' interface means that this is where DUT is connected to the subscriber side (e.g. OLT, MSAN, Eth-DSLAM) So yes its absolutely possible to validate traffic streams in both directions. We typically test six streams (ipv4, ipv6, ipv6-delegated) up and downstream.

Hi, have been trying further to get the traffic streams going.

• Got the BNG with a static pointing to bngblaster
• On the bngblaster interactive screen shows network interfaces are resolved, thus can see an ARP entry and ping the bngblaster interface
• Only testing a single PPPOE session till we've got the traffic streams scenario sorted, it shows as connected with configured protocols/services complete

Not seeing any traffic yet though? Here is the json config we are using at the moment ... any thoughts perhaps?

{
    "interfaces": {
	"network": {
            "interface": "bond0",
            "address": "100.127.6.6/30",
            "gateway": "100.127.6.5",
            "vlan": 99
        },
        "access": {
            "__comment__": "PPPoE Client",
            "interface": "bond0.702",
            "type": "pppoe",
            "stream-group-id": 1,
            "vlan-mode": "N:1"
        }
    },
    "streams": {
	    "name": "general",
	    "stream-group-id": 1,
	    "type": "ipv4",
	    "direction": "upstream",
	    "pps": 1000,
	    "network-interface": "bond0"
    },
    "pppoe": {
        "reconnect": true
    },
    "ppp": {
        "mru": 1492,
        "authentication": {
            "username": "test@bng2",
            "password": "password",
            "timeout": 3,
            "retry": 5,
            "authentication-protocol": "PAP"
        },
        "lcp": {
            "conf-request-timeout": 1,
            "conf-request-retry": 10,
            "keepalive-interval": 30,
            "keepalive-retry": 3
        },
        "ipcp": {
            "enable": true,
            "request-ip": true,
            "request-dns1": true,
            "request-dns2": true,
            "conf-request-timeout": 1,
            "conf-request-retry": 10
        }
    }
}

[marthin-vandyk]

Hi. Additionally used 'session-traffic' however that does not seem to give the desired result, but at least got it working. Looks like the pps configured gets divided amongst the total amount of sessions. Thus aiming for ~2,5Mbps per session needs about 3500 pps. Had to set 1750000 pps, but bngblaster did not reach that high? Excerpt from the report after the json.

How does bngblaster know to generate traffic according to the 'streams' config? The API/CLI result when using the json as shown:

marthin@oss3jhb:~$ sudo bngblaster-cli run.sock session-streams session-id 1
{
    "status": "ok",
    "code": 200,
    "session-streams": {
        "session-id": 1,
        "rx-packets": 16,
        "tx-packets": 23,
        "rx-accounting-packets": 4,
        "tx-accounting-packets": 0,
        "rx-pps": 0,
        "tx-pps": 1,
        "rx-bps-l2": 0,
        "tx-bps-l2": 560,
        "rx-mbps-l2": 0.0,
        "tx-mbps-l2": 0.00056,
        "streams": []
    }
}

json config:

{
    "interfaces": {
	"network": {
            "interface": "bond0",
            "address": "100.127.6.6/30",
            "gateway": "100.127.6.5",
            "vlan": 99
        },
        "access": {
            "__comment__": "PPPoE Client",
            "interface": "bond0.702",
            "type": "pppoe",
            "stream-group-id": 1,
            "vlan-mode": "N:1"
        }
    },
    "session-traffic": {
        "ipv4-pps": 1750000,
        "ipv6-pps": 0,
        "ipv6pd-pps": 0
    },
    "streams": {
	    "name": "BestEffort",
	    "stream-group-id": 1,
	    "type": "ipv4",
	    "direction": "both",
	    "pps": 1000,
	    "network-interface": "bond0"
    },
    "pppoe": {
        "reconnect": true
    },
    "ppp": {
        "mru": 1492,
        "authentication": {
            "username": "test@bng2",
            "password": "password",
            "timeout": 3,
            "retry": 5,
            "authentication-protocol": "PAP"
        },
        "lcp": {
            "conf-request-timeout": 1,
            "conf-request-retry": 10,
            "keepalive-interval": 30,
            "keepalive-retry": 3
        },
        "ipcp": {
            "enable": true,
            "request-ip": true,
            "request-dns1": true,
            "request-dns2": true,
            "conf-request-timeout": 1,
            "conf-request-retry": 10
        }
    }
}

Excerpt from report after using 'session-traffic' as per above:

Session Traffic (Global):
------------------------------------------------------------------------------
  Config:
    PPS IPv4:                46064
    PPS IPv6:                    0
    PPS IPv6PD:                  0

[GIC-de]

First install latest version 0.8.10.

I would propose following configuration meaning to remove all VLAN's from Linux and create them locally in BNG Blaster. It is also possible to do link-aggregation (bonding) with and without LACP natively from BNG Blaster (https://rtbrick.github.io/bngblaster/interfaces.html#link-aggregation-lag).

{
    "interfaces": {
        "network": {
            "interface": "bond0",
            "address": "100.127.6.6/30",
            "gateway": "100.127.6.5",
            "vlan": 99
        },
        "access": {
            "comment": "PPPoE Client",
            "interface": "bond0",
            "type": "pppoe",
            "stream-group-id": 1,
            "vlan-mode": "N:1",
            "outer-vlan": 702
        }
    },
    "session-traffic": {
        "ipv4-pps": 1
    },
    "streams": {
        "name": "general",
        "stream-group-id": 1,
        "type": "ipv4",
        "direction": "upstream",
        "pps": 1000
    },
    "pppoe": {
        "reconnect": true
    },
    "ppp": {
        "mru": 1492,
        "authentication": {
            "username": "test@bng2",
            "password": "password",
            "timeout": 3,
            "retry": 5,
            "protocol": "PAP"
        },
        "lcp": {
            "conf-request-timeout": 1,
            "conf-request-retry": 10,
            "keepalive-interval": 30,
            "keepalive-retry": 3
        },
        "ipcp": {
            "enable": true,
            "request-ip": true,
            "request-dns1": true,
            "request-dns2": true,
            "conf-request-timeout": 1,
            "conf-request-retry": 10
        }
    }
}

If you would like to test beyond 1M PPS, you should try with multithreading enabled but consider that a single traffic flow (instance of stream) is always handled by the same thread. Meaning you need multiple flows to achieve high bandwidth (https://rtbrick.github.io/bngblaster/interfaces.html#multithreaded-interfaces).

[marthin-vandyk]

Hi Christian,

Sincere thanks for the hints. We have tried those however no go yet. Also to note upgraded to the latest version available.

From the top:

1. To verify that forwarding is setup correctly, we have done session-traffic only for now. This works as expected. Note the additional threads and io-slots added as well.

{
    "interfaces": {
	"rx-threads": 22,
	"tx-threads": 22,
	"io-slots": 16384,
	"network": {
            "interface": "bond0",
            "address": "100.127.6.2/24",
            "gateway": "100.127.6.1",
            "vlan": 99
        },
        "access": {
            "interface": "bond0",
            "type": "pppoe",
            "stream-group-id": 1,
            "vlan-mode": "N:1",
            "outer-vlan": 702
        }
    },
    "session-traffic": {
            "ipv4-pps": 4500,
            "ipv6-pps": 0,
            "ipv6pd-pps": 0
    },
    "pppoe": {
        "reconnect": true
    },
    "ppp": {
        "mru": 1492,
        "authentication": {
            "username": "test@bng2",
            "password": "password",
            "timeout": 3,
            "retry": 5,
            "authentication-protocol": "PAP"
        },
        "lcp": {
            "conf-request-timeout": 1,
            "conf-request-retry": 10,
            "keepalive-interval": 30,
            "keepalive-retry": 3
        },
        "ipcp": {
            "enable": true,
            "request-ip": true,
            "request-dns1": true,
            "request-dns2": true,
            "conf-request-timeout": 1,
            "conf-request-retry": 10
        },
        "ip6cp": {
            "enable": false
        }
    },
    "dhcpv6": {
        "enable": false
    }
}

2. The session-traffic works as expected.
3. Using the below config, which is pretty much the same as your suggestion, only the threads and io-slots added, streams do not come up at all.

{
    "interfaces": {
	"rx-threads": 22,
	"tx-threads": 22,
	"io-slots": 16384,
	"network": {
            "interface": "bond0",
            "address": "100.127.6.2/24",
            "gateway": "100.127.6.1",
            "vlan": 99
        },
        "access": {
            "interface": "bond0",
            "type": "pppoe",
            "stream-group-id": 1,
            "vlan-mode": "N:1",
            "outer-vlan": 702
        }
    },
    "streams": {
	    "name": "general",
	    "stream-group-id": 1,
	    "type": "ipv4",
	    "direction": "both",
	    "pps": 1000,
	    "network-ipv4-address": "100.127.6.10"
    },
    "pppoe": {
        "reconnect": true
    },
    "ppp": {
        "mru": 1492,
        "authentication": {
            "username": "test@bng2",
            "password": "password",
            "timeout": 3,
            "retry": 5,
            "authentication-protocol": "PAP"
        },
        "lcp": {
            "conf-request-timeout": 1,
            "conf-request-retry": 10,
            "keepalive-interval": 30,
            "keepalive-retry": 3
        },
        "ipcp": {
            "enable": true,
            "request-ip": true,
            "request-dns1": true,
            "request-dns2": true,
            "conf-request-timeout": 1,
            "conf-request-retry": 10
        },
        "ip6cp": {
            "enable": false
        }
    },
    "dhcpv6": {
        "enable": false
    }
}

4. Variations to this config:

• without the network-ipv4-address in streams config, no change still no streams.
• used "network-interface": "bond0:99" in streams config, no change still no streams.

5. Tried splitting out the streams config into another file and included with -T, no change.

bngblaster -C wa3.json -T wa-streams.json -c 10 -S run.sock -I -l debug -L log

marthin@oss3jhb:~$ cat wa-streams.json

{
	"streams": {
		"name": "general",
		"stream-group-id": 1,
		"type": "ipv4",
		"direction": "both",
		"pps": 1000,
		"network-interface": "bond0:99"
	}
}

7. Added the debug logs from both the session-traffic and streams tests.
   session-traffic-log.txt
   streams-log.txt

Any further thoughts perhaps? Can show you a lot of output from the running bngblaster instance, however it will only serve to confirm my statements between session-traffic vs traffic streams. Let me know if there is additional output that would be useful.

many thanks Christian

[GIC-de]

One more note, 22 RX/TX threads per link is way too much! For up to 250K PPS you do not need threads at all. So for 1M PPS 4 threads should be fine, max 8 if you have low CPU performance.

[marthin-vandyk]

But your sessions are fully established? If you start BNG Blaster with interactive mode (-I) can you share the screenshot about session and stream progress.

Thanks Christian, have edited the previous reply post with more detail if there is anything that helps have a look.

Yes the sessions are fully established indicated by a green bar. Screenshot (from each screen on the interactive console) and log attached from the below command:

marthin@oss3jhb:~$ bngblaster -C wa3.json -T wa-streams.json -c 10 -S run.sock -I -l debug -L streams-log2.txt

streams-log2.txt

One more note, 22 RX/TX threads per link is way too much! For up to 250K PPS you do not need threads at all. So for 1M PPS 4 threads should be fine, max 8 if you have low CPU performance.

Sure thanks, will keep in mind!

[GIC-de]

Okay that helps, seems that no streams are created and reason is simple.

WRONG

 {
    "streams": {
	    "name": "BestEffort",
	    "stream-group-id": 1,
	    "type": "ipv4",
	    "direction": "both",
	    "pps": 1000,
	    "network-interface": "bond0"
    },
}

CORRECT

 {
    "streams": [
        {
	    "name": "BestEffort",
	    "stream-group-id": 1,
	    "type": "ipv4",
	    "direction": "both",
	    "pps": 1000,
	    "network-interface": "bond0:99"
        }
    ],
}

Streams must be an array ([]) of objects ({}). And network-interface must be bond0:99. But it's actually not needed if only one network interface exists. So it's even fine to remove network-interface from stream.

[marthin-vandyk]

Perfect thanks Christian!

All looking good now

[hannesgredler]

Might be a good idea to log an error if streams object is not an array.