[nsp] HSRP problem

Pete Templin pete.templin at texlink.com
Thu Dec 11 07:26:26 EST 2003 

OK, I tend not to stray from the simple stuff, but how can you have the VIP and RIP (real IP address) be the same?

In non-HSRP circles, assigning two routers the same address would cause Real Problems (tm).  I don't see how adding a third representation (HSRP) of the same address will cause the first two to not collide.

How would setting the VIP to the master physical interface cause pings to succeed if the master is up but to fail if the master is down?  HSRP responds to pings just fine for me if it's not the same as the physical interface, so why wouldn't a slave HSRP box not respond to pings if it assumed Active HSRP state?

Pete Templin
Senior Staff Engineer
TexLink Communications
(210) 892-4183
pete.templin at texlink.com


-----Original Message-----
From: Robert Larsen [mailto:robert.larsen at ntlworld.com]
Sent: Thursday, December 11, 2003 2:52 AM
To: bep at whack.org; 'Roger'
Cc: cisco-nsp at puck.nether.net
Subject: RE: [nsp] HSRP problem

There's also no reason why the virtual IP address (VIP) - or shared HSRP
address - cannot be the same as one of the physical interface IP addresses.
That way, you're not using up one extra IP address and you don't end up with
this routing problem.

As a side note, if one uses a non-Cisco router and is configuring VRRP, then
you will *not* be able to ping the VIP address - this is in accordance with
RFC 2338.  However, there is an exception to this: if the VIP is the same as
the physical interface IP address of the *master* router, then you will be
able to ping the VIP (effectively, you are pinging the physical interface
IP).  If the master goes down and the standby/backup router becomes master,
then you will *not* be able to ping the VIP (since it's not the same as the
master's physical interface IP anymore).

By configuring the VIP to be the same as your master router's physical
interface IP gives you some useful info during any fault diagnosis: if you
can ping the VIP, then there's been no switch of master router; if you
cannot ping the VIP, then the master router has switched over to your
standby/backup router.

With Cisco's HSRP, you can ping the VIP even though it is a different
address to the master's physical interface address.

Cheers,

Rob.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Bruce Pinsky
Sent: 10 December 2003 21:06
To: Roger
Cc: cisco-nsp at puck.nether.net
Subject: Re: [nsp] HSRP problem


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roger wrote:

| Ed Ravin wrote:
|
|> Are "shared hsrp address" and "primary ip address x.x.x.x" in the
|> same subnet?
|
| No - seperate subnets.
|
|> If not, have you configured routing for the shared HSRP address?
|>
|>
| Ahh - changing the hsrp address to one within the subnet fixed things.
|
|> The last time I tried stuff like this, it didn't work unless I used
|> an HSRP address that was in the same subnet as one of the primary or
|> secondary addresses on the interface.  What does:
|>
|>  show ip route <shared HSRP address>
|>
|>
|>
| Yes it was pointed to Null 0 - on both active and standby routers-
| which was fairly strange...
|
|> show?
|>
|>
| That is a limitation... when HSRP address have to be in the same
| subnet..  Now I'm aware of that things will move along quickly!
|

Well, that is the generally accepted way of doing it.  The point is that the
HSRP address is a virtual default gateway address for hosts on that subnet.
Hence, the HSRP address should be part of the subnet for the hosts that need
to get off the local subnet.  If it were in a different subnet than the
hosts that need to reach it, they would need a route to the subnet for the
HSRP address.

However, in looking at your issue, I was successful in using an address is a
different subnet.  The workstation or router that was trying to ping the
HSRP address needed to believe that it could ARP on the local wire however.
~ That required static route pointing to interface to make it work.  Kinda
defeats the purpose of HSRP.

R2#sh standby
Ethernet0/0 - Group 0
~  State is Active
~    2 state changes, last state change 00:07:48
~  Virtual IP address is 132.108.5.2
~  Active virtual MAC address is 0000.0c07.ac00
~    Local virtual MAC address is 0000.0c07.ac00 (bia)
~  Hello time 3 sec, hold time 10 sec
~    Next hello sent in 0.008 secs
~  Preemption disabled
~  Active router is local
~  Standby router is unknown
~  Priority 100 (default 100)
~  IP redundancy name is "hsrp-Et0/0-0" (default)


R3#sh ip int bri
Interface        IP-Address      OK? Method Status                Protocol
Ethernet0/0      132.108.4.3     YES NVRAM  up                    up
Ethernet1/0      142.108.10.3    YES NVRAM  up                    up
Loopback0        3.3.3.3         YES NVRAM  up                    up
Virtual-Access1  unassigned      YES unset  up                    up

R3#sh ip route static
~     132.108.0.0/16 is variably subnetted, 2 subnets, 2 masks
S       132.108.5.0/24 is directly connected, Ethernet0/0

R3#ping 132.108.5.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.108.5.2, timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/22/32 ms

| Thanks!
|
|


- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)

iD8DBQE/14qlE1XcgMgrtyYRAuXQAJ0WRYkooiKJ5xWKhdsvGupE36bJHwCdHy5d
BRpls47j2wKuGxszEOqLnvg=
=Qpx3
-----END PGP SIGNATURE-----

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


_______________________________________________
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