Understanding HSRP, VRRP, and GLBP.

So I've been playing around with redundancy in my lab and I'm trying to figure out what happens during fail-over on the host's end. In HSRP and VRRP that both create a single virtual MAC that the host can arp for. So I'm assuming that when a failover is complete, there is no new ARP entries to be updated on the access-layer switch or host. Is this correct? The standby router just begins to answer. But if you have 2 routers and two L2 switches with a mesh topology (see below) how does that work?

(R1)-------(R2)
  |\        /|
  | \      / |
  |  \    /  |
  |   \  /   |
  |    \/    |
  |    /\    |
  |   /  \   |
  |  /    \  |
  | /      \ |
  |/        \|
(S1)-------(S2)
  |          |
  |          |
(HostA)      |
           (HostB)

If failover occurs, will S1 know that the virtual MAC is now reached through the diagonal link or will there be some ARPing going on? Not that it really matters, just thinking that if I disable gratuitous arps on my routers, then there won't be an update sent to S1 or S2 when the failover occurs. Am I on the right track?

Thanx

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

SteveThing

To continue on with this, in regards to GLBP, how does the ARP scenario work? Is it strictly based off of ARP time outs for the hosts and when it expires it will send an ARP to the AVG (primary) and get a new MAC? Also, how do the switches fit into this? Do they strictly work on MAC tables and skip the ARP process all together and let the hosts do all the work (more specifically L3 switches like 3550s)?

Met44

SteveThing wrote: »

if I disable gratuitous arps on my routers, then there won't be an update sent to S1 or S2 when the failover occurs. Am I on the right track?

In the case of VRRP, the backup will immediately send an advertisement message when it is promoted to master. In your scenario, I suspect this will update the switches, since the advertisement is sent with the source MAC set to the virtual mac address.

SteveThing

Met44,
Send an advertisement to whom? HostA?

APA

SteveThing wrote: »
So I've been playing around with redundancy in my lab and I'm trying to figure out what happens during fail-over on the host's end. In HSRP and VRRP that both create a single virtual MAC that the host can arp for. So I'm assuming that when a failover is complete, there is no new ARP entries to be updated on the access-layer switch or host. Is this correct? The standby router just begins to answer. But if you have 2 routers and two L2 switches with a mesh topology (see below) how does that work?
(R1)-------(R2)
  |\        /|
  | \      / |
  |  \    /  |
  |   \  /   |
  |    \/    |
  |    /\    |
  |   /  \   |
  |  /    \  |
  | /      \ |
  |/        \|
(S1)-------(S2)
  |          |
  |          |
(HostA)      |
           (HostB)
If failover occurs, will S1 know that the virtual MAC is now reached through the diagonal link or will there be some ARPing going on? Not that it really matters, just thinking that if I disable gratuitous arps on my routers, then there won't be an update sent to S1 or S2 when the failover occurs. Am I on the right track?

Thanx

Assuming you trunked vlans correctly between switches and your HSRP groups are tied to an interface per router... then yes... when S1 loses itś direct link to R1, HSRP should flip over to R2.

When S1 loses link to R1, the interface should go down and MAC entry removed from the table, the new HSRP primary router should automatically send a gratuitous arp as soon as it obtains the primary role but say it doesn´t........ well then.......as the hosts probably are still sending traffic destined to the virtual MAC, S1 now floods these frames out all ports except the one the frame was received on as it is an unknown unicast address.

Once the new HSRP primary router either sends a gratuitous arp or responds with the source mac being the HSRP virtual mac, mac address tables on the switches will be updated accordingly and the switch will then know to get to the HSRP virtual MAC it is is to use whichever port the L2 forwarding table now references.... no more unicast flooding...

That is essentially HSRP failover in a nut shell.... and VRRP failover..... Although with VRRP terminology changes a bit...

Met44

SteveThing wrote: »

Send an advertisement to whom?

To the VRRP multicast group. The advertisement will happen to hit host A assuming there is no multicast pruning being done on the switches, but as you pointed out earlier, the hosts will continue to send to the virtual mac without needing to know that anything has failed over.

Heero

Keep in mind that the only purpose of the advertisement when backup ----> master (or whatever terminology) is to update the mac address tables on the switches. The hosts will still send traffic to the same virtual MAC address, it's just the switches that need to know where that traffic needs to go (new master). The new VRRP master just sends it out multicast (essentially broadcast) so every switch in that subnet will know it's new path to the VRRP Virtual Gateway.

SteveThing

I didn't even account for the nature of switches... durh! I don't need to worry about disabled gratuitous arps then. What about when you are tracking a WAN link and R2 takes over for R1 without S1 losing a link to R1? Does R1 just pass it along to R2?

I don't mean to ask such rediculous questions, just trying to get a clear image in my head.

APA

More often than not... your tracking of the WAN link would either involve a shutdown of the circuit or a seamless decrement of HSRP\VRRP priority...

Thus R2 would advertise it has become master\primary router for the relevant networks...via gratuitous arp

No such thing as stupid or ridiculous questions.... (well most of the time)..... those who aren't willing to ask questions often don't go far in life....

SteveThing

I appreciate the help guys. I've been playing with HSRP and VRRP on my lab. Unfortunately, I my 3550s don't support GLBP. I'll have to yank a couple spare 4500s or 6500s off the shelf at work and play with it there.

Thanx a bunch.

stuh84

Or you could configure GLBP on routers

SteveThing

I was thinking about doing that too. I will probably do both just so I get the feel for it on both levels. I've got a few 3640s, but they are setup for a frame relay lab I'm not finished with yet.

SteveThing

Ok, working on GLBP and came across something I don't know is possible.

Take my diagram above and assume that R1 and R2 have a serial WAN link each. Is there a way to setup interface tracking (like in HSRP/VRRP) and if so, how does that play out with load balancing?

If R1's WAN link dies, is there a way to make R2 the AVG and "disable" round robin until the link comes back up? Or does R1 just route everything through R2 irregardless of what GLBP is doing (assuming there is a route)?

I have read over cisco's docs on setting up GLBP, but it doesn't cover interface tracking or this specific scenario.

Any insight?

SteveThing

After some more researching and testing, I have a better understanding of GLBP, but still getting wrapped up in weighting/tracking.

It is my understanding that you set your initial weight and the tracking decrements that value by X. So:

track 1 interface FastEthernet0/0 line-protocol
track 2 interface Serial0/0 line-protocol

interface FastEthernet0/0.10
 description LAN Segment
 encapsulation dot1Q 10
 ip address 10.0.0.2 255.255.255.0
 glbp 10 ip 10.0.0.1
 glbp 10 timers msec 150 msec 500
 glbp 10 priority 110
 glbp 10 preempt
 glbp 10 weighting 100 lower 90
 glbp 10 authentication md5 key-string *******
 glbp 10 weighting track 1 decrement 20
 glbp 10 weighting track 2 decrement 20
end

That should drop my weighting to 80 if either s0/0 or fa0/0 go down (or 60 if they both do). Now, what does that mean? More to the point, why does the router stay as AVG when I yank the cable? I see it doesn't work like HSRP/VRRP in that regard, is that be design? Where am I going wrong?