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

[Phil Mayers]

On 07/02/17 19:21, Jason Lixfeld wrote:
> 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)

Seems this is not actually IPv6 traffic, rather encapsulated SPAN 
traffic. Notice that dst/src MAC of the outer packet make up the last 
two bytes/first ten of the supposedly embedded IPv6 packet, so I think 
there's an ethernet frame - there's an 8847 earlier in the source IP 
which is MPLS ethertype

I'm not familiar with how that platform does encapsulated SPAN but 
obviously check you don't have it setup to do that.

Otherwise I guess a hw/sw bug in setting up SPAN and applying 
encapsulation wrongly, or a FIB misprogram on the encapsulation 
forwarding path.