[c-nsp] IOS XR 5.3.4 tx-only or bi-dir monitor session = IPv6 DoS?

[Jason Lixfeld]

Unless I’m doing something dumb, I’ve got an odd one here.  A new ASR9000 5.3.4 box in the lab with one interface enabled for upstream traffic (BFD, LDP, ISIS) and one bundle interface enabled for downstream traffic (dot1q routed subinterfaces with one active link in the bundle).  Both are on the same Trident based 16 port 10G card (fpd up to date); different NPs, different fia, different bridge.

If I do either a tx-only or a bi-dir SPAN of the upstream facing port on this box, I seem to create an IPv6 DoS where the port I’ve enable the monitor session on generates tens of thousands of pps of IPv6 proto 64 (SATNET EXPAK) traffic towards the MAC of the box on the other end of this upstream interface (the box on the upstream side is also an A9K, running 4.3.4).  If I remove the SPAN, traffic drops back down to normal.  If I do a rx-only monitor session, it’s fine, which in this case fine means that I’m not seeing heaps of output packets in the show interface counters.

Here are a couple of frames segments of this traffic.  Src and Dst MAC are the 5.3.4 and 4.3.4 boxes, respectively.

Frame 23: 1110 bytes on wire (8880 bits), 1110 bytes captured (8880 bits) on interface 0
Ethernet II, Src: 40:55:39:2f:9e:80, Dst: 6c:9c:ed:57:6f:fa
MultiProtocol Label Switching Header, Label: 16164, Exp: 0, S: 0, TTL: 254
MultiProtocol Label Switching Header, Label: 946, Exp: 0, S: 1, TTL: 254
Internet Protocol Version 6, Src: 392f:9e80:8847:3f2:40fe:3b:21fe:6c9c, Dst: ed57:6ffa:4055:392f:9e80:8847:3f2:40fe
Data (1048 bytes)

Frame 24: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface 0
Ethernet II, Src: 40:55:39:2f:9e:80, Dst: 6c:9c:ed:57:6f:fa
MultiProtocol Label Switching Header, Label: 16164, Exp: 0, S: 0, TTL: 254
MultiProtocol Label Switching Header, Label: 946, Exp: 0, S: 1, TTL: 254
Internet Protocol Version 6, Src: 392f:9e80:8847:3f2:40fe:3b:21fe:4055, Dst: 392f:9e80:6c9c:ed57:6ffa:800:45c0:28
Data (36 bytes)

If I monitor the downstream bundle interface, any or all of it’s sub-interfaces, in any or all directions, it’s fine.

There are no IPv6 enabled interfaces on this 5.3.4 box, and the adjacent interface on the 4.3.4 box is also not IPv6 enabled (although the BGP VPNv6 AF is enabled, but it doesn’t make a difference whether it’s enabled or disabled, the issue is the same).

I’ve tried this capture on two separate wireshark machines, both of which are Mac OS Sierra based.  Both have the capture interface in IPv6 Link-Local Only mode.  Both machines exhibit the same symptoms.  The SPAN session itself is actually a PW-SPAN configuration.  It’s not hardwired.  I’ve done monitor sessions like this a hundred times, and I’ve never seen anything like this before.  Must be some 5.3.4 thing, but I can’t even begin to imagine what..

RP/0/RSP0/CPU0:#show install active summary
Tue Feb  7 14:19:23.490 EST
Default Profile:
  SDRs:
    Owner
  Active Packages:
    disk0:asr9k-mini-px-5.3.4
    disk0:asr9k-mpls-px-5.3.4
    disk0:asr9k-mgbl-px-5.3.4
    disk0:asr9k-mcast-px-5.3.4
    disk0:asr9k-fpd-px-5.3.4
    disk0:asr9k-k9sec-px-5.3.4
    disk0:asr9k-px-5.3.4.CSCvb31992-1.0.0
    disk0:asr9k-px-5.3.4.CSCvb37291-1.0.0
    disk0:asr9k-px-5.3.4.CSCvb39379-1.0.0
    disk0:asr9k-px-5.3.4.CSCvb72705-1.0.0
    disk0:asr9k-px-5.3.4.CSCvb88426-1.0.0
    disk0:asr9k-px-5.3.4.CSCvb92687-1.0.0
    disk0:asr9k-px-5.3.4.CSCvb95320-1.0.0
    disk0:asr9k-px-5.3.4.CSCvc02589-1.0.0
    disk0:asr9k-px-5.3.4.CSCvc18067-1.0.0
    disk0:asr9k-px-5.3.4.CSCvc22207-1.0.0

RP/0/RSP0/CPU0:#

Anyone seen anything like this before?