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 [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
