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 :
CH01SW01#show mac-address-table address 001f.6c67.bf80
Legend: * - primary entry
age - seconds since last seen
n/a - not available
vlan mac address type learn age ports
No entries present.
- From the VRF, we can ping a host on VLAN 400 across the firewall :
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.56.9.223, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
- Unicast packet seen on port Gi 9/48 in access mode on VLAN 300 :
Frame 10231 (84 bytes on wire, 84 bytes captured)
Ethernet II, Src: Cisco_b8:0b:00 (00:1e:4a:b8:0b:00), Dst: Cisco_67:bf:80 (00:1f:6c:67:bf:80)
Destination: Cisco_67:bf:80 (00:1f:6c:67:bf:80)
Source: Cisco_b8:0b:00 (00:1e:4a:b8:0b:00)
Type: IP (0x0800)
Internet Protocol, Src: 10.240.4.37 (10.240.4.37), Dst: 10.56.9.223 (10.56.9.223)
Does anyone know what the problem could be ? Why does the switch not learn the FWSM MAC address ?
Thank you in advance for any help
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.
This could be your problem as well.
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 :
vlan mac address type learn age ports
* 901 001e.bed6.ed80 dynamic Yes 0 Po308 <----- Po308 !
But in the failing environment, the MSFC does not see the firewall MAC address behind a port-channel...
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 !