Associate streams to correct A10-NSP

[SoerenBusse]

Describe the bug
I'm not really sure if this is a bug or a feature request:

We're trying to do L2BSA traffic testing with a single access-node and two A10-NSP for a single carrier. Each subscriber's S-VLAN is dynamically assigned to an A10-NSP by the BNG.

We notice that the session itself (PPPoE or IPoE) establishes successfully, however the "Traffic Flows Verified" will never reach 100%.

When looking at a PCAP file, the stream traffic is sent through the wrong interface, while the session related traffic (PPP, DHCP) is sent through the right one:

The documentation states the following:

It is recommended to manually specify the corresponding a10nsp-interface in the access interface function, otherwise the first found a10nsp interface function is used. This interface is used for corresponding traffic streams where the a10nsp-interface is not explicitly defined, including the autogenerated session traffic.

However, a10nsp-interface cannot be set when the BNG itself decides to which A10-NSP a specific subscriber's s-vlan is assigned. How can something like this classic L2BSA scenario can be tested?

To Reproduce

Version (bngblaster -v):

Version: DEV
Compiler: GNU (11.4.0)
GIT:
  REF: release-0.9.25
  SHA: 4bc12475b4cc345ddb9f1041927ff67a6aff3a7d
IO Modes: packet_mmap_raw (default), packet_mmap, raw, dpdk

JSON configuration:
I tried to replicate this scenario using veth-interface-pairs.

{
   "interfaces":{
      "qdisc-bypass": true,
      "capture-include-streams": true,
      "a10nsp":[
         {
            "interface": "a10-sink-1",
            "qinq": true
         },
         {
            "interface": "a10-sink-2",
            "qinq": true
         }
      ],
      "access":[
         {
            "interface":"a10-source-1",
            "outer-vlan-min":128,
            "outer-vlan-max":4094,
            "inner-vlan-min":7,
            "inner-vlan-max":7,
            "qinq":true,
            "type":"ipoe",
            "stream-group-id":1,
            "ipv6":false
         }
      ]
   },
   "dhcp": {
      "enable": true
   },
   "sessions":{
      "count": 1
   },
   "streams":[
        {
            "name": "Downstream",
            "stream-group-id": 1,
            "type": "ipv4",
            "direction": "downstream",
            "pps": 10,
            "length": 1200
        }
   ]
}

Steps to reproduce the behavior:

1. Create veth-interfaces

ip link add dev a10-source-1 type veth peer name a10-sink-1
ip link add dev a10-source-2 type veth peer name a10-sink-2

2. Run BNGBlaster configuration

Expected behavior

BNGBlaster should associate each session to an A10-NSP and use this A10-NSP for sending traffic by default.

[GIC-de]

I added a new feature to the dev branch to dynamically change the A10NSP TX interface for downstream traffic streams, as required when A10NSP is dynamically selected.

This feature is disabled by default and operates only on interfaces without multithreading enabled.

{
   "interfaces":{
      "a10nsp-dynamic": true, <<<<<<<
      "a10nsp":[ ... ]
}

Please verify!

[GIC-de]

Fixed in 0.9.27, please confirm!

[SoerenBusse]

Hi @GIC-de,

that looks great. I will try and report back if everything works 👍.

Maybe some additional use-case to consider for this feature: We're using BNGBlaster to simulate high traffic usage for carriers which have multiple A10-NSPs. In our case I establish 50 sessions with 300M each, which will be then distributed dynamically to two A10-NSPs.

Before this new feature was implemented our current work around was to setup 50 sessions, check the associated A10-NSPs and then dynamically generate a list of access configs - one per S-VLAN - with the associated A10-NSP interface. I was easily able to push 20G with threading enabled, PPPoE on an epyc machine with Intel E810 cards, but low clock speed. I have to check how much our machine will handle without threading enabled to use this new feature.

What is the current challenge that threading is not supported and would make it more complex?

If it would be possible to use this dynamic A10-NSP feature with threading enabled in the future it would be a quite unique feature for traffic generators.

[GIC-de]

Reopened to investigate the feasibility of adding threading support.