[nsp] HSRP problem

Robert Larsen robert.larsen at ntlworld.com
Thu Dec 11 12:01:55 EST 2003


Yes, agreed that the routing problem in this case was caused by
misconfiguration.

There is an alternative configuration that uses up only one address: the VIP
and all clients are configured in, say 10.0.0.0/24 (with 10.0.0.254 being
the VIP and default gateway), but the physical interface addresses on the
two routers can be in a *different* subnet (e.g. 10.0.1.0/30).  The two
routers see eachother on the /30 subnet for the keepalives, and the clients
see their default gateway since it's on the same subnet.  Sounds a bit
weird, I know, but it really does work.  This address saving is great when
you're using public IPs.  The only disadvantage (when using VRRP) is that
the clients won't be able to ping their default gateway.

I gave the comparison with VRRP since I couldn't understand why you couldn't
ping the VIP (when it was different to the physical interface IPs), and it
took some time before I found out why, so I thought some people might be
interested...  ;-)

Agreed that SNMP management should be to loopback addresses, but again over
the years I've come across some management systems that need to have
"ping-ability" to each interface IP address for it to be able to report on
it - don't ask me what I think about that method!

Regards,

Rob.

-----Original Message-----
From: Bruce Pinsky [mailto:bep at whack.org] 
Sent: 11 December 2003 16:25
To: Robert Larsen
Cc: 'Roger'; cisco-nsp at puck.nether.net
Subject: Re: [nsp] HSRP problem


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

Robert Larsen wrote:

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

The routing *problem* as you call it is caused by misconfiguration.  The
virtual address is intended to be in the same subnet as the primary,
secondary, and workstation addresses.  That's the point....it's a default
gateway address for the subnet.  If you put it in another subnet, you must
know how to get to that other subnet, either via a gateway or by configuring
a route that make workstations think that is local to the wire.

Your issue with non-pingablility may be true for VRRP, but we're talking
about HSRP here.  Besides, if you are concerned about monitoring the router,
you should have an IP address assigned to the loopback and be pinging that
(as well as get SNMP traps for events like HSRP changes).

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

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



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

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

iD8DBQE/2JpPE1XcgMgrtyYRAv2oAJ93Pc4CxjNt3H2JB6R6fzUFt6oRUQCeODsg
KtCDnGH3YTspUsuVYU8GC+g=
=HrNF
-----END PGP SIGNATURE-----




More information about the cisco-nsp mailing list