[nsp] HSRP problem
Robert Larsen
robert.larsen at ntlworld.com
Thu Dec 11 08:56:54 EST 2003
>From memory, on Cisco HSRP, you would do something like:
<--- on master router --->
interface fastethernet 0/0
ip address 10.0.0.1 255.255.255.0
standby 1 ip 10.0.0.1
standby 1 priority 105
standby 1 preempt
standby 1 track <WAN interface>
<--- on standby router --->
interface fastethernet 0/0
ip address 10.0.0.2 255.255.255.0
standby 1 ip 10.0.0.1
standby 1 preempt
Under both normal and failure conditions, you will be able to ping the VIP
address, since Cisco HSRP allow that.
A Juniper VRRP configuration would look something like this:
<--- on master router --->
interfaces {
fe-0/0/0 {
unit 0 {
family inet {
address 10.0.0.1/24 {
vrrp-group 1 {
virtual-address 10.0.0.1;
priority 105;
preempt;
track {
interface <WAN interface priority-cost 10;
}
}
}
}
}
}
}
<--- on standby router --->
interfaces {
fe-0/0/0 {
unit 0 {
family inet {
address 10.0.0.2/24 {
vrrp-group 1 {
virtual-address 10.0.0.1;
priority 100;
preempt;
}
}
}
}
}
}
Under normal conditions, you will be able to ping the VIP address, since it
is the same as the physical interface address. However, under failure
conditions where the standby router has taken over the VIP, you will not be
able to ping the VIP since it doesn't match the physical interface address
of the standby router (which is now the new master).
This is why (for VRRP) if the VIP is different from the physical interface
address, then you will never be able to ping the VIP (this is correct
according to RFC 2338). However, Cisco router will respond to pings
received to the VIP because Cisco decided to allow this under the HSRP
protocol.
Hope this clarifies my earlier post! ;-)
Regards,
Rob.
--
------------------------------------------------------------------------
Robert Larsen | T: +44 (0)20 7847 4513 | Epworth House, 25 City Road
Network Architect | M: +44 (0)7811 271057 | London, EC1Y 1AA, UK
HighSpeed Office | F: +44 (0)20 7847 4599 | www.highspeedoffice.com
------------------------------------------------------------------------
-----Original Message-----
From: Pete Templin [mailto:pete.templin at texlink.com]
Sent: 11 December 2003 12:26
To: Robert Larsen; cisco-nsp at puck.nether.net
Subject: RE: [nsp] HSRP problem
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