[EX/MX/QFX] IPv6 NA packets have Override flag set differently

Description

Users may find that unicast IPv6 Neighbor Advertisement (NA) packets do not have the Override flag set, whereas other vendors may have this flag set in the same packets.

Juniper's implementation of IPv6 NA is compliant with RFC4861, which is the standard for IPv6 Neighbor Discovery Protocol (NDP) and which allows the Override flag to be set or not set in the IPv6 NA packets as required.

Based on the configuration of the Override flag, devices running Junos OS may have different actions of updating the corresponding NDP cache entry.

This article clarifies with an example that this is expected as per the RFC standard, which allows the flag to be set or not set.

Symptoms

Example

NA Packet from EX9214 (lab setup)

Ethernet II, Src: JuniperN_fe:6b:a7 (f4:b5:2f:fe:6b:a7), Dst: Cisco_29:bd:80 (00:1a:30:29:bd:80)
    Destination: Cisco_29:bd:80 (00:1a:30:29:bd:80)
    Source: JuniperN_fe:6b:a7 (f4:b5:2f:fe:6b:a7)
    Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::f6b5:2fff:fefe:6ba7, Dst: fe80::21a:30ff:fe29:bd80
    0110 .... = Version: 6
    .... 1100 0000 .... .... .... .... .... = Traffic Class: 0xc0 (DSCP: CS6, ECN: Not-ECT)
        .... 1100 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 6 (48)
        .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
    Payload Length: 24
    Next Header: ICMPv6 (58)
    Hop Limit: 255
 
<snip>
 
Internet Control Message Protocol v6
    Type: Neighbor Advertisement (136)
    Code: 0
    Checksum: 0xaaae [correct]
    [Checksum Status: Good]
    Flags: 0xc0000000, Router, Solicited
        1... .... .... .... .... .... .... .... = Router: Set
        .1.. .... .... .... .... .... .... .... = Solicited: Set
        ..0. .... .... .... .... .... .... .... = Override: Not set <===== Override NOT set
        ...0 0000 0000 0000 0000 0000 0000 0000 = Reserved: 0
    Target Address: fe80::f6b5:2fff:fefe:6ba7 <===== Target link-layer address field is NOT present, hence the Override flag is NOT set.

NA Packet from Cisco ASR9922 (from customer’s setup)

Juniper Ethernet <========== captured using monitor traffic interface command
    Magic Number: 0x4d4743
    .... ...1 = Direction: In (0x1)
    .... ..1. = L2 header presence: Unknown (0x1)
 
<snip>
 
Internet Protocol Version 6, Src: fe80::baa3:77ff:feb9:4a80, Dst: fe80::82ac:acff:fe3b:b37f <===== SRC/DST MACs
    0110 .... = Version: 6
    .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0 (DSCP: CS7, ECN: Not-ECT)
        .... 1110 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 7 (56)
        .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
    Payload Length: 32
    Next Header: ICMPv6 (58)
    Hop Limit: 255
 
<snip>
 
Internet Control Message Protocol v6
    Type: Neighbor Advertisement (136)
    Code: 0
    Checksum: 0x4620 [correct]
    [Checksum Status: Good]
    Flags: 0xe0000000, Router, Solicited, Override
        1... .... .... .... .... .... .... .... = Router: Set
        .1.. .... .... .... .... .... .... .... = Solicited: Set
        ..1. .... .... .... .... .... .... .... = Override: Set <===== Override set
        ...0 0000 0000 0000 0000 0000 0000 0000 = Reserved: 0
    Target Address: fe80::baa3:77ff:feb9:4a80
    ICMPv6 Option (Target link-layer address : b8:a3:77:b9:4a:80)
        Type: Target link-layer address (2)
        Length: 1 (8 bytes)
        Link-layer address: Cisco_b9:4a:80 (b8:a3:77:b9:4a:80) <===== Target link-layer address field is present, hence the Override flag is set.

When an NA packet with the Override flag set is received, a next-hop change is triggered. The following outputs are rtsockmon traces on the EX9214 switch taken when NA packets are received with/without the Override flag set:

NA packets with Override set (solicited and router flags set) injected into EX9214 switch (license check messages removed from the output)

root@EX9214_SF3_ASR9922_BMT:~ # rtsockmon -nrt
        sender   creator  flag    type       op
[07:16:12:421.822] kernel     rpd        P    nexthop    change  inet6 addr=fe80::21a:30ff:fe29:bd80 nh=ucst flags=0x1 uflags=0x0 idx=731 ifidx=384 filteridx=0 tid=0 lr_id=0   infotype = 0 fwdnhidx = 0 fwdnhtype = 0 af_fixup=inet6 nh_adders=0x0000000000000020 <===== Next-hop change happens for every NA packet (every 10 sec).
 
