Routing

 View Only

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



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
    ------------------------------