[nsp] HSRP problem
Robert Larsen
robert.larsen at ntlworld.com
Thu Dec 11 11:54:56 EST 2003
The Juniper configs we use track multiple egress interfaces, each having
various priority values that get subtracted from the router priority so that
we only switch to the standby router when we want to. For example, if a
transit interface goes down, you might want to switch immediately to a
standby router that has alternative transit, but if an IX peering interface
goes down you might deem it not critical enough to do the switch.
I left out the full tracking configuration to make the config easier on the
eye - and it was just to demonstrate the use of a VIP that was the same as a
physical interface address.
Of course, you can leave out the interface tracking all together, and then
you're relying on the master router itself (or the link between the master
and standby routers) going down before you make the switch. But in my
experience, it's egress interfaces that tend to have the problem, and that's
exactly when you want to switch to the standby router.
At the end of the day, HSRP/VRRP is pretty flexible - you can configure it
in many different ways to get it to achieve most things. For example, we
also use two VRRP groups, where under normal conditions router A is the
master and router B is the standby for group1, and for group 2 router B is
the master and router A is the standby. Clients can be configured to use
either the VIP of group A or the VIP of group B as their default gateway.
This achieves a level of load balancing for outgoing traffic - well, sort
of, anyway!
Regards,
Rob.
-----Original Message-----
From: Burns, Keith [mailto:Keith_Burns at icgcomm.com]
Sent: 11 December 2003 16:01
To: 'Robert Larsen'; 'Pete Templin'; cisco-nsp at puck.nether.net
Subject: RE: [nsp] HSRP problem
The only problem with doing this is if you are using "tracking" for the
egress interface. When the tracked interface goes down, the primary physical
ethernet doesn't go down, but the VIP would go to the secondary.
Keith Burns
Principal Network Architect
ICG Telecommunications
IP Ph: 303-414-5385
Cell: 303-912-3777
"The dogs may bark, but the caravan rolls on...."
> -----Original Message-----
> From: Robert Larsen [mailto:robert.larsen at ntlworld.com]
> Sent: Thursday, December 11, 2003 6:57 AM
> To: 'Pete Templin'; cisco-nsp at puck.nether.net
> Subject: RE: [nsp] HSRP problem
>
>
> >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/
>
>
> _______________________________________________
> 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