[Subscriber Management] DHCPv6 advertise message source address does not match address on interface

Summary:

MX DHCPv6 advertise message source address is different from the address on VLAN interface.

This article provides two options to resolve this issue.

Symptoms:

When DHCPv6 client dials in from one static VLAN interface, the MX router replies to DHCPv6 advertise by using another VLAN interface link-local address as source. Then the DHCPv6 client sends NS to MX, and MX replies NA with router bit set. Next, the DHCPv6 client gateway address v6 neighbor entry is refreshed.

All DHCP messages sent from MX source address is wrong, but the RA message source address is correct. For this reason, the DHCPv6 client gateway neighbor entry is unstable. When it received the DHCP message, the gateway becomes unreachable. However, when it received the RA message, it is reachable.

Example configuration:

interfaces {
    xe-4/1/0 {
        unit 0 {
            family inet6 {
                address 3000::1/64;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet6 {
                address 2402:f000:4:71::1/128;
            }
        }
    }
    xe-4/0/3 {
        flexible-vlan-tagging;
        encapsulation flexible-ethernet-services;
        unit 10 {
            vlan-id 10;
            generate-eui64;
            family inet6 {
                unnumbered-address lo0.0 preferred-source-address 2402:f000:4:71::1;
            }
        }
        unit 20 {
            vlan-id 20;
            family inet {
                address 101.6.251.129/25;
            }
        }
        unit 30 {
            vlan-id 30;
            family inet6 {
                address 2003::1/64;  <-- problem vlan interface
            }
        }
    }
}
forwarding-options {
    dhcp-relay {
        dhcpv6 {
            overrides {
                send-release-on-delete;
            }
            group no-demux {
                active-server-group DHCPv6-QIP812;
                interface xe-4/0/3.30;
            }
            server-group {
                DHCPv6-QIP812 {
                    3000::2;
                }
            }
        }
    }
}
protocols {
    router-advertisement {
        interface xe-4/0/3.10 {
            managed-configuration;
            other-stateful-configuration;
        }
        interface xe-4/0/3.30 {
            managed-configuration;
            other-stateful-configuration;
        }
    }
}

user@mx> show interfaces xe-4/0/3 terse
Interface               Admin Link Proto    Local                 Remote
xe-4/0/3                up    up
xe-4/0/3.10             up    up   inet6    fe80::f6cc:55ff:fe89:3297   <-- jdhcpd used this address as source address 
                                   multiservice
xe-4/0/3.20             up    up   inet     101.6.251.129/25
                                   multiservice
xe-4/0/3.30             up    up   inet6    2003::1/64
                                            fe80::f6cc:5500:1e89:3297/64   <-- this address should be correct one
                                   multiservice
xe-4/0/3.32767          up    up   multiservice

user@mx> show interfaces lo0 terse
Interface               Admin Link Proto    Local                 Remote
lo0                     up    up
lo0.0                   up    up   inet6    2402:f000:4:71::1
                                            fe80::2a0:a50f:fc91:818e
lo0.16384               up    up   inet     127.0.0.1           --> 0/0
lo0.16385               up    up   inet

user@mx# run monitor traffic interface xe-4/0/3.30 no-resolve size 1500 matching "port 546 or 547"
verbose output suppressed, use  or  for full protocol decode
Address resolution is OFF.
Listening on xe-4/0/3.30, capture size 1500 bytes

13:24:08.263394  In IP6 fe80::210:94ff:fe00:1.546 > ff02::1:2.547: dhcp6 solicit
13:24:08.423921 Out IP6 fe80::f6cc:55ff:fe89:3297.547 > fe80::210:94ff:fe00:1.546: dhcp6 advertise
MX used  xe-4/0/3.10 link-local address fe80::f6cc:55ff:fe89:3297 as source on interface xe-4/0/3.30
13:24:09.263601  In IP6 fe80::210:94ff:fe00:1.546 > ff02::1:2.547: dhcp6 request
13:24:09.623356 Out IP6 fe80::f6cc:55ff:fe89:3297.547 > fe80::210:94ff:fe00:1.546: dhcp6 reply

Cause:

Bbesmgd uses MAC based EUI-64 link-local address for source address for all IPv6 DORA exchanges packets. This is FAD and day one behavior.
All the sourced DORA packet over a ge-x/y/z interface will have the same source IPv6 address irrespective of VLAN ID.
Router-advertisement packets sourced from bbesmgd (configured in dynamic profile) will also use MAC based EUI-64 link-local as source IPV6 address.
Router-advertisement packets sourced RPD (static config) will use rtsock interface's link-local address (ex: ge-1/0/0.10 or ge-1/0/0.30, etc)
The rtsock link-local can be configured to be derived off of MAC address by using the following config switch - "generate-eui64"

Solution:

Option #1 - Move router-advertisement config from static interface to dynamic profile.

Option #2 - Use "generate-eui64" configuration option for all static VLANs. For above example, refer to the following configuration modification.

interfaces {
    lo0 {
        unit 0 {
            family inet6 {
                address 2003::1/128;  <-- move global address from vlan interface to lo0.0
            }
        }
    }
    xe-4/0/3 {
        unit 30 {
            generate-eui64;  <-- add generate-eui64 knob
            family inet6 {
                unnumbered-address lo0.0 preferred-source-address 2003::1;  <-- set vlan interface to unnumbered-address
            }
        }
    }
}
routing-options {
    rib inet6.0 {
        static {
            route 2003::/64 discard;   <-- add discard route for dhcpv6 clients address range
        }
    }
}

Knowledge Base