IPv6 streams not being received

[marthin-vandyk]

Hi all,

We have been using bngblaster for various BNG tests and so far everything has worked as expected. Other than some initial questions regarding syntax there has been no issues.

On a new router we have the same bngblaster config and setup as before, however for some reason we are not getting the IPv6 streams received.

From the DUT router itself we can ping the subscriber assigned v6 address, which is the same address we can see in the streams packet capture.

Also from the DUT router we can ping the network address on bngblaster.

Any thoughts or hints welcome :)

Have drawn out our scenario with some screenshots annotated, please see attached 'Whiteboard.png'.

Have also attached a pcap from bngblaster and a debug log from '-l debug -L debug_log.txt':
streams.pcap.zip
debug_log.txt

Manual Test

We have done a normal manual test where we are pinging from the network side (network interface in a netns during this test) to the subscriber, outside of bngblaster. This is working so seems the v6 forwarding on the DUT is ok.

• network interface placed in netns LAB

root@bng-poc1-bngblaster:~# ip netns exec LAB ip a sh dev int.100
2: int.100@enp130s0f4d1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:07:43:55:eb:78 brd ff:ff:ff:ff:ff:ff
    inet6 2001:db8:1::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::207:43ff:fe55:eb78/64 scope link 
       valid_lft forever preferred_lft forever

• routing table of netns LAB

root@bng-poc1-bngblaster:~# ip netns exec LAB ip -6 rou show
2001:db8:1::/64 dev int.100 proto kernel metric 256 pref medium
fe80::/64 dev enp130s0f4d1 proto kernel metric 256 pref medium
fe80::/64 dev int.100 proto kernel metric 256 pref medium
default via fe80::7ff:feb2:15e4 dev int.100 proto ra metric 1024 expires 323sec hoplimit 64 pref medium

• dialup in the default context on the bngblaster server

root@bng-poc1-bngblaster:~# ip a sh ppp0
15: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 172.99.99.33 peer 100.99.99.99/32 scope global ppp0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1110:0:9604:d7a9:bbb9:44a9/64 scope global temporary dynamic 
       valid_lft 603660sec preferred_lft 85220sec
    inet6 2001:db8:1110:0:207:43ff:fe55:eb70/64 scope global dynamic mngtmpaddr 
       valid_lft 2591801sec preferred_lft 604601sec
    inet6 fe80::207:43ff:fe55:eb70 peer fe80::669d:99ff:feb2:15e3/128 scope link 
       valid_lft forever preferred_lft forever

• pinging subscriber from LAB netns, through the DUT router

root@bng-poc1-bngblaster:~# ip netns exec LAB ping6 2001:db8:1110:0:207:43ff:fe55:eb70
PING 2001:db8:1110:0:207:43ff:fe55:eb70(2001:db8:1110:0:207:43ff:fe55:eb70) 56 data bytes
64 bytes from 2001:db8:1110:0:207:43ff:fe55:eb70: icmp_seq=1 ttl=63 time=0.207 ms
64 bytes from 2001:db8:1110:0:207:43ff:fe55:eb70: icmp_seq=2 ttl=63 time=0.160 ms
64 bytes from 2001:db8:1110:0:207:43ff:fe55:eb70: icmp_seq=3 ttl=63 time=0.138 ms
^C
--- 2001:db8:1110:0:207:43ff:fe55:eb70 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2046ms
rtt min/avg/max/mdev = 0.138/0.168/0.207/0.028 ms

bngblaster json

Here is our json used for this test. To note again, we are getting the v4 streams received/verified no problem, but not the v6.

{
    "interfaces": {
        "capture-include-streams": true,
	"network": {
            "interface": "enp130s0f4d1",
            "address": "100.127.1.2/24",
            "gateway": "100.127.1.1",
            "address-ipv6": "2001:db8:1::2/64",
            "gateway-ipv6": "2001:db8:1::1",
            "vlan": 100
        },
        "access": {
            "interface": "enp130s0f4",
            "vlan-mode": "N:1",
	    "outer-vlan": 702,
            "type": "pppoe",
            "stream-group-id": 1
        }
    },
    "streams": [
        {
            "name": "general4",
            "stream-group-id": 1,
            "type": "ipv4",
            "direction": "downstream",
            "bps": 1736000,
            "length": 1024,
            "network-interface": "enp130s0f4d1:100"
        },	
	{
            "name": "general6",
            "stream-group-id": 1,
            "type": "ipv6",
            "direction": "downstream",
            "bps": 1736000,
            "length": 1024,
            "network-interface": "enp130s0f4d1:100"
        }
    ],
    "sessions": {
        "start-rate": 30,
        "stop-rate": 30
    },
    "pppoe": {
        "reconnect": true
    },
    "ppp": {
        "mru": 1492,
        "authentication": {
            "username": "[email protected]",
            "password": "testing",
            "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
        },
        "ip6cp": {
            "enable": true,
            "conf-request-timeout": 1,
            "conf-request-retry": 10
        }
    },
    "dhcpv6": {
        "enable": true,
        "retry": 2
    }
}

[GIC-de]

I have some idea. To improve performance, IPv6 stream traffic is send with UDP checksum zero, which is permitted for IPv4 but not permitted for IPv6. Typically network devices would not check but you are using a virtual BNG, maybe with UDP checksum offloading enabled, so this could cause such drops. You can try to disable checksum offloading.

You can also open an issue to add a new configuration option to enable IPv6 UDP checksums.

[marthin-vandyk]

Thanks Christian! will have a look. have an adjunct question open with router software devs so will ask them this as well.

Yes I noticed the error in the pcap as well, made a note however was not sure if that would impact anything.

[marthin-vandyk]

Hi Christiaan, seems this was the issue. thanks for the spot!