rtbrick / bngblaster

The BNG Blaster is an open-source network tester for access and routing protocols.

RtBrick BNG Blaster

The open network tester for the IP networking community.

The BNG Blaster is an open-source network tester for access and routing protocols.

Originally developed as an access protocol tester, the BNG Blaster has undergone a significant evolution, transforming into a comprehensive network testing tool that now encompasses both access and routing functionalities. Its scope has expanded beyond the assessment of access protocols and now encompasses a broader spectrum, involving the evaluation of network functionalities at large. Contrary to its nomenclature, the BNG Blaster isn't restricted only to BNG (Broadband Network Gateway) testing.

It simulates a massive number of PPPoE and IPoE (DHCP) subscribers, encompassing IPTV and L2TP (LNS). Additionally, it supports all common routing protocols such as IS-IS, OSPF, LDP and BGP. This allows for comprehensive testing of both BNG and non-BNG routers, enabling end-to-end evaluations.

The included traffic generator serves various functions. It can be used to verify forwarding, conduct QoS tests, and measure convergence times. With the capacity to handle millions of separate tracked flows, it allows for thorough verification of every forwarding state within a complete internet routing table. Furthermore, it enables the transmission of traffic to each specific QoS queue present in service edge routers with detailed per-flow statistics like receive rate, loss or latency.

The BNG Blaster is used by leading network operators like Deutsche Telekom AG with their famous Access 4.0 project, network hard- and software vendors like RtBrick and many more.

A short introduction from DENOG15 can be found on YouTube.

Please check out the documentation for details.

This project will be actively maintained and further evolved by RtBrick. We are fully committed to building a project for the community and take issue and enhancement requests seriously. We are looking forward to any kind of contributions, new features, bug fixes, or tools. Even contributions to the documentation are more than welcome.

Our mission is to build better networks with open test suites.

License

BNG Blaster is licensed under the BSD 3-Clause License, which means that you are free to get and use it for commercial and non-commercial purposes as long as you fulfill its conditions.

See the LICENSE file for more details.

Copyright

Copyright (C) 2020-2024, RtBrick, Inc.

Contact

• Mail: [email protected]
• Chat: matrix.org #bngblaster

bngblaster's Issues

Expose collected data

Currently some data is only provided in forms of summaries, e.g. the IGMP stats. It would be great if the actual data used to calculate the summaries is exposed via some interface. This would allow a user to check and analyze the results themself.

Usecase 1: an in depth analysis of the data. For IGMP only min, max and avg are given. Let's consider these 2 different results:

Result List 1: [1, 1, 1, 1, 99, 99, 99, 99]
Result List 2: [1,50,50,50,50,50,50,99]

Both of them have a min of 1, max of 99, and an avg of 50. Yet these results can't be considered similar. To be able to identify the actual behavior a more fine grained analysis is necessary.

Usecase 2: Reprodicibility and comparability of tests:
This kind of depends on Usecase 1: Some finer grained analysis might be necessary to be able to compare test runs, especially in corner cases. A simple summary can hide details how multiple testruns are different from each other.

While this Feature Requests focuses on the IGMP data, all collected data should be exposed via some API.

wrong DHCPv6 session count after session flap

Configuration of IPV6CP interface identifier

Hello,

Is there any way to influence or configure the PPP IPv6 Interface identifier of BNG Blaster, which is negotiated during IPV6CP?
In my tests, the interface identifier seems to be always 00:00:00:00:00:00:00:00 for all sessions. Maybe the interface identifier could be based on the session number?

Regards,
John

Missing L2TPv2 LNS Hello Messages

The BNG Blaster acting as LNS is not sending hello messages as defined by RFC 2661 and therefore tunnel is not terminated (hanging) if LAC is not sending StopCCN.

fix GitHub release action warning

Warning see here: https://github.com/rtbrick/bngblaster/actions/runs/3379673696

https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Interface Locking

During start the BNG Blaster should lock all used interfaces by creating a file with the current PID. This allows to prevent other Blaster instances using the same interfaces in parallel.

Changing start source MAC address and DUID so that multiple instances of bngblaster can be run towards the same BNG

In order to scale test a BNG with a large number of dual-stack IPoE sessions, bngblaster may need to be run on more than one host if the CPU/network resouces of a single host are not enough. The host I am using supports up to about 25k sessions before packet loss occurs although the BNG supports up to 120k.

The BNG under test rejects sessions with duplicate MACs / DHCPv6 DUIDs so they need to be unique between bngblaster instances.

However, the src MAC address and IPv6 DUID appear to be hard coded such that two instances of bngblaster will use the same DUID/src MAC address as they interate over the session identifiers.

I have not found a way to do this by configuration option or agument when calling bngblaster. There seem to be two access interface configuration options i1_start and i2_start which I was hoping could be used to configure an offset for the session ID for multiple bngblaster instances. The documentation at

https://rtbrick.github.io/bngblaster/configuration/index.html#access-interfaces

defines i1_start and i2_start as Iterator for usage in strings {i1} and Iterator for usage in strings {i2} respectively. It's not too clear what they are to be used for. Changing them from their defaults of 1 to something else does not appear to change the MAC src address, IPv6 DUID or other DHCPv6 parameters based on the bngblaster session_id.

I have quickly tested that compiling a second bngblaster instance after changing session->client_mac[1] and session->dhcpv6_duid[3] from their defaults works.

--- a/code/bngblaster/src/bbl_session.c
+++ b/code/bngblaster/src/bbl_session.c
@@ -559,7 +559,7 @@ bbl_sessions_init(bbl_ctx_s *ctx)

         /* Set client OUI to locally administered */
         session->client_mac[0] = 0x02;
-        session->client_mac[1] = 0x00;
+        session->client_mac[1] = 0x01;
         session->client_mac[2] = 0x00;
         /* Use session identifier for remaining bytes */
         session->client_mac[3] = i>>16;
@@ -590,7 +590,7 @@ bbl_sessions_init(bbl_ctx_s *ctx)

         /* Set DHCPv6 DUID */
         session->dhcpv6_duid[1] = 3;
-        session->dhcpv6_duid[3] = 1;
+        session->dhcpv6_duid[3] = 2;
         memcpy(&session->dhcpv6_duid[4], session->client_mac, ETH_ADDR_LEN);

         /* Init string variables/iterators */

If there's not a current way of doing this in the configuration, I believe there is a good use-case to add it as a feature and in such a way that other access interface configuration options such as inner-vlan-min that increment with session identifier work as before.

Additional explanation for the configuration options i1_start and i2_start etc in the documentation would also probably be useful.

Service-name should be present in PADR

Describe the bug

PPPoE Servers should check existing Service-name in PARD packed as described in https://tools.ietf.org/html/rfc2516#section-5.3 , but BNGBlasted does not use Service-name tags.

DHCPv6 requests rejected by dhcplb: no vendor-class-data present in vendor class option

I am sending relayed bngblaster version 0.7.4 DHCPv6 requests through a dhcplb loadbalancer to a number of ISC Kea DHCP servers. The load balancer uses the dhcp library at https://github.com/insomniacslk/dhcp/

The code at https://github.com/insomniacslk/dhcp/blob/master/dhcpv6/option_vendorclass.go#L52 seems to assume at least one vendor-class-data field will always be present in the DHCPv6 vendor-class option 16 and if not, rejects the request with "at least one vendor class data is required":

E0504 18:31:41.869180 1 handler.go:243] Error encoding DHCPv6 packet: ParseOptVendorClass: at least one vendor class data is required 
E0504 18:31:41.869436 1 glog_logger.go:105] dhcp_server: , error_details: ParseOptVendorClass: at least one vendor class data is required, error_name: E_PARSE, latency_us: 188, server_is_rc: false, source_ip: 2001:db8:2009::1

Reading the RFC at https://www.rfc-editor.org/rfc/rfc8415.html#section-21.16 it says

[21.16] Vendor Class Option

   This option is used by a client to identify the vendor that
   manufactured the hardware on which the client is running.  The
   information contained in the data area of this option is contained in
   one or more opaque fields that identify details of the hardware
   configuration.  The format of the Vendor Class option is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      OPTION_VENDOR_CLASS      |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       enterprise-number                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                       vendor-class-data                       .
      .                             . . .                             .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 28: Vendor Class Option Format

      option-code          OPTION_VENDOR_CLASS (16).

      option-len           4 + length of vendor-class-data field.

      enterprise-number    The vendor's registered Enterprise Number as
                           maintained by IANA.  A 4-octet
                           field containing an unsigned integer.

      vendor-class-data    The hardware configuration of the node on
                           which the client is running.  A
                           variable-length field (4 octets less than the
                           value in the option-len field).

