[c-nsp] full routing table / provider-class chassis (Roland Dobbins)

Roland Dobbins rdobbins at arbor.net
Thu Jun 11 12:07:47 EDT 2009


On Jun 11, 2009, at 9:22 PM, Jeff Bacon wrote:

> Is there a good list of these caveats somewhere I can look at?

NetFlow:

256K mls tables at 93% efficiency (~233K entries).

No packet-sampled control of flow creation can lead to mls table  
overflow & non-deterministic skewing of stats/heuristics; small mls  
table size contributes to this in environments with diverse traffic  
patterns and/or high pps, such as SP edge.  NetFlow 'sampling' on  
6500/7600 is actually NDE output telemetry sampling only, not the same  
as packet-sampled control of flow creation on software platforms, GSR,  
ASR 1K, CRS-1, N7K.

No logical OR of TCP flags observed throughout a TCP flow, only the  
last flag.

No dropped traffic stats/heuristics.

ACLs:

ACLs must be carefully crafted to avoid LOU exhaustion & subsequent  
software switching self-DoS:

<https://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp43500 
 >

uRPF:

uRPF mode must be the same for all interfaces in a chassis.

Note that these are all edge features.  These boxes are fine running  
in the core and/or other areas in which these particular edge features  
aren't required; it's the edge which can be problematic.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton



More information about the cisco-nsp mailing list