Talk to me about "bridge mode" in FWSM

[jfraasch]

I am wondering what the benefits of bridged mode are in both the FWSM and the ACE implemenation. I am so used to routing everything that I have never used the bridge feature.

For my particular case I will have two server farms hanging directly off the 6513 on VLAN 1000 (about 50 servers). Users will come in on trunked ports to the 6513 on VLANS 100 and 101 (about 500 users).

I have redundant 6513s that will be sitting at a primary data center and redundant 6513s sitting at the DR site. Services will be 100% duplicated at the DR site but in different VLANs.

I get how the ACE would work as a bump in the wire because of the VIPs. I am having a hard time figuring how the firewall would do it...but dont worry, I am working my way through the 710 page guide right now!

Just some general thoughts would be appreciated.

James

[t814687]

James, here is a good reference for the bridge option with traffic flows explained for both ACE and FWSM, hope that helps.

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/ACE_FWSM.html#wp1024527

Both ACE and the FWSM can be deployed in either bridged or routed mode. Bridged mode is selected here to simplify the Layer 3 topology. Consider the following when making this choice:

•Network Address Translation (NAT)-The FWSM does not currently perform NAT in bridged mode. If this is required, FWSM must be deployed in routed mode today, although NAT support will probably be added in the future.

•Routing support-ACE does not support any routing protocols-static routing only. FWSM supports a routing protocol (OSPF). By confining the routing function to the Catalyst 6500 and simply bridging flows across the contexts, there are no constraints on which routing protocol can be deployed, so here the decision was made to have the service modules bridge all the traffic. For the VRF routed design, the VRF sees the global MSFC as an OSPF neighbor across the bridged ACE and FWSM contexts; no actual routing is done on the service modules themselves. EIGRP or other routing protocols can be supported as well.

•Number of interfaces per context-There are no practical limitations on the number of bridged or routed interfaces on an individual ACE context. It can bridge two interfaces together and route between others. An FWSM context can support either bridging or routing, but not both. The number of bridged interface pairs is limited to eight with FWSM 3.1. As a result, if there are going to be more than eight interfaces on a given FWSM context, routed mode is required.

•Loops in the aggregation layer-Introducing back-to-back service module contexts in bridged mode allows the possibility of loops. Although normally there will not be a loop because the standby context does not forward traffic, the event of an active-active scenario between the primary and secondary contexts opens up this possibility. This can happen when heartbeat messages are lost and both contexts believe the other is down. This scenario is mitigated by forwarding BPDUs, but if the intention is to completely remove the possibility of a loop, at least one of the contexts (either ACE or FWSM) must be placed in routed mode.