The RFC talks of "one of more" rather than "zero or more" vendor-class-data attributes. Other DHCP server implementations such as the ISC Kea server itself do accept a request with zero vendor-class-data objects but https://github.com/insomniacslk/dhcp/ appears not to.

From the excerpt of a wireshark packet export below, bngblaster appears not to include a vendor-class-data attribute in Vendor Class (option 16):

    Option Request
        Option: Option Request (6)
        Length: 2
        Value: 0017
        Requested Option code: DNS recursive name server (23)
    Vendor Class
        Option: Vendor Class (16)
        Length: 4
        Value: 0000c38a
        Enterprise ID: RtBrick Inc. (50058)
    Interface-Id
        Option: Interface-Id (18)
        Length: 23

As a test, if the vendor class option is commented out completely from the bngblaster source, the traffic is forwarded successfully by dhcplb without that error being generated and a packet capture shows option 16 no longer present.

--- a/code/bngblaster/src/bbl_protocols.c
+++ b/code/bngblaster/src/bbl_protocols.c
@@ -236,12 +236,12 @@ encode_dhcpv6(uint8_t *buf, uint16_t *len,
         BUMP_WRITE_BUFFER(buf, len, sizeof(uint16_t));
     }
     /* Vendor Class Option */
-    *(uint16_t*)buf = htobe16(DHCPV6_OPTION_VENDOR_CLASS);
-    BUMP_WRITE_BUFFER(buf, len, sizeof(uint16_t));
-    *(uint16_t*)buf = htobe16(sizeof(uint32_t));
-    BUMP_WRITE_BUFFER(buf, len, sizeof(uint16_t));
-    *(uint32_t*)buf = htobe32(RTBRICK);
-    BUMP_WRITE_BUFFER(buf, len, sizeof(uint32_t));
+//    *(uint16_t*)buf = htobe16(DHCPV6_OPTION_VENDOR_CLASS);
+//    BUMP_WRITE_BUFFER(buf, len, sizeof(uint16_t));
+//    *(uint16_t*)buf = htobe16(sizeof(uint32_t));
+//    BUMP_WRITE_BUFFER(buf, len, sizeof(uint16_t));
+//    *(uint32_t*)buf = htobe32(RTBRICK);
+//    BUMP_WRITE_BUFFER(buf, len, sizeof(uint32_t));

Comparing the behaviour to DHCPv4, it appears that bngblaster does not set DHCPv4 option 60 at all.

I can raise an issue at https://github.com/insomniacslk/dhcp/ suggesting that the RFC interpretation is too strict but would it be possible to include a vendor-class-data attribute (or the ability to not include the DHCPv6 vendor class option 16 at all)? I have not found a config option for this.

DHCP Request Message for RENEW Lease Msg is sending with Broadcast Address

Describe the bug
DHCP Request Message for RENEW Lease Msg is sending with Broadcast Address
A clear and concise description of what the bug is.

To Reproduce

Version (bngblaster -v):

JSON configuration:

{
    "interfaces": {
        "access": [
        {
            "interface": "l1-bng",
            "type": "ipoe",
            "vlan-mode": "N:1"
        }
     ]  
    },
    "dhcp": {
        "enable": true,
        "broadcast": true
    },
    "sessions": {
        "count": 1
    }
}

Steps to reproduce the behavior:

1. ...

Expected behavior
DHCP Request Message for RENEW Lease Msg should sent to selected dhcp-server
A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

Add config to switch between inner and outer VLAN Iterator

Add new configuration option to switch between outer and inner VLAN iteration. Per default VLAN ranges should be iterated by inner VLAN first and outer VLAN second. A new configuration option should be added to restore the current behavior of outer VLAN first and inner VLAN second.

BCM MD Support

Provide simple test mediation device for BCM QMC LI headers.

In Scaled scenario,either Subscribers destined traffic or from subscribers traffic, need tracking of ipv4/ipv6 traffic flows in a paged approach

Enhancement Request Description-:

In scaled scenario, Subscribers Traffic Statistics Tracking (based on IPv4/IPv6 Destination Address, IPv4/IPv6 Source Address, IPv4-ToS, IPv6-TC) by listing the traffic flows of scaled subscribers in a paged manner.

Probably exposing the traffic stats in a prometheus mode to Grafana Monitoring Tool to show in paged manner.

Additional context attached for reference:

Analogous reference attachment of Tester Tool where Subscriber Traffic Stats tracking is done in a scaled scenario.

Thanks,
Dharmendra

Crash if unknown UDP packet received

Fixed with a0cba9f.

Program received signal SIGSEGV, Segmentation fault.
0x000055555555debd in bbl_l2tp_session_hash (k=0x0) at /home/christian/bngblaster/src/bbl.c:629
629	    hash ^= *(uint32_t *)k;
(gdb) bt
#0  0x000055555555debd in bbl_l2tp_session_hash (k=0x0) at /home/christian/bngblaster/src/bbl.c:629
#1  0x000055555558eaa4 in nonzero_hash ()
#2  0x000055555558eb84 in hashtable2_search ()
#3  0x0000555555573005 in bbl_qmx_li_handler_rx (eth=0x55555579d760, qmx_li=0x0, interface=0x55555579e7c0) at /home/christian/bngblaster/src/bbl_li.c:69
#4  0x00005555555819fe in bbl_rx_handler_network (eth=0x55555579d760, interface=0x55555579e7c0) at /home/christian/bngblaster/src/bbl_rx.c:1861
#5  0x00005555555825ed in bbl_rx_job (timer=0x55555579f1d0) at /home/christian/bngblaster/src/bbl_rx.c:2022
#6  0x0000555555587a0b in timer_walk (root=0x55555579d260) at /home/christian/bngblaster/src/bbl_timer.c:516
#7  0x000055555555ff0a in main (argc=3, argv=0x7fffffffe4f8) at /home/christian/bngblaster/src/bbl.c:1338

Bngblaster session is not getting terminated with either Ctrl+c or 'terminate' command during longevity test

Describe the bug
Bngblaster session is running from past ~10hrs and When ctrl+c signal is sent to the running bngblaster session, session is not getting terminated.
Same results, when I used command 'terminate' using cli.

[00:38][Bhishma@srv2:~/bngblaster][main*]$date;sudo bngblaster -C ../srv2_zap_test_config_4.json -S test.socket;date
Fri Apr 9 00:38:42 IST 2021
Apr 09 00:38:43.065249 Getting MAC address 3c:fd:fe:c2:06:48 for interface ens2f0
Apr 09 00:38:43.137562 Add interface ens2f0
Apr 09 00:38:43.209226 Getting MAC address 3c:fd:fe:c2:06:49 for interface ens2f1
Apr 09 00:38:43.289576 Add interface ens2f1
Apr 09 00:38:43.292030 Opened control socket test.socket
Apr 09 00:38:44.403417 ALL SESSIONS ESTABLISHED
^CApr 09 09:10:02.636662 Received signal Interrupt (2), initiating teardown

^CApr 09 09:13:13.806373 Received signal Interrupt (2), initiating teardown
Apr 09 09:21:43.816481 Teardown request

Apr 09 09:26:44.015730 Teardown request

Apr 09 09:26:55.626354 Teardown request

---

Bhishma@srv2:/bngblaster$ sudo ./cli.py test.socket terminate
{
"status": "ok",
"code": 200,
"message": "terminate all sessions"
}
Bhishma@srv2:/bngblaster$ sudo ./cli.py test.socket terminate
{
"status": "ok",
"code": 200,
"message": "terminate all sessions"
}
Bhishma@srv2:/bngblaster$ sudo ./cli.py test.socket session-info
{
"status": "warning",
"code": 404,
"message": "session not found"
}
Bhishma@srv2:/bngblaster$

A clear and concise description of what the bug is.

To Reproduce

Version (bngblaster -v):

JSON configuration:

{
}

Steps to reproduce the behavior:

1. This is a longevity test

Expected behavior
bngblaster session must have terminated.

A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

DHCP failing to Nokia BNG: bngblaster sends DHCPDISCOVER to siaddr rather than broadcast address

DHCP failing to Nokia BNG: bngblaster sends DHCPDISCOVER to siaddr rather than broadcast address

We are testing bngblaster version 0.70 with IPoE sessions to a Nokia 7750 BNG (although the same behaviour/issue was also present using bngblaster version 0.6.6).

The BNG accepts the DHCP discover and replies with an offer which from the debugs, is received and processed by the BNG. The BNG however does not send a DHCPACK to bngblaster. The DHCPREQUESTs are retried by bngblaster:

