[c-nsp] Best practices for Cat6500

[Justin Krejci]

With regards to SSO-NSF and HSRP I've read documents on ciscos site that
conflict when discussing the use of NSF. 

One indicates do not use HSRP and NSF together on the same box.
http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsnsf20s.html#wp1467556
http://www.cisco.com/en/US/customer/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/nsfsso.html#wp1112624


I've read in another article (sorry, don't have the URL handy at the
moment but I think I saw in a PDF from cisco.com) that either implied
the use of NSF and HSRP together was OK thru config examples or
something or else explicitly stated the use of the to together is OK.

Can anyone comment on this conflict? Also does this conflict with NSF
also apply to GLBP which can be configured in a way to behave similar to
that of HSRP? The second link above makes comment of GLBP but the first
one does not. Is GLBP newer than the first article?

Thanks.


On Mon, 2010-11-01 at 11:59 +0000, Phil Mayers wrote:

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