HSRP Role Change

[narsha]

In a HSRP setup when Active Fails and Standby takes over how does the end host knows that it's path has been changed?

[MHM Cisco World]

Hstp have three device 

Router which is hsrp router 

SW that connect two routers

Endpoint 

The whole idea of hsrp is making endpoint service not interrupted so when the hsrp role is change endpoints dont know and don't effect

But SW know the change of role' the hsrp router when it becomes active send GARP (hsrp VIP to Virtual MAC)' this make SW update port it learn from virtual MAC

And hence now traffic pass to new active hsrp.

MHM

[Joseph W. Doherty]

---

@narsha wrote:

In a HSRP setup when Active Fails and Standby takes over how does the end host knows that it's path has been changed?

---

Normally, the end-host wouldn't know, or normally care, that the path has changed.

If fact, that's the basic idea, i.e. the gateway has physically changed, but the end-host doesn't need to concern itself.

[David Ruess]

Hello,

Thats the idea behind the Virtual IP and MAC address. No matter which device owns it and is forwarding on behalf of them it is the same. Since switches work at L2 for this here is what happens.

1. Active Router fails

2. Standby router realizes the failure from the keepalives and it now forwards any device using that IP/MAC as its Gateway.

Another thing that happens is the new Active router will send a gratuitous ARP claiming that it now has that Default Gateway MAC/IP address. If it didn't then traffic would be dropped for a period of time. Because the L2 switch forwards traffic out 1 interface for that Virtual MAC, if that interface changes because a new Active device took over then it wouldn't know that MAC is out another interface without that Gratuitous ARP.

Hope that helps

-David

[Joseph W. Doherty]

"Because the L2 switch forwards traffic out 1 interface for that Virtual MAC, if that interface changes because a new Active device took over then it wouldn't know that MAC is out another interface without that Gratuitous ARP."

BTW, actually switch would know the MAC shifted to another port as soon as it sees an ingress frame.  This is accomplished by the gratuitous ARP's frame, i.e. switch doesn't care purpose of frame.

Also, BTW, depending on how HSRP (or other FHRPs are) is configured might take several seconds to switch over, which may, or may not, interrupt traffic.  It's also possible routing will redirect the traffic before HSRP flips.

[David Ruess]

---

@Joseph W. Doherty wrote:

BTW, actually switch would know the MAC shifted to another port as soon as it sees an ingress frame.  This is accomplished by the gratuitous ARP's frame, i.e. switch doesn't care purpose of frame.

---

I thought that's what I said. It WOULD know the MAC changed ports with the Gratuitous ARP to notify where the MAC is at any given time. Unless I misread your post. That ingress frame is from the GARP.

I think I stated it something as: it WOULD NOT know where the MAC is WITHOUT the Gratuitous ARP. The intent was there, the message may have been less than clear lol.

[Joseph W. Doherty]

"I think I stated it something as: it WOULD NOT know where the MAC is WITHOUT the Gratuitous ARP."

That's how I understood it, and such is technically incorrect.

What I thought was lacking possible clarity was that perhaps ONLY a gratuitous ARP would reset the switch's MAC table.  I thought it should be clarified the switch, for updating its MAC table would do so with any ingress frame.  I thought this important because a gratuitous ARP can do other things like changing the gateway's MAC on other host ARP tables.  Also this understanding is important for understanding something like GLBP, where GARP cannot be used because there can be multiple virtual MACs for a single virtual IP.

Also, of course, the switch and hosts would (eventually!) migrate to the new gateway port within needing any ingress frame when the virtual gateway changes.

To be clear, for HSRP, GARP is used, for multiple excellent reasons, but GARP, technically, isn't required.

[David Ruess]

Ah. Ok. Yeah I could have explained it with better clarity. Yes GARP is used for multiple purposes and a switch updates it’s MAC table with any ingress frame. 
I was leaning towards the specific function these roles play in HSRP. GARP can be used for gateway updating but HSRP uses it solely to update the switch MAC table. The frames will make it down to the PCs but nothing will change as their GW is still the same MAC/IP.

