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.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
