FWSM > ASASM migration query

[Neil Preston]

Hi, we are migrating from the Cisco FWSM > Cisco ASASM, the FWSM is operating in transparent mode and we are using multiple contexts, the local MSFC is providing layer 3 services via appropriate SVI's. 

As this is part of a larger scale migration stratedgy we currently have the FWSM and ASASM in different 6500 series switch chassis's that are interconnected at layer 2.

We have tried to take a phased approach and migrate on a per context basis leaving behind the layer 3 SVI's on what will eventually be the legacy switch, this appeared to work fine in a lab environment and during migration however we now have users reporting intermittent comms issues specifically for systems that reside within the migrated ASASM firewall contexts.

My concern is that the issue may be due to us not having the layer 3 SVI's on the local switch housing the ASASM at this time, does anybody know if the approach we have taken is valid or should we be looking at moving over the layer 3 SVI's on the switch at the same time?

[prashant dwivedi]

Hello ,

have you got it working ? I have same issues , planning to replace layer 3 firewalls to layer 2 mode.

Looking for any reference documents..

[Neil Preston]

Hi Prashant, sounds like you are doing something different to me, we are effectively migrating from the FWSM to the ASASM as is ie not going from a layer 3 firewall topology to a layer 2 firewall topology.  That said I can provide an update on the problem I posted:

To a large extent it works, we had functional comms when we migrated users onto the ASASM (transparent mode) even though the SVI's for those ASASM VLAN interfaces existed on a 6500 series switch that was not housing the ASASM modules. 

Unfortunately though we did experince intermittent packet loss across various systems in the region of 3-10% post migration which was significant enough to have to regress the change.  We have ended up raising a case with Cisco TAC originally to ask the question 'is this a valid topology or would we expect to see packet loss issues such as the ones we observed?' The feedback from Cisco is that in theory as long as the L2 connectivity between the switches is setup correctly they cannot think of any reason as to why it wouldn't work and indeed our experience indicates it does work and thus our current thinking is that we are experiencing some other problem that is causing our packet loss which we are still investigating.

[Neil Preston]

I found my problem and worked around it, it was nothing to do with our migration approach in the end, more details below:

The problem I had was due to a change in the behaviour of the local MSFC that is providing the L3 DFG services via VRRP for hosts connected beyond the transparent FWSM/ASASM.  The change is with respect to the MAC address used by the L3 gateway for routed traffic that is sent to the real hosts, for whatever reason when the hosts are active via the FWSM the majority of L2 frames from the MSFC are sourced from a MAC address of the VRRP DFG virtual MAC, when we migrate users onto the ASASM this changes to be the real MAC address of the VLAN interface.  

The upshot of this is that intermediate switches in the L2 path between DFG and host do not mainatin a consistent CAM table entry for the DFG VRRP MAC which will always be used by the host as a destination MAC address for non local (routed) traffic, as intermediate switches in the L2 path no longer see the DFG VRRP MAC address as a source MAC address in frames from the DFG it ages out the CAM table popping up every now and again when they see an ARP request from a host and the ARP reply which as per RFC5798 must use the VRRP MAC as source.

Flooding does not help in our scenerio as one of the intermediate switches between DFG and host is an internal bladeframe virtual switch which does not appear to apply 'flooding' practices not that we particulary want such a situation anyway.  ARP requests from the host resolves the problem temporarily as the ARP reply from the DFG uses the VRRP MAC as per VRRP RFC but again within 20mins or so that will age out.  The end result is packet loss in our environment.  

To resolve this issue we have allowed the VRRP advertisements to pass through the firewall onto the host VLAN, technically they are not required here as there are no VRRP consumers on the host side VLAN of the firewall but as per RFC5798 these VRRP advertisements must contain the source MAC address of the VRRP virtual MAC which means we have a reliable consistent flow of traffic from the VRRP virtual MAC address (source) propogated across our host L2 network resulting in all intermediate switches having knowledge of where to send host packets bound for non local subnets.

Another resolution would have been to use HSRP as a FHRP with BIA, hope this may help someone out there if they have a similar setup or problem.

[Marvin Rhoads]

Great followup explanation - thanks for sharing. +5