HSRP is an "inbound" next hop routing protocol. It creates a virtual Ip that tracks with a virtual MAC. It has no bearing on outbound traffic, only inbound. With HSRP it is very easy to create asymmetrical routing.
For example, consider a firewall connected to a VLAN with two 6500 switches (10.1.2.2) 6500-A (10.1.1.1) PC --> HSRP (10.1.2.3) (10.1.1.3) (HSRP) --> Firewall (10.1.1.4) (10.1.2.4) (10.1.2.1) 6500-B (10.1.1.2) PC outbound traffic will go out via 6500-A, return traffic will come in via 6500-B With no priority set with HSRP, the active interface is chosen by the "higher" IP. With dynamic routing and HSRP, it's even easier to create asymetrical routing. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 > -----Original Message----- > From: cisco-nsp-boun...@puck.nether.net > [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron > Riemer > Sent: Wednesday, July 14, 2010 10:59 AM > To: 'Benjamin Lovell' > Cc: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720 > > Forgive my ignorance. What is ECPM?? > > Shouldn't all routed traffic be handled by the active HSRP node? > > -----Original Message----- > From: Benjamin Lovell [mailto:belov...@cisco.com] > Sent: Wednesday, 14 July 2010 10:38 PM > To: Aaron Riemer > Cc: 'JC Cockburn'; 'Phil Mayers'; cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720 > > Most of the time we see problems like this it is caused by asymmetric > routing. The ECPM return path leads to the standby switch which does not > know the DMAC as all traffic was processed by the active switch. This is > usually fixed by increasing the MAC table timers to match the ARP timers so > that standby will keep MAC in table long enough until the next time ARP > comes around. > > -Ben > > On Jul 14, 2010, at 9:46 AM, Aaron Riemer wrote: > > > Hi Phil, > > > > Answers below: > > > > 1) IOS - s72033-advipservicesk9_wan-mz.122-18.SXF17a.bin > > 2) HSRP configured between two core 6509's. SVI is VLAN1 (I know don't > ask) > > trunked between the cores via 10G. Only ports in VLAN1 on one core switch > > are impacted and seeing the flooding. > > 3) Building floor switches connect to both cores (Routed and running > EIGRP) > > 4) Spanning Tree Below: > > > > Core1: > > spanning-tree mode pvst > > spanning-tree vlan 1-199,336,503-930 priority 16384 > > > > Core2: > > spanning-tree mode pvst > > spanning-tree vlan 1-199,336,503-930 priority 0 > > > > 5) No rate limiting or CoPP configured. We are seeing drops even when the > > CPU is not hitting 100% (most likely due to ASIC oversubscription). > > 6) Source of traffic is unknown at this stage. Will turn to wireshark > > tomorrow. > > 7) I don't believe there are any L2 loops. If spanning-tree was an issue I > > would think the CPU would gradually hit 100% and stay there. > > > > We are seeing output drops on interfaces and oversubscription of ASICs as > a > > result of this flooding which I think is the main culprit for the brief > > connectivity outages. Is there a way similar to CoPP to protect the ASICs > to > > ensure they are never 100% utilised? Egress shaping on all suspect ports? > > > > > > Thanks, > > > > Aaron. > > > > > > -----Original Message----- > > From: cisco-nsp-boun...@puck.nether.net > > [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of JC Cockburn > > Sent: Wednesday, 14 July 2010 8:03 PM > > To: 'Phil Mayers' > > Cc: cisco-nsp@puck.nether.net > > Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720 > > Importance: High > > > > Hi Phil, > > I had a problem like this last year on 6500's. > > It was related to bug: CSCsk23521 > > Basically a server in our datacenter used multicast addresses in the range > > allocated for BPDU's, and this just killed the SP (100% CPU...). > > > > If you do a "remote command switch sh proc cpu" on the 6500 you can see if > > the SP CPU is under fire... > > > > Cheers > > JC > > > > -----Original Message----- > > From: cisco-nsp-boun...@puck.nether.net > > [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers > > Sent: Wednesday, July 14, 2010 1:41 PM > > To: cisco-nsp@puck.nether.net > > Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720 > > > > On 14/07/10 11:30, Aaron Riemer wrote: > >> Hi Group, > >> > >> > >> > >> We are having trouble with unicast flooding on a particular VLAN and > >> associated ports and as a result brief spikes in CPU usage on one of our > >> 6509 core switches. > >> > >> > >> > >> ARP and MAC timeouts are set to default and we haven't had problems with > >> this in the past. The problem is I believe this is causing brief 100% > > spikes > >> within the SP or RP and as a result brief connectivity outages. > > > > Which is it? SP or RP? > > > >> > >> > >> > >> We have narrowed down the source of the unicast flooding but we need to > > know > >> why it is occurring. > > > > Rather more info required I think. > > > > * IOS version > > * Config of ports & SVIs in question > > * Nature of downstream devices (if any) > > * spanning tree config (if any) > > * rough idea of the size of the ARP & MAC tables > > * Any MLS rate-limit or CoPP config > > * Nature of the source of the unicast-flooded traffic > > * Any possibility of loops in the network? > > > >> Has anyone experienced this in the past? Could unicast flooding over > >> multiple interfaces account for this kind of behaviour? > > > > Anything punted to the CPU at high rate could cause this kind of thing. > > That's why MLS limiters and CoPP are important on this platform, even > > with all their limitations. > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > <RP CPU.txt><sh module.txt><SP > CPU.txt>_______________________________________________ > > cisco-nsp mailing list cisco-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/