# ./bngblaster -v
GIT:
  REF: main
  SHA: 2ba5a782d72b04f554a64c32cc4cc83c734e00e2
IO Modes: packet_mmap_raw (default), packet_mmap, raw

Apr 06 18:10:25.943151 Resolve network interfaces
Apr 06 18:10:25.943282 All network interfaces resolved
Apr 06 18:10:25.943320 DHCP (ID: 1) Start DHCP
Apr 06 18:10:25.948432 DHCP (ID: 1) DHCP-Discover send
Apr 06 18:10:26.032631 DHCP (ID: 1) DHCP-Offer received
Apr 06 18:10:26.035857 DHCP (ID: 1) DHCP-Request send
Apr 06 18:10:31.037336 DHCP (ID: 1) DHCP-Request send
Apr 06 18:10:36.041096 DHCP (ID: 1) DHCP-Request send
Apr 06 18:10:41.044076 DHCP (ID: 1) DHCP-Request send
Apr 06 18:10:46.048311 DHCP (ID: 1) DHCP-Request send
Apr 06 18:10:51.049583 DHCP (ID: 1) DHCP-Request send
Apr 06 18:10:56.050670 DHCP (ID: 1) DHCP-Request send
Apr 06 18:11:01.051205 DHCP (ID: 1) DHCP-Request send
Apr 06 18:11:06.056436 DHCP (ID: 1) DHCP-Request send
Apr 06 18:11:11.060699 DHCP (ID: 1) DHCP-Request send
Apr 06 18:11:16.060872 DHCP (ID: 1) Stop DHCP
Apr 06 18:11:16.060967 DHCP (ID: 1) Start DHCP
Apr 06 18:11:16.064548 DHCP (ID: 1) DHCP-Discover send
Apr 06 18:11:16.069751 DHCP (ID: 1) DHCP-Offer received
Apr 06 18:11:16.069832 DHCP (ID: 1) DHCP-Request send
Apr 06 18:11:21.074295 DHCP (ID: 1) DHCP-Request send

From a packet capture, the DHCP request is being sent by bngblaster to the siaddr in the received DHCPOFFER (the address 172.31.19.1 in the example below):

# tshark -T fields  -e ip.src -e ip.dst  -e _ws.col.Info  -e dhcp.option.dhcp_server_id -e dhcp.ip.server -E header=y -r bngblaster-0.70.pcap dhcp

ip.src  ip.dst  _ws.col.Info    dhcp.option.dhcp_server_id      dhcp.ip.server
0.0.0.0 255.255.255.255 DHCP Discover - Transaction ID 0xe4ffd06c               0.0.0.0
100.64.0.1      100.64.34.35    DHCP Offer    - Transaction ID 0xe4ffd06c       172.31.19.1     172.31.19.1
0.0.0.0 172.31.19.1     DHCP Request  - Transaction ID 0xe4ffd06c       172.31.19.1     0.0.0.0
0.0.0.0 172.31.19.1     DHCP Request  - Transaction ID 0xe4ffd06c       172.31.19.1     0.0.0.0
0.0.0.0 172.31.19.1     DHCP Request  - Transaction ID 0xe4ffd06c       172.31.19.1     0.0.0.0
0.0.0.0 172.31.19.1     DHCP Request  - Transaction ID 0xe4ffd06c       172.31.19.1     0.0.0.0

RFC 2131 section 3.1 says

the DHCPREQUEST message MUST use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as the original DHCPDISCOVER message.

RFC 2131 Section 2 defines the intrepretation of the siaddr as:

the address of the server to use in the next step of the client's bootstrap process. A DHCP server may return its own address in the 'siaddr' field, if the server is prepared to supply the next bootstrap service (e.g., delivery of an operating system executable image). A DHCP server always returns its own address in the 'server identifier' option.

The above seems to imply that the behaviour should be to send the request to the broadcast address and not to the siaddr.

If the source code is changed to send the DHCP Request to the broadcast address, the DHCP transaction is successful and the session is established.

Diff:

