[c-nsp] HSRP issues on Cisco3550
Tom Sands
tsands at rackspace.com
Wed Nov 8 08:49:25 EST 2006
We've seen this type of scenario for years, which is why we opted to not
have ECP with OSPF. We did raise the cost on the standby.
I would first as what your STP setting are in relation to the
Active/Stanby router and dual homed access switch (where are you blocking).
While not everything seems that it works the way you would expect it to,
in our setup the secondary uplink going from the access switch to the
standby router was in blocking on the access switch side. And, since
the standby router was never used for an active return path for
forwarding, it would never have MAC's stored in it's CAM table, and in
some cases not even ARP's. The standby router ends up having to unicast
broadcast out the traffic to all ports (to include the secondary uplink
that is blocking on the other side). The active router should (and does
since you know ping works) forward this on to the destination port that
the MAC is seen on. Why you don't get a response on a traceroute, is
just a "feature". Maybe something to do with the TTL, though I would
doubt it since it's all L2 at that point. If you have access to the
remote systems, I would run tcpdump/ethereal on it to see if you receive
the traceroute packet, and what the response is from the system.
Due to the inefficientness of the routing (flooding) of the stanby
router, we've just avoided setting it up this way, and changed the cost.
Sam Stickland wrote:
> With HSRP, both the VLAN interfaces are (up, up), it's just that from
> the customers perspective the default gateway's IP address only lives on
> the active router. This means that traffic from the outside can be
> routed in via the standby router. Traffic from the customer will, or
> course, only ever go out via the active router.
>
> Increasing the OSPF cost on the standby router is the correct way to try
> and avoid this situation.
>
> It still confuses me as to why the traceroute through the standby switch
> doesn't complete.
>
> S
>
> Kanagaraj Krishna wrote:
>
>>Hi Sam,
>> The setup you described is the exact setup that we have
>>here. I don't have "ip verify unicast reverse-path" enabled. The
>>problem is if the vlan on switchA is on standby and switchB on active,
>>switchA should not be seen a path to reach the customer unless the
>>port on switchB goes down. Am I right? In my case both path were being
>>seen and sometimes the trace from outside goes through
>>switchA reaching the active switch using the trunk port. When this
>>happens, although the host is reachable but the trace result does not
>>look good which my customer is curious about. Thats the reason I've
>>increased the OSPF cost on switchA vlan interface to make it less
>>prefered. Usually if HSRP is configured on the physical port itself,
>>would the standby port be (down,down) or (up,up) without any traffic
>>passing through? Thanks again.
>>
>>Regards,
>>Kana
>>
>> ----- Original Message -----
>> *From:* Sam Stickland <mailto:sam_mailinglists at spacething.org>
>> *To:* Kanagaraj Krishna <mailto:kanagaraj at aims.com.my>
>> *Cc:* cisco-nsp at puck.nether.net <mailto:cisco-nsp at puck.nether.net>
>> *Sent:* Tuesday, November 07, 2006 6:09 AM
>> *Subject:* Re: [c-nsp] HSRP issues on Cisco3550
>>
>> Hi,
>>
>> The higher OSPF cost can be a good thing, since it stops traffic
>> routing
>> assymmetrically and makes the traffic paths a little more
>> predictable.
>> However, it shouldn't be neccessary to get this working. I assume
>> your
>> layout is something like this?
>>
>> OSPF Uplink OSPF Uplink
>> | |
>> SwitchA === Trunk === Switch B
>> | |
>> | |
>> +-------- Customer ---------+
>>
>> Let's say the customer is using VLAN 10, so you have "int vlan 10"
>> configured on both of your switches, with Switch A having a higher
>> HSRP
>> preference, and a lower OSPF cost on it's uplink.
>>
>> In this setup it shouldn't make any difference regarding which switch
>> traffic ends up on. Traffic destined to the customer should be
>> able to
>> end up on either Switch A or Switch B, which will then transit the
>> the
>> traffic to the customer.
>>
>> The only thing that could mess this up is uRPF (ip verify unicast
>> reverse-path). If you were running this - in it's default
>> configuration
>> - you would find that you could not ping either the primary or
>> standby
>> HRSP address (depending on which uplink the traffic took), but it
>> wouldn't actually affect traffic destined to the customer.
>>
>> None of this really explains your problem - is your setup more
>> complicated than you have described? What are the sizes of the
>> subnets
>> in use? Do you have any routes pointing to the customer or are they
>> numbered out of your address space?
>>
>> S
>>
>> Kanagaraj Krishna wrote:
>> > Hi,
>> > The same routing of the customer subnet is configured on both
>> the switch
>> > (OSPF). Usually in normal circumstances where HSRP is configured
>> on the
>> > physical interface, the standby interface will be down (this
>> OSPF route will
>> > become inactive). In our scenario, we are using vlan interface
>> on both switch.
>> > When i run "sh standby", it can be seen that one of the vlan is
>> in standby
>> > mode but because the physical interface and vlan is up, the
>> route is still
>> > active (redundant path). For temporary measures, I've set higher
>> ospf cost on
>> > the standby vlan interface. Is this the right way?
>> >
>> > Regards,
>> > Kana
>> >
>> >
>> >> Kanagaraj Krishna wrote:
>> >>
>> >>> Hi,
>> >>> I have an issue with our HSRP setup between 2 Cisco
>> Catalyst 3550
>> >>>
>> >> (trunk between them). The IP addresses are configured on the
>> customers vlan
>> >> interface in the switches. A customer will have 2 different
>> connection to
>> >> each switch (one active and the other standby). Whenever we try
>> to reach the
>> >> customer subnet using traceroute from location A, its ok if the
>> trace got
>> >> through the active switch. The issue is that, when from
>> location B if the
>> >> trace takes the standby switch it does not complete " * ".
>> Although a ping
>> >> from location B is successful. Any idea whats happening?
>> >>
>> >>> Note: Both the switches advertise the customer subnet using
>> OSPF. By right
>> >>>
>> >> only the routes from switch with the active ports is supposes
>> to be seen. But
>> >> in this case because the ip addresses are configured on the
>> VLAN and its up
>> >> in the standby switch as well, some packets reaches the switch
>> and then goes
>> >> to the active switch through the trunk port.
>> >>
>> >>>
>> >>>
>> >> Perhaps a uRPF check is dropping the traffic? Have you enabled "ip
>> >> verify unicast reverse-path"?
>> >>
>> >> S
>> >> _______________________________________________
>> >> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> <mailto:cisco-nsp at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
More information about the cisco-nsp
mailing list