1) there is a 1 gig inband channel to CPU. the traffic prioritization referred to (selective packet discard) really doesn't matter at the point in which the inband channel is saturated. when you start punting large amounts of traffic to CPU, it will take down your routing protocols, kill ARP, etc, even with selective packet discard, due to this saturation. the only way to prevent this is CoPP in the fast path.
2) inband traffic is interrupt driven on this platform. high inband traffic, by itself, will cause the CPU to spike and drop protocols (missed hellos, etc).
the result will be, without a doubt, an outage. packet loss and high latency would be the best case scenario, but only on a box that doesn't carry much traffic (typically not the case for anything taking full tables).
as a side note, these boxes should have started alarming well before overrunning the TCAM (iirc, it begins at 97% utilization), so operators should have had notice to implement the necessary TCAM carving changes.
1) there is a 1 gig inband channel to CPU. the traffic prioritization referred to (selective packet discard) really doesn't matter at the point in which the inband channel is saturated. when you start punting large amounts of traffic to CPU, it will take down your routing protocols, kill ARP, etc, even with selective packet discard, due to this saturation. the only way to prevent this is CoPP in the fast path.
2) inband traffic is interrupt driven on this platform. high inband traffic, by itself, will cause the CPU to spike and drop protocols (missed hellos, etc).
the result will be, without a doubt, an outage. packet loss and high latency would be the best case scenario, but only on a box that doesn't carry much traffic (typically not the case for anything taking full tables).
as a side note, these boxes should have started alarming well before overrunning the TCAM (iirc, it begins at 97% utilization), so operators should have had notice to implement the necessary TCAM carving changes.