$ git diff
diff --git a/code/bngblaster/src/bbl_tx.c b/code/bngblaster/src/bbl_tx.c
index b2b7ea2..c7bdd50 100644
--- a/code/bngblaster/src/bbl_tx.c
+++ b/code/bngblaster/src/bbl_tx.c
@@ -1367,6 +1367,8 @@ bbl_encode_packet_dhcp(bbl_session_s *session) {
             dhcp.type = DHCP_MESSAGE_REQUEST;
             session->stats.dhcp_tx_request++;
             LOG(DHCP, "DHCP (ID: %u) DHCP-Request send\n", session->session_id);
+           eth.dst = (uint8_t*)broadcast_mac;
+            ipv4.dst = IPV4_BROADCAST;
             dhcp.option_address = true;
             dhcp.address = session->dhcp_address;
             dhcp.option_server_identifier = true;

Logs:

Apr 06 17:48:53.339912 Resolve network interfaces
Apr 06 17:48:53.340028 All network interfaces resolved
Apr 06 17:48:53.340059 DHCP (ID: 1) Start DHCP
Apr 06 17:48:53.341119 DHCP (ID: 1) DHCP-Discover send
Apr 06 17:48:53.428681 DHCP (ID: 1) DHCP-Offer received
Apr 06 17:48:53.433917 DHCP (ID: 1) DHCP-Request send
Apr 06 17:48:53.439157 DHCP (ID: 1) DHCP-ACK received
Apr 06 17:48:53.449498 ALL SESSIONS ESTABLISHED

Packet trace

# tshark -T fields  -e ip.src -e ip.dst  -e _ws.col.Info  -e dhcp.option.dhcp -e dhcp.option.dhcp_server_id -e dhcp.ip.server -E header=y -r ./bngblaster-0.70-broadcast.pcap dhcp
ip.src  ip.dst  _ws.col.Info    dhcp.option.dhcp        dhcp.option.dhcp_server_id      dhcp.ip.server
0.0.0.0 255.255.255.255 DHCP Discover - Transaction ID 0x31725964       1               0.0.0.0
100.64.0.1      100.64.36.129   DHCP Offer    - Transaction ID 0x31725964       2       172.31.19.1     172.31.19.1
0.0.0.0 255.255.255.255 DHCP Request  - Transaction ID 0x31725964       3       172.31.19.1     0.0.0.0
100.64.0.1      100.64.36.129   DHCP ACK      - Transaction ID 0x31725964       5       172.31.19.1     172.31.19.1

json:

{
    "interfaces": {
        "qdisc-bypass": true,
        "io-mode": "packet_mmap_raw",
         "network": {
         "interface": "ens160.2016",
         "address": "172.31.19.5",
         "gateway": "172.31.19.4"
        },
        "access": [
        {
            "interface": "ens224f1",
            "type": "ipoe",
            "qinq": "false",
            "outer-vlan-min": 2016,
            "outer-vlan-max": 2048,
            "inner-vlan-min": 2,
            "inner-vlan-max": 4094,
            "ipv4": true,
            "ipv6": false,
            "vlan-mode": "1:1"
        }
     ]
    },
    "sessions": {
        "count": 1,
        "session-time": 0,
        "max-outstanding": 16000,
        "start-rate": 1000,
        "stop-rate": 1000
    },
    "ipoe-line": {
            "ipv4": true,
            "arp-timeout": 5,
            "arp-interval": 300,
            "ipv6": false
    },
    "access-line": {
        "agent-remote-id": "ABCDEFGHIJKLMNOP",
        "agent-circuit-id": "0.0.0.0/0.0.0.0 eth 0:{session-global}"
    },
    "dhcp": {
        "enable": true
    },
    "dhcpv6": {
        "enable": true,
        "_enable": false,
        "rapid-commit": true
    },
   "session-traffic": {
        "ipv4-pps": 1,
        "ipv6-pps": 1,
        "ipv6pd-pps": 1
    }
}

Slow session set up

Describe the bug

When setting up around 100 sessions, the session set up is very slow;

Sessions 100 (100 PPPoE / 0 IPoE)
Established 51 [############################### ]
Outstanding 800 [############################################################]
Terminated 0 [ ]
Setup Time 13400 ms
Setup Rate 3.81 CPS (MIN: 3.42 AVG: 4.02 MAX: 4.57)
Flapped 823

If I run a PCAP, and filter for a particular vlan (one that hasn't yet auth'd successfully). I can see that PPPOE has established, and PPP LCP has begun. Following the PPP CHAP challenge from our BNG bngblaster immediately responds with a PPP LCP terminate request. We then get the Termination ACK, PPPOE terminates, and the entire process starts again.

We see that repeat over and over. Though eventually the other sessions get established.
Sessions 100 (100 PPPoE / 0 IPoE)
Established 61 [##################################### ]
Outstanding 800 [############################################################]
Terminated 0 [ ]
Setup Time 198400 ms
Setup Rate 0.31 CPS (MIN: 0.31 AVG: 2.57 MAX: 4.57)
Flapped 1000

We have tested the BNG with the same VLANs from a Spirent and set up of around 2000 sessions takes 10-20 seconds.

To Reproduce

Version (bngblaster -v):

Version: 0.7.1
IO Modes: packet_mmap_raw (default), packet_mmap, raw

JSON configuration:

{
    "interfaces": {
        "access": [
            {
                "interface": "enp3s0f0",
                "type": "pppoe",
		"outer-vlan": 4,
                "inner-vlan-min": 1,
                "inner-vlan-max": 4094,
                "authentication-protocol": "CHAP"
            }
        ]
    },
    "sessions": {
        "count": 100,
	"session-time": 0,
        "max-outstanding": 800,
        "start-rate": 400,
        "stop-rate": 400
    },
    "pppoe": {
	"service-name": "access",
        "reconnect": true,
        "discovery-timeout": 100,
        "discovery-retry": 1,
	"host-uniq": true,
        "vlan-priority": 6
    },
    "ppp": {
        "mru": 1492,
        "authentication": {
            "username": "mx10k3test{session-global}@zen",
            "password": "password",
            "timeout": 5,
            "retry": 30,
	    "protocol": "CHAP"
        },
        "lcp": {
            "conf-request-timeout": 5,
            "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
        }
    },
    "access-line": {
        "agent-remote-id": "DEU.RTBRICK.{session-global}",
        "agent-circuit-id": "0.0.0.0/0.0.0.0 eth 0:{session-global}",
        "rate-up": 1024,
        "rate-down": 16384

Steps to reproduce the behavior:

1. sudo bngblaster -C pppoe.json -I

Expected behavior

We'd expect the session setup to be quite quick. PPPOE set up completes in a few seconds, but we don't understand why bngblaster is sending the PPP LCP terminate requests to the BNG. If we wait long enough, all the sessions will eventually come up.

Screenshots

Access Interface Protocol Packet Stats:
ARP TX: 0 RX: 0
PADI TX: 902 RX: 0
PADO TX: 0 RX: 902
PADR TX: 902 RX: 0
PADS TX: 0 RX: 902
PADT TX: 839 RX: 63
LCP TX: 2986 RX: 2970
PAP TX: 0 RX: 0
CHAP TX: 64 RX: 966
IPCP TX: 192 RX: 192
IP6CP TX: 129 RX: 129
IGMP TX: 0 RX: 0
ICMP TX: 0 RX: 0
DHCP TX: 0 RX: 0
DHCPv6 TX: 0 RX: 0
ICMPv6 TX: 64 RX: 169
IPv4 Fragmented RX: 0

Access Interface Protocol Timeout Stats:
LCP Echo Request: 0
LCP Request: 0
IPCP Request: 0
IP6CP Request: 0
PAP: 0
CHAP: 0
DHCP Request: 0
DHCPv6 Request: 0

Additional context

Add any other context about the problem here.

BNG Blaster ACKs Multi Link PPP Option during LCP

Hello,

I'm running BNG Blaster against a LANCOM Systems Router which has an integrated PPPoE Server. The LANCOM PPPoE Server has support for Multi Link PPP which is not configurable and always active/advertised. BNG blaster seems to ACK the Multi Link Option in the LCP phase which results in the situation that the LANCOM PPPoE Server sends PPPoE frames with Multilink header and BNG Blaster does not. The BNG Blaster ACKs the Multilink MRRU and the Multilink Endpoint Discriminator (MAC) from the PPPoE Server.

The result is that the IPCP phase does not finish. BNG Blaster should not ACK unsupported options like Multilink PPP.

Best regards,
John

Typo estbalished instead of established

https://github.com/rtbrick/bngblaster/search?q=estbalished

Support for VLAN 0x88A8

Add support to change ethertype for VLAN from 0x8100 to 0x88A8.

Add Support for N:1 VLAN Mode

Add N:1 VLAN mode support (multiple subscribers per VLAN) for PPPoE and IPoE subscribers.

Add DHCP Support

Question about pps and i1-start

Hello all,

First of all thanks for this excellent project. Been using this for couple of days, and only have good words to describe the experience.

While going through the documentation, there are some items which are not very clear:

1. pps: PPS can be specified in two places: in { "streams": {} } and in { "session-traffic": {} }. Its not clear how they interact with each other and why its needed in two places.
2. i1-start, i1-step, i2-start and i2-step along with address-iter, gateway-iter and group-iter
3. monkey: What exactly happens when this option is enabled.

A brief explanation and a small example would go a long way to help understand this bits!

Thanks!

Need support of high-rate subscriber traffic in Mbps for scaled subscribers

Problem Statement:

1. In Scaled Subscribers Scenario say 18K Subscribers, BngBlaster(including Bngblaster infra) need to support
   high rate traffic per subscriber.

Description:

Lets take example of 18K Subscribers with per subscriber 250Kbps rate downstream & 250Kbps upstream.
18K * 500Kbps ==> 9000Kbps ==> 9Gbps approximately.

Thanks,
Dharmendra

RFC7084 compliant DHCPv6 behavior

Hey there,

I haven't configured DHCPv6 yet, however I stumpled across the following section in your FAQ:

The BNG Blaster expects an ICMPv6 router-advertisement with other-config flag before it starts sending DHCPv6 within a PPPoE session.

Personally I think that the RFC4861 is a little bit misleading here, because it wasn't written with DHCPv6 in mind, so it's unclear if DHCPv6-PD should be started by receiving the O-flag or the M-flag.

However RFC7084 states in WPD-4 the following:

WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement (RA) message.  Behavior of the
           CE router to use DHCPv6 prefix delegation when the CE router
           has not received any RA or received an RA with the M and the
           O bits set to zero is out of scope for this document.

So from my understanding DHCPv6-PD should also be instantiated when receiving the M-flag. Or is there a good reason not to do? :)

Fun Fact:
The obsoleted RFC6204 WPD-4 stated that DHCPv6-PD should always be initiated regardless if it receives a Router Advertisment with an O- or M-flag. So as soon as a CPE supports IPv6 it should request a prefix using DHCPv6 from the service provider. As far as a I rember is this still the default behavior of a Fritz!Box.

BNG Blaster not responding to PADO

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Running on Ubuntu 20.04.4, installed version is bngblaster-0.7.1-ubuntu-20.04_amd64.deb

Version (bngblaster -v):

Version: 0.7.1
IO Modes: packet_mmap_raw (default), packet_mmap, raw

JSON configuration:

{
    "interfaces": {
	"qdisc-bypass": false,
        "io-mode": "packet_mmap_raw",
        "access": [
            {
                "interface": "enp3s0f0",
                "type": "pppoe",
		"outer-vlan-min": 4,
                "outer-vlan-max": 4,
                "inner-vlan-min": 1,
                "inner-vlan-max": 4094,
                "authentication-protocol": "CHAP"
            }
        ]
    },
    "sessions": {
        "count": 10,
        "session-time": 0,
        "max-outstanding": 800,
        "start-rate": 400,
        "stop-rate": 400
    },
    "pppoe": {
        "reconnect": true,
        "discovery-timeout": 10,
        "discovery-retry": 10
    },
    "ppp": {
        "mru": 1492,
        "authentication": {
            "username": "mx10k3test{session-global}@zen",
            "password": "password",
            "timeout": 5,
            "retry": 30,
	    "protocol": "CHAP"
        },
        "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": true,
            "conf-request-timeout": 1,
            "conf-request-retry": 10
        }
    },
    "dhcpv6": {
        "enable": true,
        "rapid-commit": true
    },
    "access-line": {
        "agent-remote-id": "DEU.RTBRICK.{session-global}",
        "agent-circuit-id": "0.0.0.0/0.0.0.0 eth 0:{session-global}",
        "rate-up": 1024,
        "rate-down": 16384
    }
}

Steps to reproduce the behavior:

1. start BNG using "sudo bngblaster -C pppoe.json"

Expected behavior

I'd expect a PADR to be created. I do note that the PADI is double tagged on the PCAP, but the PADO appears single tagged, when PCAP'd using BNGBlaster, but when running the capture on the Arista switch (upstream from the server), the tagging is as expected

Arista PCAP

20:36:02.409429 02:00:00:00:00:01 > Broadcast, ethertype 802.1Q (0x8100), length 92: vlan 4, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype PPPoE D, PPPoE PADI [Service-Name] [Vendor-Specific "......0.0.0.0/0.0.0.0 eth 0:1..DEU.RTBRICK.1..........@."]

20:36:02.477526 f2:7c:c7:af:77:f3 > 02:00:00:00:00:01, ethertype 802.1Q (0x8100), length 76: vlan 4, p 6, ethertype 802.1Q, vlan 1, p 6, ethertype PPPoE D, PPPoE PADO [AC-Name "BNG3.THN-LON.LAB-RE0"] [Service-Name] [AC-Cookie "G~...9.{t. ..7]c"]

20:36:07.414196 02:00:00:00:00:01 > f2:7c:c7:af:77:f3, ethertype 802.1Q (0x8100), length 92: vlan 4, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype PPPoE D, PPPoE PADI [Service-Name] [Vendor-Specific "......0.0.0.0/0.0.0.0 eth 0:1..DEU.RTBRICK.1..........@."]

Support for NETMAP framework, to support other Oses that Linux.

Hi there, any change to allow netmap to be used for high speed access to NIC rings?

Add a cli command to fetch consolidated session-info

Currently, we can get the setup time/setup rate for the sessions from the report, once the instance is stopped

Report:

Sessions PPPoE: 10 IPoE: 0
Sessions established: 10/10
DHCPv6 sessions established: 10
Setup Time: 95 ms
Setup Rate: 105.26 CPS (MIN: 105.26 AVG: 105.26 MAX: 105.26)
Flapped: 0

Please add a bngblaster-cli command to fetch the same before stopping the instance

No verified traffic flows

Describe the bug

When running the bngblaster against our DUT, the sessions get setup and traffic is being sent and received ok. The bngblaster is being hosted on a server with one Intel 810-C NIC. However, the bngblaster does not appear to match the RX flows to generate the verified traffic flows view.

Sessions 1 (1 PPPoE / 0 IPoE)
Established 1 [############################################################]
...
Network Interface ( ens5f1 )
Tx Packets 0 | 0 PPS 0 Kbps
Rx Packets 8 | 0 PPS 0 Kbps
Tx Multicast Packets 0 | 0 PPS

Access Interface ( ens5f0 )
Tx Packets 17 | 0 PPS 0 Kbps
Rx Packets 14 | 0 PPS 0 Kbps

When saving the packets to the pcap file, we see that the packets look correctly formed, and the header is present as well.

Any clues on how to debug the issue further?

Version (`bngblaster -v`):
commit 8f8e53624a02d3f56631c99cca76ea0549c083ba (HEAD -> main, origin/main, origin/HEAD)
Merge: fd1a4dd 4276acc
Author: Christian Giese <[email protected]>
Date:   Fri Apr 8 15:16:17 2022 +0200

    Merge branch 'dev' into main

JSON configuration:

{
    "interfaces": {
        "tx_interval": 0.1,
        "rx_interval": 0.1,
        "capture-include-streams": true,
        "access": {
            "interface": "ens5f0",
            "outer-vlan-min": 400,
            "outer-vlan-max": 400,
            "inner-vlan-min": 2,
            "inner-vlan-max": 2000,
            "vlan-mode": "1:1",
            "authentication-protocol": "CHAP",
            "type": "pppoe",
            "stream-group-id": 1,
            "address": "192.168.0.1",
            "network-interface": "ens5f1"
        },
        "network": {
            "interface": "ens5f1",
            "address": "10.0.0.1"
        }
    },
    "sessions": {
        "count": 1,
        "session-time": 0,
        "max-outstanding": 1000,
        "start-rate": 400,
        "stop-rate": 400
    },
    "pppoe": {
        "service-name": "bisdn",
        "reconnect": true,
        "discovery-timeout": 3,
        "discovery-retry": 10
    },
    "ppp": {
        "mru": 1382,
        "authentication": {
                "username": "testing",
                "password": "testing"
        },
    "ipcp": {
                "enable": true,
                "request-ip": true,
                "request-dns1": false,
                "request-dns2": false
    },
    "ip6cp": {
        "enable": false
    }
    },
    "streams": [
        {
                "name": "BestEffort",
                "stream-group-id": 1,
                "type": "ipv4",
                "direction": "upstream",
                "pps": 1,
                "length": 1000,
                "destination-ipv4-address": "10.0.0.1",
                "network-interface": "ens5f1"
        }
    ]
}

ISIS hold timer for a neighbor is always ~60sec irrespective of the neighbor's hold time

Bug Description:

ISIS adjacency exists between a Router (R1) and a Bngblaster. On R1, hold timer is configured as 180sec. And from blaster it is expected that it announces the neighbor to be down after 180sec. But it is observed that it declares the neighbor to be down in approximately 60sec.

Version (bngblaster -v): Version: 0.7.9

JSON configuration:

    "interfaces": {
        "tx-interval": 1,
        "rx-interval": 1,
        "io-slots": 4096,
        "network": [
            {
                "interface": "SN-14-S4",
                "address": "131.0.0.2/24",
                "gateway": "131.0.0.1",
                "isis-instance-id": 1,
                "isis-level": 2
            }
        ]
    },
    "isis": [
        {
            "instance-id": 1,
            "area": [
                "49.0001/24"
            ],
            "system-id": "1921.6800.1007",
            "router-id": "192.168.1.7",
            "hostname": "BBL1",
            "hello-padding": true,
            "sr-base": 70000,
            "sr-range": 2000,
            "sr-node-sid": 7002,
            "teardown-time": 15,
            "lsp-tx-interval": 5,
            "lsp-tx-window-size": 5
                    }
                ]
            }

Steps to reproduce the behavior:

1. Configure 180sec hold time on R1
2. Make the ISIS neighbor down on R1

Expected behavior:

Bngblaster is expected to declare the neighbor to be down in 180sec

Bngblaster log for isis:

Jul 05 16:13:49.797809 ISIS L2 adjacency UP on interface SN-14-S4 
Jul 05 16:13:50.488119 Resolve network interfaces
Jul 05 16:13:50.488205 All network interfaces resolved
Jul 05 16:16:50.206916 ISIS RX L2-LSP PDU checksum error on interface SN-14-S4
Jul 05 16:17:49.502686 ISIS P2P-Hello timeout on interface SN-14-S4
Jul 05 16:17:49.502735 ISIS L2 adjacency DOWN on interface SN-14-S4 
Jul 05 16:21:20.883952 Received signal Interrupt (2), initiating teardown

Support ANCP

Hey there,

we really would like to use the BNGBlaster to test our L2BSA setup. However we currently use ANCP triggered subscriber interfaces on our Juniper BNGs as described there: https://www.juniper.net/documentation/us/en/software/junos/subscriber-mgmt-wholesale/topics/concept/ancp-layer2-bitstream-access-overview.html

So the access node sends an ANCP port-up message, gets the appropriate A10-NSP from the radius and forwards the subscriber traffic to it.

So to test like thousands of PPPoE client sessions we need to first trigger thousands of ANCP port-up messages. Currently I use your library https://github.com/GIC-de/PyANCP for it, which works absolutely great.

So currently we've to maintain two configurations and can do it only after each other. First trigger all ANCP port-up messages and afterwards establish PPPoE sessions using BNGBlaster. An build-in feature to send an ANCP port-up before establishing a PPPoE session would be a lot easier and would create a more realistic scenario.

Do you've any plans to support ANCP? Or is it already implemented and I didn't find it in the documentation.

Maybe you've an idea for a more elegant solution, like calling BNGBlaster from a Python script which also sends the ANCP port-up messages.

Thank you very much!

Any Sessions(PPPoE, L2BSA,IPoE, L2TP, ISIS, BGP) Uptime to be exposed

Description:

---

Any sessions bring up that we do using blaster, it can be pppoe/ipoe/l2bsa/l2tp/isis/bgp sessions.
We dont expose the session uptime in mins/hours.

Expectation:

---

A snapshot of the l2bsa(pppoe) 8K sessions are up from 4hours if we manually see. But we need to expose this in blaster on from how long the sessions are up.
NOTE: Snapshot is attached.

It would be good to expose the session uptime for all the protocols we support...!!

Thanks,
Dharmendra

No response to IPv6 unicast reachability check NSs

Our BNG under test has a feature where it tests IPoE subscriber host connectivity by using unicast IPv6 Neighbour Solicitations sent to the access interface address. If no NAs are received the BNG declares host connectivity is lost and tears down the IPoE session. These checks can be sent periodically or be event triggered.

In our use-case, each bngblaster session receives an IA_PD via DHCPv6 and has only a locally generated fe80::/10 link local address for the access interface between it and the BNG. No DHCPv6 IA_NA is assigned.

IPv6 NSs sent from the gateway address to the network interface are responded to successfully by bngblaster. However, NSs sent from the BNG to the bngblaster access interfaces (such as the packets fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 in the output below) appear in the pcap generated by bngblaster but are not responded to and the BNG brings the session down. The corresponding IPv4 host connectivity check which is an ARP request to the access interface address (assigned by DHCPv4) works fine. We are running bngblaster 0.7.8.

Expected behaviour is an IPv6 NA reply is sent by bngblaster from a source of an address assigned to the access interface from which the NS was received and with a destination of the source address of the received NS.

$ bngblaster -v
Version: DEV
Compiler: GNU (9.4.0)
GIT:
  REF: main
  SHA: 0abdeaf2eed9fc3b78b90c2dadf92548dfd7dccf
IO Modes: packet_mmap_raw (default), packet_mmap, raw

Jun 19 19:29:21.047988 Resolve network interfaces
Jun 19 19:29:21.048162 All network interfaces resolved
Jun 19 19:29:21.075023 IPv6 (ID: 1) DHCPv6 IA_PD prefix 2001:db8:3400:1800::/56
Jun 19 19:29:26.057986 IPv4 (ID: 1) address 100.66.0.11
Jun 19 19:29:26.060320 ALL SESSIONS ESTABLISHED

$ tshark -r ipv6-no-na.pcap icmpv6
    2   0.000000 2001:db8:2016::2 → ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:db8:2016::1 from 00:0c:29:de:e3:ef
    4   0.001257 2001:db8:2016::1 → 2001:db8:2016::2 ICMPv6 86 Neighbor Advertisement 2001:db8:2016::1 (rtr, sol, ovr) is at f0:0d:be:ef:5a:ba
    8   1.001388 2001:db8:2016::2 → ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:db8:2016::1 from 00:0c:29:de:e3:ef
   10   1.002855 2001:db8:2016::1 → 2001:db8:2016::2 ICMPv6 86 Neighbor Advertisement 2001:db8:2016::1 (rtr, sol, ovr) is at f0:0d:be:ef:5a:ba
   12   1.028243 fe80::ffff:ffff:ff00:1 → ff02::2      ICMPv6 70 Router Solicitation
   13   1.119500 fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 ICMPv6 82 Router Advertisement from f0:0d:be:ef:5b:32
   15   5.058367 2001:db8:2016::1 → 2001:db8:2016::2 ICMPv6 86 Neighbor Solicitation for 2001:db8:2016::2 from f0:0d:be:ef:5a:ba
   16   5.059570 2001:db8:2016::2 → 2001:db8:2016::1 ICMPv6 86 Neighbor Advertisement 2001:db8:2016::2 (sol, ovr) is at 00:0c:29:de:e3:ef
   26  60.659329 fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 ICMPv6 90 Neighbor Solicitation for fe80::ffff:ffff:ff00:1 from f0:0d:be:ef:5b:32
   31  90.659055 fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 ICMPv6 90 Neighbor Solicitation for fe80::ffff:ffff:ff00:1 from f0:0d:be:ef:5b:32
   34 120.658560 fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 ICMPv6 90 Neighbor Solicitation for fe80::ffff:ffff:ff00:1 from f0:0d:be:ef:5b:32
   37 150.658771 fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 ICMPv6 90 Neighbor Solicitation for fe80::ffff:ffff:ff00:1 from f0:0d:be:ef:5b:32   

IPv4 connectivity check:

   86 416.664069 f0:0d:be:ef:5b:32 → 02:00:00:00:00:01 ARP 60 Who has 100.66.0.11? Tell 100.66.0.1
   87 416.664144 02:00:00:00:00:01 → f0:0d:be:ef:5b:32 ARP 50 100.66.0.11 is at 02:00:00:00:00:01

Config:

{
    "interfaces": {
        "qdisc-bypass": true,
        "io-mode": "packet_mmap_raw",
         "network": {
         "interface": "ens160.2016",
         "address": "172.31.19.5",
         "gateway": "172.31.19.4",
        "capture-include-streams": false,
         "address-ipv6": "2001:db8:2016::2",
         "gateway-ipv6": "2001:db8:2016::1",
         "tx-interval": 1,
        "rx-interval": 1,
        "io-slots": 4096
        },
        "access": [
        {
            "interface": "ens224f1",
            "type": "ipoe",
            "qinq": "false",
            "outer-vlan-min": 2016,
            "outer-vlan-max": 2048,
            "inner-vlan-min": 2,
            "inner-vlan-max": 4094,
            "ipv4": true,
            "ipv6": true,
            "i1_start": "500",
            "i2_start": "1000",
            "vlan-mode": "1:1"
                    }
     ]
    },
    "sessions": {
        "count": 1,
        "session-time": 0,
        "max-outstanding": 16000,
        "start-rate": 1000,
        "stop-rate": 1000
    },
            "ipv4": true,
            "ipv6": true,
            "i1_start": "500",
            "i2_start": "1000",
            "vlan-mode": "1:1"
        }
     ]
    },
    "sessions": {
        "count": 1,
        "session-time": 0,
        "max-outstanding": 16000,
        "start-rate": 1000,
        "stop-rate": 1000
    },
    "ipoe": {
            "ipv4": true,
            "arp-timeout": 5,
            "arp-interval": 300,
                    "ipv6": true
    },
    "access-line": {
        "agent-remote-id": "ABCDEFGH{session-global}",
        "agent-circuit-id": "0.0.0.0/0.0.0.0 eth 0:{session-global}"
    },
    "dhcp": {
        "broadcast": true,
        "enable": true
    },
    "dhcpv6": {
        "enable": true,
        "rapid-commit": true
    },
   "session-traffic": {
        "ipv4-pps": 0,
        "ipv6pd-pps": 0
    }
}

A small amount of debugging verified that the condition at

bngblaster/code/bngblaster/src/bbl_rx.c

Line 576 in c75a723

} else if(icmpv6->type == IPV6_ICMPV6_NEIGHBOR_SOLICITATION) {

is passing when the IPv6 NSs are received.

Outer VLAN Restore

Add new configuration to force outer VLAN restore and add to documentation.

Segmentation Fault

Describe the bug

If i try to launch bngblaster with my config, i get a Segmentation Error.

To Reproduce

Version (bngblaster -v):

Version: 0.6.1

JSON configuration:

{
    "interfaces": {
        "access": [
        {
            "interface": "enx00e04cc53848",
            "type": "ipoe",
            "outer-vlan": 7,
            "vlan-mode": "N:1"
        }
     ]
    },
    "dhcp": {
        "enable": true
    },
"dhcpv6": {
        "enable": false
    },
    "access-line": {
        "agent-circuit-id": "0.0.0.0/0.0.0.0 eth 0:{session-global}"
    },
         "sessions": {
        "count": 100,
        "session-time": 0,
        "max-outstanding": 800,
        "start-rate": 400,
        "stop-rate": 400
    }
}

Steps to reproduce the behavior:
Unfortunately i dont't know how to reproduce this issue.

Expected behavior

I expected that the bngblaster starts like normally.

Additional context
Exception Dump:
Segmentation fault
*** Segmentation fault
Register dump:

RAX: 00000000ffffffff RBX: 0000555e7dabfe60 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 0000000000000000 R8 : 0000000000000000 R9 : 00007fa99d7c86ba
R10: 0000000000000004 R11: 00000000ffffffff R12: 00007ffe90b0d480
R13: 0000555e7dabd2d0 R14: 00007ffe90b0d500 R15: 0000555e7dac0fb0
RSP: 00007ffe90b0d448

RIP: 00007fa99dc79ad1 EFLAGS: 00010283

CS: 0033 FS: 0000 GS: 0000

Trap: 0000000e Error: 00000004 OldMask: 00000000 CR2: 00000000

FPUCW: 0000037f FPUSW: 00000000 TAG: 00000000
RIP: 00000000 RDP: 00000000

ST(0) 0000 0000000000000000 ST(1) 0000 0000000000000000
ST(2) 0000 0000000000000000 ST(3) 0000 0000000000000000
ST(4) 0000 0000000000000000 ST(5) 0000 0000000000000000
ST(6) 0000 0000000000000000 ST(7) 0000 0000000000000000
mxcsr: 1f80
XMM0: 00000000000000000000000000000000 XMM1: 00000000000000000000000000000000
XMM2: 00000000000000000000000000000000 XMM3: 00000000000000000000000000000000
XMM4: 00000000000000000000000000000000 XMM5: 00000000000000000000000000000000
XMM6: 00000000000000000000000000000000 XMM7: 00000000000000000000000000000000
XMM8: 00000000000000000000000000000000 XMM9: 00000000000000000000000000000000
XMM10: 00000000000000000000000000000000 XMM11: 00000000000000000000000000000000
XMM12: 00000000000000000000000000000000 XMM13: 00000000000000000000000000000000
XMM14: 00000000000000000000000000000000 XMM15: 00000000000000000000000000000000

Backtrace:
/lib/x86_64-linux-gnu/libc.so.6(+0x15fad1)[0x7fa99dc79ad1]
/lib/x86_64-linux-gnu/libc.so.6(__strdup+0xf)[0x7fa99dba7e3f]
bngblaster(+0x4facd)[0x555e7cbe8acd]
bngblaster(+0x5244b)[0x555e7cbeb44b]
bngblaster(+0x3d9b)[0x555e7cb9cd9b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7fa99db40d0a]
bngblaster(+0x755e)[0x555e7cba055e]

Memory map:

555e7cb99000-555e7cb9c000 r--p 00000000 103:05 261660 /usr/sbin/bngblaster
555e7cb9c000-555e7cbef000 r-xp 00003000 103:05 261660 /usr/sbin/bngblaster
555e7cbef000-555e7cbfe000 r--p 00056000 103:05 261660 /usr/sbin/bngblaster
555e7cbfe000-555e7cbff000 r--p 00064000 103:05 261660 /usr/sbin/bngblaster
555e7cbff000-555e7cc00000 rw-p 00065000 103:05 261660 /usr/sbin/bngblaster
555e7cc00000-555e7cc01000 rw-p 00000000 00:00 0
555e7dab9000-555e7dada000 rw-p 00000000 00:00 0 [heap]
7fa99d2ef000-7fa99d2f2000 r--p 00000000 103:05 261647 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7fa99d2f2000-7fa99d303000 r-xp 00003000 103:05 261647 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7fa99d303000-7fa99d307000 r--p 00014000 103:05 261647 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7fa99d307000-7fa99d308000 r--p 00017000 103:05 261647 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7fa99d308000-7fa99d309000 rw-p 00018000 103:05 261647 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7fa99d309000-7fa99d64f000 rw-p 00000000 00:00 0
7fa99d64f000-7fa99d650000 r--p 00000000 103:05 276862 /usr/lib/x86_64-linux-gnu/libdl-2.31.so
7fa99d650000-7fa99d652000 r-xp 00001000 103:05 276862 /usr/lib/x86_64-linux-gnu/libdl-2.31.so
7fa99d652000-7fa99d653000 r--p 00003000 103:05 276862 /usr/lib/x86_64-linux-gnu/libdl-2.31.so
7fa99d653000-7fa99d654000 r--p 00003000 103:05 276862 /usr/lib/x86_64-linux-gnu/libdl-2.31.so
7fa99d654000-7fa99d655000 rw-p 00004000 103:05 276862 /usr/lib/x86_64-linux-gnu/libdl-2.31.so
7fa99d655000-7fa99d65c000 r--p 00000000 103:05 276872 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
7fa99d65c000-7fa99d66c000 r-xp 00007000 103:05 276872 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
7fa99d66c000-7fa99d671000 r--p 00017000 103:05 276872 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
7fa99d671000-7fa99d672000 r--p 0001b000 103:05 276872 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
7fa99d672000-7fa99d673000 rw-p 0001c000 103:05 276872 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
7fa99d673000-7fa99d677000 rw-p 00000000 00:00 0
7fa99d677000-7fa99d686000 r--p 00000000 103:05 276863 /usr/lib/x86_64-linux-gnu/libm-2.31.so
7fa99d686000-7fa99d720000 r-xp 0000f000 103:05 276863 /usr/lib/x86_64-linux-gnu/libm-2.31.so
7fa99d720000-7fa99d7b9000 r--p 000a9000 103:05 276863 /usr/lib/x86_64-linux-gnu/libm-2.31.so
7fa99d7b9000-7fa99d7ba000 r--p 00141000 103:05 276863 /usr/lib/x86_64-linux-gnu/libm-2.31.so
7fa99d7ba000-7fa99d7bb000 rw-p 00142000 103:05 276863 /usr/lib/x86_64-linux-gnu/libm-2.31.so
7fa99d7bb000-7fa99d7bd000 rw-p 00000000 00:00 0
7fa99d7bd000-7fa99d7bf000 r--p 00000000 103:05 267884 /usr/lib/x86_64-linux-gnu/libjansson.so.4.13.0
7fa99d7bf000-7fa99d7c8000 r-xp 00002000 103:05 267884 /usr/lib/x86_64-linux-gnu/libjansson.so.4.13.0
7fa99d7c8000-7fa99d7cb000 r--p 0000b000 103:05 267884 /usr/lib/x86_64-linux-gnu/libjansson.so.4.13.0
7fa99d7cb000-7fa99d7cc000 r--p 0000d000 103:05 267884 /usr/lib/x86_64-linux-gnu/libjansson.so.4.13.0
7fa99d7cc000-7fa99d7cd000 rw-p 0000e000 103:05 267884 /usr/lib/x86_64-linux-gnu/libjansson.so.4.13.0
7fa99d7cd000-7fa99d853000 r--p 00000000 103:05 261667 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fa99d853000-7fa99d9fa000 r-xp 00086000 103:05 261667 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fa99d9fa000-7fa99da8a000 r--p 0022d000 103:05 261667 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fa99da8a000-7fa99da8b000 ---p 002bd000 103:05 261667 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fa99da8b000-7fa99dabb000 r--p 002bd000 103:05 261667 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fa99dabb000-7fa99dabd000 rw-p 002ed000 103:05 261667 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fa99dabd000-7fa99dac1000 rw-p 00000000 00:00 0
7fa99dac1000-7fa99dacf000 r--p 00000000 103:05 265153 /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2
7fa99dacf000-7fa99dadd000 r-xp 0000e000 103:05 265153 /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2
7fa99dadd000-7fa99daeb000 r--p 0001c000 103:05 265153 /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2
7fa99daeb000-7fa99daef000 r--p 00029000 103:05 265153 /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2
7fa99daef000-7fa99daf0000 rw-p 0002d000 103:05 265153 /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2
7fa99daf0000-7fa99daf8000 r--p 00000000 103:05 267891 /usr/lib/x86_64-linux-gnu/libncurses.so.6.2
7fa99daf8000-7fa99db11000 r-xp 00008000 103:05 267891 /usr/lib/x86_64-linux-gnu/libncurses.so.6.2
7fa99db11000-7fa99db17000 r--p 00021000 103:05 267891 /usr/lib/x86_64-linux-gnu/libncurses.so.6.2
7fa99db17000-7fa99db18000 ---p 00027000 103:05 267891 /usr/lib/x86_64-linux-gnu/libncurses.so.6.2
7fa99db18000-7fa99db19000 r--p 00027000 103:05 267891 /usr/lib/x86_64-linux-gnu/libncurses.so.6.2
7fa99db19000-7fa99db1a000 rw-p 00028000 103:05 267891 /usr/lib/x86_64-linux-gnu/libncurses.so.6.2
7fa99db1a000-7fa99db3f000 r--p 00000000 103:05 276861 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7fa99db3f000-7fa99dc8a000 r-xp 00025000 103:05 276861 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7fa99dc8a000-7fa99dcd4000 r--p 00170000 103:05 276861 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7fa99dcd4000-7fa99dcd5000 ---p 001ba000 103:05 276861 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7fa99dcd5000-7fa99dcd8000 r--p 001ba000 103:05 276861 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7fa99dcd8000-7fa99dcdb000 rw-p 001bd000 103:05 276861 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7fa99dcdb000-7fa99dcdf000 rw-p 00000000 00:00 0
7fa99dce5000-7fa99dce6000 r--p 00000000 103:05 276859 /usr/lib/x86_64-linux-gnu/libSegFault.so
7fa99dce6000-7fa99dce9000 r-xp 00001000 103:05 276859 /usr/lib/x86_64-linux-gnu/libSegFault.so
7fa99dce9000-7fa99dcea000 r--p 00004000 103:05 276859 /usr/lib/x86_64-linux-gnu/libSegFault.so
7fa99dcea000-7fa99dceb000 r--p 00004000 103:05 276859 /usr/lib/x86_64-linux-gnu/libSegFault.so
7fa99dceb000-7fa99dcec000 rw-p 00005000 103:05 276859 /usr/lib/x86_64-linux-gnu/libSegFault.so
7fa99dcec000-7fa99dcee000 rw-p 00000000 00:00 0
7fa99dcee000-7fa99dcef000 r--p 00000000 103:05 276857 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7fa99dcef000-7fa99dd0f000 r-xp 00001000 103:05 276857 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7fa99dd0f000-7fa99dd17000 r--p 00021000 103:05 276857 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7fa99dd18000-7fa99dd19000 r--p 00029000 103:05 276857 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7fa99dd19000-7fa99dd1a000 rw-p 0002a000 103:05 276857 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7fa99dd1a000-7fa99dd1b000 rw-p 00000000 00:00 0
7ffe90aed000-7ffe90b0e000 rw-p 00000000 00:00 0 [stack]
7ffe90b9a000-7ffe90b9e000 r--p 00000000 00:00 0 [vvar]
7ffe90b9e000-7ffe90ba0000 r-xp 00000000 00:00 0 [vdso]

Sessions established count is zero when we bring up only with dhcpv6 and Traffic not starting

Describe the bug
Sessions established count is zero when we bring up only with dhcpv6 and Traffic not starting
A clear and concise description of what the bug is.
Sessions established count is zero when we bring up only with dhcpv6 and Traffic not starting
To Reproduce
1] Bring up only ipoe dhcpv6
Version (bngblaster -v):
Latest bngblaster Version

JSON configuration:

{
    "interfaces": {
        "tx-interval": 1,
        "rx-interval": 1,
        "io-slots": 4096,
        "network": {
            "interface": "br-spine1-0",
            "address": "131.0.0.2",
            "gateway": "131.0.0.1",
            "address-ipv6": "fc66:1337:7331::2",
            "gateway-ipv6": "fc66:1337:7331::1"
        },	
        "access": [
        {
            "interface": "leaf1-1",
            "type": "ipoe",
            "outer-vlan-min": 1201,
            "outer-vlan-max": 1300,
            "inner-vlan-min": 1001,
            "inner-vlan-max": 1100
        }
     ]  
    },
    "sessions": {
        "count": 5,
        "session-time": 0,
        "max-outstanding": 800,
        "start-rate": 400,
        "stop-rate": 100
    },
    "access-line": {
        "agent-remote-id": "DEU.RTBRICK.{session-global}",
        "agent-circuit-id": "0.0.0.0/0.0.0.0 eth 0:{session-global}",
        "rate-up": 2000,
        "rate-down": 16384,
        "dsl-type": 5
    },
    "dhcp": {
        "enable": false
    },
    "dhcpv6": {
        "enable": true
    },
    "session-traffic": {
        "autostart": true,
        "ipv6-pps": 1,
        "ipv6pd-pps": 1
    }
}

Steps to reproduce the behavior:

1. ...

Expected behavior
Sessions established count should not be zero and traffic should work
A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

support to set session traffic upstreams source IP

Add support to overwrite the source IP for upstream session traffic to allow testing RPF functionality for IPv4 and IPv6.

Multithreaded RX

This issue tracks all changes related to support multithreaded packet receive (RX) in order to increase scaling.

IPOE DHCPv6 session not getting establised if IA_PD is null

when IA_PD is NULL as only IA_NA is configured in the BNG, the sessions are not getting established. Please fix this

BNG Blaster not working on ubuntu 20.04

The ubuntu 20.04 release versions from GitHub are broken.

Bngblaster sending multiple ARP requests even after the ARP reply in case of DHCPv4

During the DHCPv4 negotiation, Bngblaster is sending out the ARP for the gateway after the OFFER message as expected. Gateway is replying to the second ARP request.
But could see in almost all cases, bngblaster is sending a third ARP request. Please check.

config:

{
    "interfaces": {
        "access": [
           {
            "interface": "S1L1I1",
            "outer-vlan-min": 1,
            "outer-vlan-max": 3999,
            "type": "ipoe"
           }
	 ],
         "network": {
            "interface": "LNS2",
            "address": "121.0.0.2",
            "gateway": "121.0.0.1"
	 }
    },
    "dhcp": {
        "enable": true
    },
    "sessions": {
        "count": 1
    }
}

pcap:

A10NSP DHCPv4/v6 Support

Add support for DHCPv4 and DHCPv6 on A10NSP interfaces.

• DHCPv4
• ARP
• DHCPv6
• ICMPv6 ND

PR: #88
Branch: https://github.com/rtbrick/bngblaster/tree/a10nsp_dhcp

L2TP unhide with padding not working

Describe the bug

I'm using a Juniper MX with PPPoE PAP as LAC and BNGBlaster as LNS, but I get the error message, that AVP 33 cannot be decrypted. This seems to be related to this code:

bngblaster/code/bngblaster/src/bbl_l2tp_avp.c

Line 207 in 2ba5a78

if (len + 2 > avp->len) {

len contains the Original Attribute length. However, the AVP length must not be len + 2, because there can be a random padding as specified in RFC2661 https://www.rfc-editor.org/rfc/rfc2661.html#section-4.3. The issue occurs because the Juniper MX sends the AVP 33 with padding.

DHCPv6 - Is dhcpv6 working on v5.5?

bng.txt
Hi there,
Quick question, we have a bng here configured with Dual-stack PPPoE. BNG configuration is working as we some other test clients with v4/v6 connected. Bngblaster, is also working but only for v4. DHCPv6 seems to be stuck in init, but doing a packet capture on the host I cannot see any v6 request generated.

Also, seems that debug/logging not working (or I'm doing something wrong, most probably).

The release we are using is 5.5, using the debian pre-build package.

Version: 0.5.5
IO Modes: packet_mmap_raw (default), packet_mmap, raw

root@bng-tg1:/home/smartinez# bngblaster-cli /var/run/bng session-info session-id 1 { "status": "ok", "code": 200, "session-info": { "type": "pppoe", "session-id": 1, "session-state": "Established", "interface": "enp0s5f2", "outer-vlan": 100, "inner-vlan": 0, "mac": "02:00:00:00:00:01", "username": "test", "lcp-state": "Opened", "ipcp-state": "Opened", "ip6cp-state": "Opened", "ipv4-address": "203.0.13.83", "dhcpv6-state": "Init", "tx-packets": 16, "rx-packets": 13, "rx-fragmented-packets": 0 } }

DHCPv6 LDRA behaviour

Currently it is possible to set the interface-id and remote-id via access-line for DHCPv6, but this results in adding option17/38 to the normal DHCPv6 packet.

I would think that in most situations option17/38 are added by an LDRA-agent, and the original DHCP-request is encapsulated in the relay-message option (option9). Currently our Juniper BRAS is rejecting the SOLICITs, because the packet is not constructed as a non relay-packet.
Reference: https://datatracker.ietf.org/doc/html/rfc6221

In our set-up our L2 switches act as LDRA agent and add option17/18 information, which works fine. Unfortunately we currently cannot mimic this behaviour with bngblaster.

Would it be possible to add DHCPv6 LDRA-emulation to BNGblaster?

Clear Counter Command

Add new control socket commands to reset the session traffic, interface packet and protocol counters.

GitHub Pages for Documentation

Wrong IGMP Delay Measurements

IGMP delay calculation is wrong.

IGMP Zapping Stats:
  Join Delay:
    MIN: 59 ms
    AVG: 27334087 ms
    MAX: 4294967295 ms  <<<<<<<<<<<<< this is UINT32_MAX
  Leave Delay:
    MIN: 143 ms
    AVG: 10856 ms
    MAX: 44202 ms
  Multicast:
    Overlap: 2573314 packets
    Not Received: 0

Add L2TPv2 LNS Support

Add support to to emulate L2TPv2 LNS servers on the network interface to test the BNG L2TP LAC functionality.

Linking fails with GCC version 10

Describe the bug

When trying to compile bngblaster from source on a Debian bullseye, the linking fails with the following errors:

/usr/bin/ld: CMakeFiles/bngblaster.dir/src/bbl_a10nsp.c.o (symbol from plugin): in function `log_win':
(.text+0x0): multiple definition of `log_win'; CMakeFiles/bngblaster.dir/src/bbl.c.o (symbol from plugin):(.text+0x0): first defined here
/usr/bin/ld: CMakeFiles/bngblaster.dir/src/bbl_a10nsp.c.o (symbol from plugin): in function `log_win':
(.text+0x0): multiple definition of `stats_win'; CMakeFiles/bngblaster.dir/src/bbl.c.o (symbol from plugin):(.text+0x0): first defined here

To Reproduce

# Debian Bullseye 11.3
mkdir build && cd build
cmake /root/bngblaster-0.7.2 -DCMAKE_BUILD_TYPE=Release
cmake --build . --config Release

Workaround
When using gcc-9 everything works fine.

apt install gcc-9
cmake /root/bngblaster-0.7.2 -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=/usr/bin/gcc-9
cmake --build . --config Release