[07:16:22:546.916] kernel     rpd        P    nexthop    change  inet6 addr=fe80::21a:30ff:fe29:bd80 nh=ucst flags=0x1 uflags=0x0 idx=731 ifidx=384 filteridx=0 tid=0 lr_id=0   infotype = 0 fwdnhidx = 0 fwdnhtype = 0 af_fixup=inet6 nh_adders=0x0000000000000020
 
[07:16:32:623.859] kernel     rpd        P    nexthop    change  inet6 addr=fe80::21a:30ff:fe29:bd80 nh=ucst flags=0x1 uflags=0x0 idx=731 ifidx=384 filteridx=0 tid=0 lr_id=0   infotype = 0 fwdnhidx = 0 fwdnhtype = 0 af_fixup=inet6 nh_adders=0x0000000000000020

NA packets with no Override (solicited and router flags set) injected into EX9214 switch

root@EX9214_SF3_ASR9922_BMT:~ # rtsockmon -nrt
        sender   creator  flag    type       op
[08:22:51:685.349] license-ch license-ch PI   gencfg     add     major type="Feature License" minor type=1 seq 9 kid=0 lrid=0 key=0X 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 , feature: 0:0000000000000000 0000000000000000, validity type: 0
[08:22:51:685.600] kernel     kernel     PE   rts-err    add     function=unknown line=0 seq_no=10 rtm_type=gencfg rtm_op=add sender_id=license-check mproc_err=0 final_err=17:File exists
[08:22:51:685.616] license-ch unknown    PI   gencfg     delete  major type="Feature License" minor type=1 seq 11 kid=0 lrid=0 key=0X 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 , feature: 0:0000000000000000 0000000000000000, validity type: 0
[08:22:51:685.838] license-ch self       P    gencfg     delete  major type="Feature License" minor type=1 seq 12 kid=0 lrid=0 key=0X 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 , feature: 0:0000000000000000 0000000000000000, validity type: 0
 
<snip>
 
[08:25:21:799.525] license-ch license-ch PI   gencfg     add     major type="Feature License" minor type=1 seq 63 kid=0 lrid=0 key=0X 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 , feature: 0:0000000000000000 0000000000000000, validity type: 0
[08:25:21:799.773] license-ch self       P    gencfg     add     major type="Feature License" minor type=1 seq 64 kid=0 lrid=0 key=0X 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 , feature: 0:0000000000000000 0000000000000000, validity type: 0
[08:25:31:836.642] license-ch license-ch PI   gencfg     add     major type="Feature License" minor type=1 seq 65 kid=0 lrid=0 key=0X 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 , feature: 0:0000000000000000 0000000000000000, validity type: 0
[08:25:31:836.917] kernel     kernel     PE   rts-err    add     function=unknown line=0 seq_no=66 rtm_type=gencfg rtm_op=add sender_id=license-check mproc_err=0 final_err=17:File exists
[08:25:31:837.128] license-ch unknown    PI   gencfg     delete  major type="Feature License" minor type=1 seq 67 kid=0 lrid=0 key=0X 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 , feature: 0:0000000000000000 0000000000000000, validity type: 0 <===== No next-hop change is seen.

Solution

This is because the IPv6 NDP standard ( RFC4861 ) allows omitting the target link-layer address field in unicast NA packets.

As per the standard (RFC4861) :

7.2.4. Sending Solicited Neighbor Advertisements

A node sends a Neighbor Advertisement in response to a valid Neighbor Solicitation targeting one of the node's assigned addresses. The Target Address of the advertisement is copied from the Target Address of the solicitation. If the solicitation's IP Destination Address is <===== here not a multicast address, the Target Link-Layer Address option MAY be omitted ; the neighboring node's cached value must already be current in order for the solicitation to have been received. If the solicitation's IP Destination Address is a multicast address, the Target Link-Layer option MUST be included in the advertisement.

Furthermore, if the node is a router, it MUST set the Router flag to one; otherwise, it MUST set the flag to zero.

If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service, or the Target Link-Layer Address option is not included, the Override flag SHOULD <===== here be set to zero. Otherwise, the Override flag SHOULD be set to one.

Proper setting of the Override flag ensures that nodes give preference to non-proxy advertisements, even when received after proxy advertisements, and also ensures that the first advertisement for an anycast address "wins".

This behavior is compliant with the RFC4861 standard. No other action is required.