[c-nsp] Best practices for Cat6500

[Phil Mayers]

On 01/11/10 10:00, Robert Hass wrote:
>
> 1) mls rate-limit
>
> My current configuration only consist few rate-limiters:
>
> mls rate-limit unicast ip rpf-failure 300 30
> mls rate-limit unicast ip icmp unreachable no-route 300 30
> mls rate-limit unicast ip icmp unreachable acl-drop 300 30
> mls rate-limit unicast ip errors 300 30
>
> Should I consider to configure more mls rate-limiters ?

Search the archives for truly extensive discussion on these issues.

Suffice to say that some of the more useful looking rate-limiters 
(glean, receive) have gotchas either in terms of bugs in certain 
hardware (glean limiter subject to output ACL of input interface on some 
PFC/DFC versions) or just sub-optimal behaviour.

We use these, in addition to what you've got, which I believe to be 
relatively safe:

mls rate-limit all ttl-failure 100 10
mls rate-limit all mtu-failure 100 10


>
> I would like to implement 'mls rate-limit layer2 pdu'. How I can check
> how many layer2 pdu packets are coming to RP ? And SNMP Oid or CLI
> command to show this ?

Personally I would avoid that, and instead ensure layer2 PDUs are 
filtered on untrusted ports.

> 3) Automatic BGP refresh
>
> When I change something in route-map for inbound BGP prefixes I
> noticed that Cat6500 automatically refresh inbound BGP router
> (automatically doing something like clear ip bgp x.x.x.x in). Is is
> new feature in SXI4a ?

Really? Are you sure?

>
> 4) NetFlow only for packets going to RP/SP
>
> Is any way to export NetFlow (v5 or v9) information for packets coming
> to RP/SP only ? I would like to check whats coming to software
> switching by RP/SP for develop control-plane policing are decrease CPU
> usage for eg. ICMP traffic.

Not sure about that, but you can use SPAN to monitor the SP/RP:

mon sess 1 type ...
   source cpu rp
   source cpu sp

...etc.

>
> 5) Supervisor Redundancy
>
> I would like to add redundant Sup720. Is IOS automatically will switch
> to second Supervisor when primary :
> a) Will crash (software error/bug)
> b) Will fail (hardware failure)

Not automatically - you need to configure it:

redundancy
  main-cpu
   auto-sync running-config
  mode sso

When configured, it is supposed to protect against many failures. It 
works most of the time; however in early versions of SXI we saw a couple 
of crashes where the primary sup crashed, and the SSO caused the 
secondary to crash, dropping both to ROMMON :o(

But we have also seen successful SSO.

Beware: SSO alone might not be sufficient. You might need NSF, and 
routing neighbours (e.g. BGP, OSPF) that support NSF, in order to 
recover "instantly".

>
> In my configuration I'm using old classic bus cards (3 x WS-X6408A-GBIC).

I'm not sure if SSO supports classic bus cards; read the docs.