[c-nsp] HSRP issues on Cisco3550

[Kanagaraj Krishna]

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 
  To: Kanagaraj Krishna 
  Cc: 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
  >> https://puck.nether.net/mailman/listinfo/cisco-nsp
  >> archive at http://puck.nether.net/pipermail/cisco-nsp/
  >>
  >>     
  >
  >
  >