Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

Unicast Flooding -- HSRP -- Assymetric routing

Dears

Would like your assistance please in understanding unicast flooding behavior

According to below URLs it should only occurs If we are having HSRP load-balancing between both routers or asymmetric routing.

 

http://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/10583-62.html#t8

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/23563-143.html

 

Explanation makes sense however whats confuses me that even if we are using single router or HSRP where all all active groups are on one router still this behavior should occur. According to my understanding is that when packet is L3 switched from one VLAN to another source MAC is lost that's why it erased from CAM table after CAM age timer. So this behavior should occur in all cases , right ?

 

Regards

Many Thanks

Sherif Ismail

1 ACCEPTED SOLUTION

Accepted Solutions
Community Member

Hi bro Sherif :) ,Based on

Hi bro Sherif :) ,
Based on the URL u list, the issue is not in the HSRP and asymmetric routing , the main issue (unknown unicast flooding)  occurred when the asymmetric routing  happened even without using the HSRP in ur design, but in the first URL, it discuss the unknown unicast flooding  when the asymmetric routing  happened when u use the HSRP in ur design.
So let's discuss ur question:
U said that if u have two or more routers and u create multiple HSRP groups on these routers, but only one HSRP-speaking router is the active for all the groups u configured, so assume that we have 2 VLANs (VLAN1 and VLAN2) as on the document, so let's take the example in the document as our scenario but at this case  MSFC-1 is the active one for the two HSRP groups , so assume that all the caches (ARP cache) and tables (CAM table) r empty for all the devices, so assume that host A(10.1.1.10/24) need to ping host B(10.1.2.10/24) so it must forward the packet to its gateway (MSFC-1 at our example) but it must know the MAC address of MSFC-1, so it send ARP request to  know the MAC address of MSFC-1, then MSFC reply with its MAC address via ARP reply packet, then MSFC-1 need to make the L2 rewrite as the packet is originated from VLAN1 and is destined to VLAN2, MSFC-1 know that host B(10.1.2.10/24) is on the same VLAN (VLAN2), so it can reach it via the L2 level, this mean that it has to send ARP request to know the MAC address of host B, then host B reply with its MAC address via the ARP reply packet, then the ICMP-echo request packet (of the ping tool) is sent to host B, then host B send the ICMP-echo reply packet to MSFC-1  because MSFC-1 act as its gateway (remember that MSFC-1 is the active HSRP for all the configured group), let's take the example from values point of view:
assume we talk about continous ping from host A to host B:
MAC of host A : 0000.0000.000A
MAC of host B : 0000.0000.000B
MAC of interface VLAN1 of MSFC-1 : 0000.0000.0001
MAC of interface VLAN2 of MSFC-1 : 0000.0000.0002 

so neglect the MAC addresses in the image
now, let's talk about  the sequence of the ICMP-echo request packet:
 1-host A send the ICMP echo request packet toward MSFC-1
the frame:
source MAC: 0000.0000.000A 
destin MAC: 0000.0000.0001 (for VLAN1)
source IP:10.1.1.10
destina IP:10.1.2.10 
2-MSFC-1 forward the ICMP echo request packet toward host B
the frame:
source MAC: 0000.0000.0002 (for VLAN2)
destin MAC: 0000.0000.000B
source IP:10.1.1.10
destina IP:10.1.2.10
now, let's talk about  the sequence of the ICMP-echo reply packet:
1-host B send the ICMP echo reply packet toward MSFC-1
the frame:
source MAC: 0000.0000.000B 
destin MAC: 0000.0000.0002 (for VLAN2)
source IP:10.1.2.10
destina IP:10.1.1.10 
2-MSFC-1 forward the ICMP echo reply packet toward host A
the frame:
source MAC: 0000.0000.0001(for VLAN1)
destin MAC: 0000.0000.000A
source IP:10.1.2.10
destina IP:10.1.1.10
This mean that Switch1 send frames to host B and host B send frames to Switch1, this mean that the CAM table of  Switch1 is refreshed (during the continous ping between host A and host B) because host B always send frames to Switch1, this mean that before the 5 minutes of CAM table age timer expire, the entry  (2 0000.0000.000B dynamic 1/1) associated to host B in Switch1 CAM table is refreshed, this mean that unknown unicast flooding doesn't occurred here.
Because at the example in the document, host B send direct frame to MSFC-1 only at the first, when host B send  the ARP reply to MSFC-1, but during the operation of the contious ping, the host B send the frame to MSFC-2 not to MSFC-1, this mean that the entry   (2 0000.0000.000B dynamic 1/1) associated to host B in Switch1 CAM table is not refreshed, this mean that once the 5 minutes of the CAM table age timer expired, so MSFC-1 start to make the unknown unicast flooding as the entry asscoiated to host B is not present in the CAM table of MSFC-1

hope that is helpful
BR
Mostafa :)

 

:

2 REPLIES
Community Member

Hi bro Sherif :) ,Based on

