I am experiencing a severe Unicast Flooding problem in two Catalyst 6500 with a FWSM installed in each of them. Here is the analysis of the problem :
- CH01FW01 and CH01FW02 are two Firewall contexts in two FWSM Modules running version 3.2(6) and configured in active -standby mode of operation. CH01FW01, the primary firewall is installed in the Catalyst SW01, while CH01FW02, the standby firewall is installed in the Catalyst FW02. Both Catalyst run IOS 12.2(33)SXH
- The outside interface of the firewall cluster is on VLAN 300 (10.56.5.0 /24), while the inside interface is on VLAN 400 (10.56.9.0 /24).
On VLAN 300, each Catalyst has a VRF with an interface vlan 300 configured : CH01RT01 on Catalyst SW01 and CH01RT02 on Catalyst SW02.
- The VRFs have a static route to VLAN 400, pointing to the primary firewall. Communication through the firewall.
- The problem is that when packets are sent to VLAN 400, I observe Unicast Flooding on all ports assigned to VLAN 300! Similarly, I observe Unicast Flooding on all ports assigned to VLAN400.
- Unicast Flooding usually occurs when the mac-address table does not have an entry for the destination MAC address on a VLAN. It is exactly what I observe in the switch : the Catalyst does not learn the MAC address of the FWSM installed in the same chassis ! Strangly enough, the Catalyst does learn the MAC of the standby FWSM in the other switch (via the trunk linking both switches).
- The FWSM responds to ARPs from the VRF :
CH01SW01#sh ip arp vrf CH01RT01 10.56.5.1
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.56.5.1 5 001f.6c67.bf80 ARPA Vlan300
- But the FWSM MAC address 001f.6c67.bf80) is NOT learned by the switch :
I have a issue with a fwsm at the moment. Customer has two transparent contexts and wants to route through both of them with the msfc in the middle. This does not seem to work. I think the fwsm does ip and vlan checking to make sure traffic is unique through the fwsm.
I think we have very different problems in fact. I never tried to route between two bridged networks, where two contexts are configured in bridge mode. i don't see the benefice of this setup, compared with a traditional routed design ?
In my case, the unicast flooding is due to the fact that the MSFC does not see the Port-Channel to the FWSM...In another similar client environment, when I enter the command : sh mac-address-table dynamic address 001e.bed6.ed80, where the mac address is the MAC of the firewall, I see that this MAC is behind a port-channel 308 :
My customer was using bridged FWSM's in order to route OSPF to the MSFC, they were peering with some ISP's who did not want them to use FWSM with OSPF enabled. This was the very original design, as we know dymanic routing is not supported in context mode.
My problem was due to the famous packet recirculation issue, we droped the FWSM into bus mode. They were using all span sessions on the box.
I just answer my own question in order to complete the case and to allow anybody experiencing the same problem to fix it.
As I mentionned in my analysis above, the unicast flooding effect is due to the fact that the catalyst does not learn the MAC address of the FWSM. This is a known bug (CSCsl39710). This bug occurs if another service module is in the switch. It was my case as we have also an ACE module inserted !
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...