HSRP Case

[kamal el assaad]

hello,

if i have 2 layer 3 switches and a set of layer 2 access switches in between so it forms a loop (the layer 3 on the edges of the loop and the layer 2 access switch in between as a physical connectivity), is that will affect the HSRP response configuration between the 2 layer 3 switches? 

what kind of problem may i face other than the delay of the response issue.

Note: the distance between the 2 layer 3 switches is around 5 KM.

best regards,

[marce1000]

 - Get sufficient knowledge on hsrp :
             https://community.cisco.com/t5/networking-documents/hsrp-overview-and-basic-configuration/ta-p/3131590

 M.

[Georg Pauwen]

Hello,

the response to HSRP packets (multicast address 224.0. 0.2 for HSRP version 1, and 224.0. 0.102 for version 2) will be the same as for any other traffic traversing that link. As long as there is layer 3 connectivity between both L3 switches, it comes down to what the physical link is capable of. 5 kilometers, e.g. if you use single mode fiber, the distanca can be up to 40 kilometers.

I would just send a ping from one L3 to the other L3 switch, and see what the response time is.

[kamal el assaad]

hello,

yeah its a single mode fiber, so nothing will affect the operation of HSRP right?

[Joseph W. Doherty]

Well RTT for 5 KM, on fiber, would be about 49 microseconds.

I don't recall HSRP being much concerned with RTT.  Generally, it's concerned with missed hellos.

So, in the case were the primary gateway fails, the secondary will take over roughly 25 microseconds later vs. being next to its primary on a LAN.  Do you see this additional 25 microseconds as a problem?

[paul driver]

Hello

To gain an accurate ttl responce time bewteen the two L3 devcies you can use IPSA

L3 Sw1
ip sla responder

L3 Sw2
ip sla 10
udp-echo <l3 Sw1>
ip sla schedule 10 life 30 start now

show ip sla statistics

[Joseph W. Doherty]

I wouldn't expect the 5 KM and/or additional switches to be any problem, except, perhaps, unless you use very "fast" timers (i.e. BFD) and/or the actual links congest such that the HSRP packets are subject to additional latency and/or drops.

If, because of the foregoing, secondary HSRP gateway believes the primary gateway has failed, then, of course, it may then try to take over as the primary gateway (which isn't good).