I think I used the words like “it won’t know where the Mac is otherwise” because the standby router won’t send frames with that HSRP Mac/ip combo while it’s in standby (otherwise the switch will see the same Mac on 2 ports). A GARP message from the standby is  basically the initial message to the switch saying to forward to it.

I am confused with you saying GARP isn’t required but I can’t find any other source that allows the Mac to be learned on the new port. From my understanding the standby can’t use the Mac/ip unless it’s the active router so no traffic will be generated towards the switch. 
Be curious to see in a lab disabling GARP on that port and seeing how it functions. TO THE LAB!

-David

[Joseph W. Doherty]

". . . and a switch updates it’s MAC table with any ingress frame."

Correct.

"I am confused with you saying GARP isn’t required but I can’t find any other source that allows the Mac to be learned on the new port."

Because of the first quote.

Consider, as HSRP is proprietary, when standby takes over, HSRP could have generated a proprietary frame, using about any destination MAC as long as that frame has the HSRP virtual MAC as it source MAC.  Again, the switch doesn't need it be a GARP frame.

Interestingly, by using a GARP, in theory, you don't need a virtual MAC, just provide real interface MAC.  From what I've read, Cisco chose not to do this as there was concern not all hosts would process the GARP.

BTW, if you're also wondering why I also wrote you don't need anything to have the switch over because both a switch's MAC table and a host ARP table will age out, but that causes delay, especially with typical ARP table timers.

So, to review, although a GARP frame causes the switch to update its MAC table, the switch doesn't care it's a GARP.

[David Ruess]

OK. That makes a little more sense along with some other digging I did. Surface level the Cisco docs say HSRP uses GARP (but other mechanisms can also trigger things). And I only meant to use GARP in the context of telling the switch a change in MAC->Port has occurred. While the end hosts would get it nothing changes for them. Yes I know the switch doesn't care what frame it is, it just sees a mac and port to associate with it. I was just using it in the contexct of the Standby router cant use the Virtual MAC until it becomes active, thus generating a frame to send to the switch.

Funnily enough I did do a lab and disabled GARP and regular ARP. When I shut down a port and doing the packet capture HSRP STILL sent out a GARP. Must be built into the protocol regardless if its disabled on the device. Nevertheless I learned something new. Thats @Joseph W. Doherty for making me use more than 10% of my brain this early in the morning!

[Joseph W. Doherty]

Well, I only brought this up because understanding what's really happening makes it easier to understand alternative approaches.  I.e. a particular implementation might not be the only way or perhaps the best way, especially as technology evolves.

For lab fun, try blocking the GARP with an ACL.

[David Ruess]

Some people just want to watch the world burn  haha

[narsha]

Lets say active Router never fails and Virtual MAC is with active router , in that situation will the physical interface's MAC address of the standby forwarded in to the other L2s or Standby will be sitting idle not share it's MAC address? 

[David Ruess]

Yes it would still learn the physical interface MAC address as you can send traffic to it as well and the switch would need to know what interface it resides in. Its just not used for the DG MAC address.

[MHM Cisco World]

this simple lab to clear confuse here 
R1 is standby and R2 is active 
you can see the R1 have two MAC one it own and other for R2 real MAC (and it real IP)
in other hand the R2 have three MAC, own and R1 real MAC and vMAC of VIP of HSRP

R2/R1 still have is real Mac ? Sure it always keep it real MAC in both case it is standby or active  
BUT 
endpoint use which ?
as I mention before the goal  of HSRP is make endpoint stable, this done by HSRP generate VIP and vMAC which is always still same whatever which router is active 
so endpoint use VIP/vMAC of HSRP not real IP/Mac of routers 
this VIP is push via DHCP or manually config in endpoint as GW, and vMAC the endpoint learn via ARP
if endpoint not learn this VIP and routers allow arp proxy then the endpoint can use any real IP of any routers in same VLAN if that routers enable arp proxy. 

MHM