Hi bro Sherif :) ,
Based on the URL u list, the issue is not in the HSRP and asymmetric routing , the main issue (unknown unicast flooding)  occurred when the asymmetric routing  happened even without using the HSRP in ur design, but in the first URL, it discuss the unknown unicast flooding  when the asymmetric routing  happened when u use the HSRP in ur design.
So let's discuss ur question:
U said that if u have two or more routers and u create multiple HSRP groups on these routers, but only one HSRP-speaking router is the active for all the groups u configured, so assume that we have 2 VLANs (VLAN1 and VLAN2) as on the document, so let's take the example in the document as our scenario but at this case  MSFC-1 is the active one for the two HSRP groups , so assume that all the caches (ARP cache) and tables (CAM table) r empty for all the devices, so assume that host A(10.1.1.10/24) need to ping host B(10.1.2.10/24) so it must forward the packet to its gateway (MSFC-1 at our example) but it must know the MAC address of MSFC-1, so it send ARP request to  know the MAC address of MSFC-1, then MSFC reply with its MAC address via ARP reply packet, then MSFC-1 need to make the L2 rewrite as the packet is originated from VLAN1 and is destined to VLAN2, MSFC-1 know that host B(10.1.2.10/24) is on the same VLAN (VLAN2), so it can reach it via the L2 level, this mean that it has to send ARP request to know the MAC address of host B, then host B reply with its MAC address via the ARP reply packet, then the ICMP-echo request packet (of the ping tool) is sent to host B, then host B send the ICMP-echo reply packet to MSFC-1  because MSFC-1 act as its gateway (remember that MSFC-1 is the active HSRP for all the configured group), let's take the example from values point of view:
assume we talk about continous ping from host A to host B:
MAC of host A : 0000.0000.000A
MAC of host B : 0000.0000.000B
MAC of interface VLAN1 of MSFC-1 : 0000.0000.0001
MAC of interface VLAN2 of MSFC-1 : 0000.0000.0002 

so neglect the MAC addresses in the image
now, let's talk about  the sequence of the ICMP-echo request packet:
 1-host A send the ICMP echo request packet toward MSFC-1
the frame:
source MAC: 0000.0000.000A 
destin MAC: 0000.0000.0001 (for VLAN1)
source IP:10.1.1.10
destina IP:10.1.2.10 
2-MSFC-1 forward the ICMP echo request packet toward host B
the frame:
source MAC: 0000.0000.0002 (for VLAN2)
destin MAC: 0000.0000.000B
source IP:10.1.1.10
destina IP:10.1.2.10
now, let's talk about  the sequence of the ICMP-echo reply packet:
1-host B send the ICMP echo reply packet toward MSFC-1
the frame:
source MAC: 0000.0000.000B 
destin MAC: 0000.0000.0002 (for VLAN2)
source IP:10.1.2.10
destina IP:10.1.1.10 
2-MSFC-1 forward the ICMP echo reply packet toward host A
the frame:
source MAC: 0000.0000.0001(for VLAN1)
destin MAC: 0000.0000.000A
source IP:10.1.2.10
destina IP:10.1.1.10
This mean that Switch1 send frames to host B and host B send frames to Switch1, this mean that the CAM table of  Switch1 is refreshed (during the continous ping between host A and host B) because host B always send frames to Switch1, this mean that before the 5 minutes of CAM table age timer expire, the entry  (2 0000.0000.000B dynamic 1/1) associated to host B in Switch1 CAM table is refreshed, this mean that unknown unicast flooding doesn't occurred here.
Because at the example in the document, host B send direct frame to MSFC-1 only at the first, when host B send  the ARP reply to MSFC-1, but during the operation of the contious ping, the host B send the frame to MSFC-2 not to MSFC-1, this mean that the entry   (2 0000.0000.000B dynamic 1/1) associated to host B in Switch1 CAM table is not refreshed, this mean that once the 5 minutes of the CAM table age timer expired, so MSFC-1 start to make the unknown unicast flooding as the entry asscoiated to host B is not present in the CAM table of MSFC-1

hope that is helpful
BR
Mostafa :)

 

:

Community Member

Hi MostafaMany thanks for

Hi Mostafa

Many thanks for your deep analysis answer :)

I got it. So the issue is actually with the router who is doing the L3 routing. If both PCs GWs are one same router then no issues however If they are on different router then it would cause this unicast flooding issue. Makes perfect sense

What I still cant figure it out is that in our network we had below behavior

  • 2 HSRP routers where all groups were active on one router
  • Unicast flooding only occured on the active HSRP router. No issues reported on 2nd standby HSRP router !!
  • Once I increased CAM table to be equal or more than that of ARP, traffic decreased from 150 Mbps to 4 Mbps
  • Still sometimes we encounter some peaks that may reach to 23 Mbps

Questions

  • Why we faced this issue on 1st router only as R2 should also flood this traffic ?
  • Why we sometimes have peaks since we are not have in changes in STP ?
  • Why fix solved the issue when we should not have this behavior from beginning ?


BTW, as you are an expert in LAN issues, may you have a look please on below thread :)
https://supportforums.cisco.com/discussion/12338861/mac-address-table-synchronize

Many Thanks for your support

Regards
Sherif Ismail

677
Views
5
Helpful
2
Replies
CreatePlease to create content