[c-nsp] S2T - XConnect traffic punted when VC is down

[Robert Williams]

Hi,

I have an issue which has been discovered during some lab testing that I’m hoping someone can either clarify or explain. The example is very simple, a dual Sup-2T based 6807 with the active supervisor’s port te3/5 configured as with:

interface TenGigabitEthernet3/5
no ip address
no keepalive
storm-control broadcast level 1.00
storm-control multicast level 1.00
xconnect 1.2.3.4 9999 encapsulation mpls

The port is then sent 5gbit/s of ‘simulated’ customer data (50% of port speed), with a selection of protocols in it as used in real life (it’s a capture of real traffic, uni, multi and broadcast – streamed in a loop).

When the xconnect is up, everything works fine as expected. However, when the xconnect goes down (I shutdown the upstream OSPF adjacency) then the Sup-2T grinds to a halt and the chassis collapses with high-CPU.

I’ve done a netdr and all the customer’s non-unicast traffic appears to be punted to the CPU, of which some is matching CoPP of course. However, CoPP is insufficient to protect the CPU and so it fails.

In my opinion, once a port is configured for a xconnect the traffic should be either encapsulated (into MPLS) or if the VC is down, then it should be dropped. Why is it being processed by the CPU, it seems crazy as it puts the stability of the whole chassis at risk.

For example, if an upstream link fails and 200 customer ports suddenly lose their xconnects, then all the ambient non-unicast traffic (which could be anything at all) will suddenly be punted to the CPU. So their STP, multicasts, IPv6 NA/RA, broadcasts etc. will hit the CPU. At best this will cause drops against CoPP classes, resulting in genuine packets from actual L3 ports going missing. At worst, the chassis collapses and goes unresponsive (as is the case in this test) – even with storm-control set to 1% which is a sensible value, I think anyway.

Any access-lists or filters which I place on the port will then interfere with the customer’s genuine traffic once the xconnect is back up, including storm-control which I don’t want to unnecessarily trip when the service is running because the customers expect a ‘transparent’ service. So I see no way to protect against this? What am I missing here?

Thanks in advance for any pointers!

Robert Williams
Custodian Data Centre
Email: Robert at CustodianDC.com
http://www.CustodianDC.com