Routing

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.

Dual-stack DHCPv6 subscribers see 12% packet loss, but no packet loss on IPv4

  • 1.  Dual-stack DHCPv6 subscribers see 12% packet loss, but no packet loss on IPv4

    Posted 03-21-2022 16:42
    Hello,

    We have a dual-stack IPv4 and IPv6 DHCP access network, and are seeing some odd behavior on the IPv6 leg that we don't see on IPv4. Our dual-stack set up is fairly simple, we use static IP Demux interfaces over a static single VLAN, and use DHCP-relay to assign addresses -- there is no authentication, firewall, or CoS configuration in our subscriber dynamic profiles.

    Dual-stack clients are getting assigned an IPv4 address and IPv6 IA_NA and IA_PD just fine. There is no problem with address assignment with our DHCP and DHCPv6 relay, and subscriber manager is installing Access-Internal routes for these clients accordingly.


    Our dual-stack clients are seeing about 12% packet loss over IPv6, but not over IPv4. When running a continuous ping to a client's IA_NA address, we see packet loss for 2-4 seconds, then no packet loss for 10-15 seconds, then packet loss again, etc.. We do not see any state changes (no route flapping) to the dual-stack client's Access-Internal route entries, and there no route flapping on our IGP.


    For example one of our dual-stack clients:
    admin@mx204> show subscribers interface ae0.2499
    Interface                             IP Address/VLAN ID                                           User Name LS:RI
    ae0.2499                           207.135.133.11                                                                     default:default
    ae0.2499                           2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f       default:default
    *                                              2607:fa18:7b00::/64




    The client's assigned IPv6 address and prefix are also correctly getting Access-Internal routes in our MX204 router:

    admin@mx204> show route 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f detail

    inet6.0: 144905 destinations, 289874 routes (144905 active, 0 holddown, 0 hidden)
    2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f/128 (1 entry, 1 announced)
    *Access-internal Preference: 12
    Next hop type: Private unicast, Next hop index: 0
    Address: 0x4e2879c
    Next-hop reference count: 19184
    Next-hop index: 635
    State: <Active Int NSR-incapable>
    Age: 32:06
    Validation State: unverified
    Task: RPD Unix Domain Server./var/run/rpd_serv.local
    Announcement bits (2): 0-KRT 2-Resolve tree 2
    AS path: I


    admin@mx204> show route range 2607:fa18:7b00::/64 detail

    inet6.0: 144889 destinations, 289842 routes (144889 active, 0 holddown, 0 hidden)
    2607:fa18:7b00::/64 (1 entry, 1 announced)
    *Access Preference: 13
    Next hop type: Private unicast, Next hop index: 0
    Address: 0x4e2879c
    Next-hop reference count: 19192
    Next-hop index: 635
    State: <Active Int NSR-incapable>
    Age: 32:52
    Validation State: unverified
    Task: RPD Unix Domain Server./var/run/rpd_serv.local
    Announcement bits (2): 0-KRT 2-Resolve tree 2
    AS path: I


    If I ping the client's IPv6 IA_NA address using our router's IPv6 loopback interface, we see packet loss:

    admin@mx204> ping 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f
    PING6(56=40+8+8 bytes) 2607:fa18:1:1::52 --> 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=0 hlim=64 time=1.868 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=1 hlim=64 time=1.825 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=2 hlim=64 time=3.233 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=3 hlim=64 time=2.024 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=4 hlim=64 time=1.603 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=9 hlim=64 time=88.934 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=10 hlim=64 time=1.641 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=11 hlim=64 time=1.713 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=12 hlim=64 time=1.625 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=13 hlim=64 time=1.693 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=14 hlim=64 time=1.709 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=15 hlim=64 time=1.602 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=16 hlim=64 time=1.666 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=17 hlim=64 time=9.915 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=18 hlim=64 time=2296.454 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=19 hlim=64 time=1295.272 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=20 hlim=64 time=294.419 ms
    16 bytes from 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f, icmp_seq=21 hlim=64 time=2.196 ms
    ^C
    --- 2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f ping6 statistics ---
    22 packets transmitted, 18 packets received, 18% packet loss
    round-trip min/avg/max/std-dev = 1.602/222.744/2296.454/584.670 ms



    If we have a client statically assign an IPv6 address (ie, not interact with DHCPv6 or subscriber management), we see no packet loss. Here is a ping from our router's loopback to a client with a static IPv6 address:

    admin@mx204> ping 2607:fa18:7800:aaaa::1234
    PING6(56=40+8+8 bytes) 2607:fa18:1:1::52 --> 2607:fa18:7800:aaaa::1234
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=0 hlim=64 time=1.589 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=1 hlim=64 time=1.435 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=2 hlim=64 time=1.254 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=3 hlim=64 time=1.449 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=4 hlim=64 time=83.440 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=5 hlim=64 time=1.838 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=6 hlim=64 time=2.719 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=7 hlim=64 time=1.547 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=8 hlim=64 time=1.377 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=9 hlim=64 time=1.483 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=10 hlim=64 time=1.339 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=11 hlim=64 time=1.488 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=12 hlim=64 time=1.416 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=13 hlim=64 time=102.698 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=14 hlim=64 time=1.461 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=15 hlim=64 time=1.463 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=16 hlim=64 time=1.742 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=17 hlim=64 time=1.293 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=18 hlim=64 time=1.256 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=19 hlim=64 time=1.261 ms
    16 bytes from 2607:fa18:7800:aaaa::1234, icmp_seq=20 hlim=64 time=1.372 ms
    ^C
    --- 2607:fa18:7800:aaaa::1234 ping6 statistics ---
    21 packets transmitted, 21 packets received, 0% packet loss
    round-trip min/avg/max/std-dev = 1.254/10.234/102.698/27.041 ms




    The Access-Internal route subscriber management is creating for DHCPv6 clients look correct, but we noticed that subscriber management also creates an entry in the router's IPv6 Neighbor cache that looks a little odd:


    admin@mx204> show ipv6 neighbors
    IPv6 Address                                                                           Linklayer  Address            State       Exp    Rtr  Secure      Interface
    2607:fa18:7800:1000:9c22:9bb6:3ae2:ef3f         14:cc:20:e2:97:f1     reachable    0    no no              demux0.2499
    fe80::16cc:20ff:fee2:97f1                                                  14:cc:20:e2:97:f1     reachable    0      no no             ae0.2499


    The client's IPv6 IA_NA address is showing up on the demux0 interface, while the client's link-local address is on the underlying access interface. We would expect both IPv6 address and the link-local address to be on the same interface, like the client with a static IPv6:


    garlicky@mar3> show ipv6 neighbors | match 2c:60:0c:f7:91:07
    2607:fa18:7800:aaaa::1234                                     2c:60:0c:f7:91:07          stale    969       yes no              ae0.2499
    fe80::63d0:a08b:8562:74b4                                    2c:60:0c:f7:91:07          stale    929       no no                ae0.2499


    Could this be part of the part of the problem with packet loss over IPv6? The Access-Internal routes look correct, but  our router seems to have difficulty routing packets to IPv6 subscribers.

    ------------------------------
    LINDSAY PARSONS
    ------------------------------