[c-nsp] HSRP issues on Cisco3550

[Sam Stickland]

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/
>     >>
>     >>    
>     >
>     >
>     >  
>