Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
During a test series for verification of IOS-XE 16.9.3 for the Catalyst 9300 we've observed, that ND inspection as part of an attached IPv6 snooping policy did not work as expected. For the ND inspection test, the valid and reachable IPv6 address of a client is spoofed by another client residing on the same switch. This address spoofing is simulated, by sending crafted neighbor solicitation and neighbor advertisement messages. In proceeding test series, the switch recognized that "a more trusted entry exists" and dropped the spoofed packets. In the current test series for 16.9.3, the spoofed packet was not dropped, as expected. Instead, this message updated the reachable timer for the original IPv6 and MAC address. The curious thing is, that the feature works correctly (message is dropped), if the spoofed message is sent twice, with e.g. one second delay.
N/A
N/A
The scenario is like follows: Output from the device-tracking database: Switch#show device-tra database ... ND xxxx:xxxx:3FC:A802::1:12 001d.d8b7.1de5 Gi1/0/1 506 0005 13s REACHABLE 18 s try 0 ND xxxx:xxxx:3FC:A802::1:11 001d.d8b7.1df3 Gi2/0/1 506 0005 14s REACHABLE 16 s try 0 ... The spoofed packet is sent (packet 7 in the capture file). New output from the device-tracking database (reachable timer for Gi2/0/1 is reset): Switch#show device-tra database ... ND xxxx:xxxx:3FC:A802::1:12 001d.d8b7.1de5 Gi1/0/1 506 0005 20s REACHABLE 11 s try 0 ND xxxx:xxxx:3FC:A802::1:11 001d.d8b7.1df3 Gi2/0/1 506 0005 2s REACHABLE 29 s try 0 ... Currently evaluating IOS-XE 16.9.4 and this version shows a different behavior as 16.9.3. In this version, the spoofed message from an IPv6 address that is gleaned via DHCPv6, is dropped by the switch, as it is expected: Switch#show device-tracking da ... DH6 xxxx:xxxx:3FC:A802:0:1:0:3 001d.d8b7.1df3 Gi2/0/1 506 0030 16s REACHABLE 15 s try 0(604212 s) ... Switch# Sep 5 12:15:57.558 UTC: %SISF-4-PAK_DROP: Message dropped A=xxxx:xxxx:3FC:A802:0:1:0:3 G=- V=506 I=Gi1/0/1 P=NDP::NS Reason=More trusted entry exists Switch# Sep 5 12:16:58.803 UTC: %SISF-4-PAK_DROP: Message dropped A=xxxx:xxxx:3FC:A802:0:1:0:3 G=- V=506 I=Gi1/0/1 P=NDP::NA Reason=More trusted entry exists Switch#show device-tracking counters int gi 1/0/1 ... Dropped messages on Gi1/0/1: Feature Protocol Msg [Total dropped] Device-tracking NDP NS [1] reason: More trusted entry exists [1] NA [1] reason: More trusted entry exists [1] The static address, which is gleaned in the device-tracking database via NDP, shows slightly different behavior, as well. The first spoofed message resets the reachable timer for the original MAC, that is the same behavior as in 16.9.3. But in 16.9.4, the switch brings the log message, that the message was dropped: Switch# Sep 5 12:12:27.475 UTC: %SISF-4-PAK_DROP: Message dropped A=xxxx:xxxx:3FC:A802::1:11 G=- V=506 I=Gi1/0/1 P=NDP::NA Reason=Packet accepted but not forwarded Switch#show device-tracking counters int gi 1/0/1 ... Dropped messages on Gi1/0/1: Feature Protocol Msg [Total dropped] Device-tracking NDP NA [1] reason: Packet accepted but not forwarded [1] However, the "more trusted entry exists" log message appears only, if 2 consecutive spoofed messages are sent, same as in 16.9.3: Switch# Sep 5 12:12:43.537 UTC: %SISF-4-PAK_DROP: Message dropped A=xxxx:xxxx:3FC:A802::1:11 G=- V=506 I=Gi1/0/1 P=NDP::NA Reason=Packet accepted but not forwarded Switch#show device-tracking counters int gi 1/0/1 ... Dropped messages on Gi1/0/1: Feature Protocol Msg [Total dropped] Device-tracking NDP NA [3] reason: More trusted entry exists [1] reason: Packet accepted but not forwarded [2] ! device-tracking policy IPv6-FHS-SNOOPING limit address-count 10 no protocol arp no protocol dhcp4 no protocol udp !