Hsrp traffic behavior

[kmb405]

Hello,

I am trying to understand the behavior of switches in HSRP. I have two core l3 switches running HSRP for VLAN 350. I have multiple switches that host this VLAN connected to both core l3 switches. However, I have one switch that is only connected to core 1. Core 2 is the active member of the HSRP pair. There is an l2 link between both core switches.

1. Is the active router still forwarding the traffic from the single connected switch?

2. If so, why is the active router not learning mac's?

3. Should it not update the mac table for links coming across the link between cores?

I have attached a diagram with generalized connections. 

[MHM Cisco World]

core 2 will forward traffic not core 1,

hsrp is GW, 

so for Sw the GW through core 2 “since it only connect to it”

core 2 get frame/packet and forward form it side.

[MHM Cisco World]

Return traffic is challenge where it instead of go to core 2 it will go to core 1 and through L2 link between core 1 and core 2 the traffic forward to core 2 then finally to SW.

[Richard Burts]

There are certainly some things about this environment that we do not know and which might impact the answers that we give. But based on the diagram posted I would expect that core2 would be forwarding traffic for vlan 350 to destinations outside of vlan 350.

The original post asks some questions some of which assume some things not described in the diagram or the original post. 

1) Is the active router still forwarding the traffic from the single connected switch? 

If a device is connected in vlan 350, is connected to the single connected switch, correctly configured with IP address, mask, and gateway, then when it want to communicate with some resource not in vlan 350 then I would expect this device to send the IP packets with the destination mac address set to the mac of the HSRP virtual address. I would expect the single connected switch to forward the frame to core1 and core1 to forward it to core2.

The question seems to imply that this is not happening. But we have no information about this.

2. If so, why is the active router not learning mac's?

We have no information about the active router (actually switch) is not learning mac addresses. To evaluate this we would need information about the configuration of each switch, about trunking between switches, about physical connectivity.

3. Should it not update the mac table for links coming across the link between cores?

I would expect that the mac address table should be updated for traffic coming across the link between cores. If that is not happening we need more information about the switches, their configuration, and physical connections.

[kmb405]

Hey Richard,

I have updated the diagram with some information; however, I am not sure this is what you need. I have changed IPs as I cannot put my production info on the public forum. 

If there is anything that I can get to help with a conclusion, please let me know. 

I am not getting mac entries for the device off switch one when I ping it from a device on another subnet. 

[MHM Cisco World]

---

This dig above, 
Host connect to SW "SW meaning access SW"
the process as following:-
1-Host ask for ip address
2-dhcp send ip address to host with the ip address of GW,
this ip address since you config the HSRP have VIP "virtual ip address"
3- host now have ip address and ip address of GW.
4- host want to send frame/packet to other subnet.
5- host don't have the mac address of VIP of GW
6- host spend arp ask the mac address of the VIP

7-Here 
a- if the SW connect to both Core "1 & 2"
then the SW will flood to both Core and ONLY active will response with the mac of VIP "this mac address is also can manually config"
b- if the SW connect only to Core 2 "not connect to core 1", then the SW flood the packet to core 2,
Core 2 is not active for this harp group it can not reply 
So
through the L2 link between the Core 1 and Core 2, the Core 2 send the arp request toward Core 1
"""MAC address add to Core 1 from L2 connect to Core 2"""

8- now the host have VIP and mac address of VIP
9- prepare the frame/packet with
source "host ip address & mac address"

destination "ip address the host want to connect not same it subnet & mac address of the VIP"
10- SW receive this frame/packet and forward thought port-VIP mac address.
11- here:-
a- the SW connect to both Core, since the Core 1 reply to arp request only so the SW will add the mac address of VIP to the port toward the Core 1, and Core 1 receive the frame/packet and forward to other subnet.
b-the SW connect to only Core 2, the SW forward this frame/packet to Core 2.
NOTE:-
here the Core 2 see frame/packet, it will see that it have SVI of it and hence always forward packet to other Subnet.

the trick here -->

the Core 1 not see anymore packet from Host so the Mac address with aging and delete from Mac-address table 

and this why we don't see the Mac of host in Core 1.

hope this helpful.

[paul driver]

Hello

TBH that diagram is hard to follow however based on hsrp features if you don’t have an priority set on the group then the highest ip of the routers in the hsrp group will become the active rtr for so in this case it would be core 1

you don’t mention if preemption is enable as by default it isn’t also you dont state what version of hsrp your are running ?

As regards the switchs cam tables being updated then i would think a GARP would be broadcasted out to update the switch ports facing the hsrp rtrs to what port and rtr is serving the hsrp vip address. which would be then be propagated to other switches including the the old port facing the previously hsrp master 

[Richard Burts]

@paul driver 

Perhaps the diagram was updated/changed since you made your post. But when I look at the diagram core 1 is 10.10.1.2 and core 2 is 10.10.1.3. So it is appropriate that core 2 is the active member.

to the original poster - your updated diagram has some more information but not nearly enough for us to understand your issue. Changing the IP addressing should not be a problem for us, as long as the addresses are consistently changed. And since these devices appear to be part of an inside network I wonder about the need to change the addresses. Does your network use Public IP addressing for devices on the inside of the network?

If you ping the host device at 10.10.1.190 from outside does the ping succeed?

[paul driver]

Hello

@Richard Burts I did see the diagram, however i must have assoicated the higher ip with core 1 instead of core 2. But the process regards unsolicated broadcasted gratuious arp would still occur as such the switches should update thier own cam to accomodate the failover.