FWSM Transparent mode and Routed Access Layer help

[jt3rry]

Hello all, I'm working on a rather large deployment all Cat 65xx running IOS and designed around routed access layer. The core is a pair of 6509's each with FWSM, they need to run in transparent mode, and will be deployed in Active/Active mode. Being that I'm new to the Cat 6k and FWSM I'm in need of some help. From reading the documentation on the FWSM it looks like I need to use either VLANs, BVI interfaces or bridge-groups to define the firewalling between subnets. Since we aren't pulling any VLANs into the core (we are routing from access-layer to core) is it sufficient that I use "bridge crb" in the MSFC per routed interface, and base my FWSM rules on the bridge-group of that interface? It doesn't look like the Security Context is the way to go to handle the rules between the Subnets, but if there is a better way of handling this please feel free to add any input. Thanks!

[Jon Marshall]

Hi

I'm not sure this will work. Firstly from the 12.2SX configuration guide for 6500's

Layer 3 Interface Configuration Guidelines and Restrictions

When configuring Layer 3 interfaces, follow these guidelines and restrictions:

?Catalyst 6500 series switches do not support:

?Integrated routing and bridging (IRB)

?Concurrent routing and bridging (CRB)

?Remote source-route bridging (RSRB)

Secondly, the problem you have is that you need to allocate vlans to the FWSM before you configure the FWSM with the "firewall vlan-group x" command. In your scenario the vlans are not present on the 6500 switch.

We deployed the FWSM in our data centres and one of the main reasons we went with layer 2 access was due to the FWSM deployment. The only other option we had was to deploy the FWSM's in the access-layer, ie have a dedicated pair of 6500 switches for firewalled servers but this is not really scalable if you need to firewall all servers and you need multiple access-layer switches.

Regards

Jon

[jt3rry]

Jon, would you say that means I couldn't configure the following:

interface gig 1/1

description Dorm A

no switchport

ip address x.x.x.x

bridge-group 1

interface gig 2/1

description Dorm B

no switchport

ip address x.x.x.y

bridge-group 1

interface bvi 1

ip address x.x.x.z

Then base the FWSM rules on "Int BVI 1"? or is it once I use the "no switchport" command I'll not be able to assign those same interfaces to a bridge-group?

[Jon Marshall]

Justin

The reason I thought it wasn't possible is because the BVI in transparent mode is used for management in effect. You still are firewalling between two vlans in effect.

And to do this you need to allocate those vlans to the FWSM.

But the vlans aren't there. They are on the access-layer.

Is there anyway you could test your idea ?

Jon

[jt3rry]

Hi Jon, I should have the ability to test soon we are still receiving equipment. I'm getting conflicting info in regard to my project. Some say it can't be done, others say it can. Let's assume the BVI as I mentioned is not the approach I need to take. The FWSM will actually be moved to the "server" layer. Multiple links (layer 3) will exist between a pair of Core 65xx's and a pair of "server" 65xx's. I just found this in the "Data Center Networking: Integrating

Security, Load Balancing, and SSL

Services Using Service Modules" guide -

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns304/c649/cdccont_0900aecd800f252b.pdf

FWSM - MSFC Placement

One of the key elements that decide how the design works is the placement of the MSFC. The traffic hitting the aggregation switches from the core can hit the MSFC first and the FWSM second (MSFC-outside) or it can hit the FWSM first and the MSFC second (MSFC-inside). Typically the MSFC-outside design applies to the Intranet Data Center while the MSFC-inside applies to the Internet

data center.

It sounds like I need the MSFC-Outside approach for two reasons: Routing to the core, and equil-cost load balancing (remember we have many ether channel links between server/core all running EIGRP)

Another potential problem, we have many servers that will have a NIC teaming requirement, I will want such servers to sit on both "server" 65xx's so we need layer 2 communication between both 65xx in that layer, also trunking between these switches will be a requirement of the FWSM's fail over functionality.

I guess the question becomes will FWSM in transparent mode, active/active FWSM, and routed access-layer all play well together?

Thanks!

[Jon Marshall]

Hi Justin

Be interesting to see if it works or not with BVI. Let me know.

You definitely want the MSFC in front of the FWSM's otherwise you are in danger of routing between vlans via the MSFC and not the FWSM.

I don't see any issues with having a routed access-layer and your FWSM's in the access-layer in transparent mode. As you say as long as you have a layer 2 trunk between your two access-layer switches you should be fine.

Hope it all goes well and if you do get the BVI thing working let me know

Jon

[edwardwaithaka]

Hi jt3rry

I have found myself in the same situation as you were a while back.

We are migrating a network to a routed access design/layer3 access. In the existing setup, we have 2 x 6509 at the core with FWSM and IDSM. The dist and access layers consists of 3750s and 3560s mix.

Question is, how did you manage to make use of the service modules on a fully layer 3 network considering they are designed for layer 2 networks (VLANs).

Need assistance urgent. Thanks.

[jt3rry]

Edward, the deployment was actually fairly straight forward after digging through a few manuals. Our deployment actually shifted away from the core to a pair of L3 connected server chassis - so the same problem existed.

Basically the server/inside VLAN(s) need to be configured to not "route" - do not configure an Interface for this VLAN, rather we will bridge this VLAN through the FWSM to an "outside" VLAN, which will have an SVI on your local switch. In my example, I'm using two inside VLANS, and two outside VLANS. Where VLAN 55 is the outside, VLAN 56 is the inside - they are bridged together. (same for VLAN 65 & 66) hosts or servers "inside" the FWSM will connect to ports in either VLAN 56, or 66 - both these VLANS have no SVI, so the default gateway for these hosts need to point to the "bridged pair" SVI (interface vlan 55, or 65) since the FWSM is in Layer 2 transparent mode it will allow the same subnet to exist on either side.

- relevant 6500 config

firewall multiple-vlan-interfaces

firewall module 5 vlan-group 50

firewall vlan-group 50 55,56,65,66,505

interface Vlan55

description MSFC "outside" SVI for 10.14.x.x servers A

ip address 10.14.0.2 255.255.0.0

no ip redirects

no ip unreachables

no ip proxy-arp

delay 5

ntp disable

standby 55 ip 10.14.0.1

standby 55 timers msec 15 msec 200

standby 55 priority 150

standby 55 preempt delay minimum 180

!

interface Vlan65

description MSFC "outside" SVI for 10.18.x.x servers B

ip address 10.18.0.100 255.255.254.0

no ip redirects

no ip unreachables

no ip proxy-arp

delay 5

ntp disable

standby 65 ip 10.18.0.1

standby 65 timers msec 15 msec 200

standby 65 priority 150

standby 65 preempt delay minimum 180

- relevant FWSM config

firewall transparent

interface Vlan55

description Server VLAN 10.14.0.0 - Outside

nameif outside

bridge-group 1

security-level 0

!

interface Vlan56

description Server VLAN 10.14.0.0 - Inside

nameif inside

bridge-group 1

security-level 100

!

interface Vlan65

description Netscale VLAN 10.18.0.0 - Outside

nameif outside-2

bridge-group 2

security-level 0

!

interface Vlan66

description Netscale VLAN 10.18.0.0 - Inside

nameif inside-2

bridge-group 2

security-level 100

interface Vlan505

description LAN/STATE Failover Interface

!

interface BVI1

description FWSM Management Interface

ip address 10.14.0.8 255.255.0.0 standby 10.14.0.9

access-list bpdu ethertype permit bpdu

access-group bpdu in interface outside

access-group bpdu in interface inside

access-group bpdu in interface outside-2

access-group bpdu in interface inside-2

failover

failover lan unit primary

failover preempt 10

failover lan interface fail Vlan505

failover polltime unit msec 500 holdtime 3

failover polltime interface 3

failover interface-policy 1

failover replication http

failover link fail Vlan505

failover interface ip fail 192.168.250.1 255.255.255.252 standby 192.168.250.2

Also have a look at the attached diagram. Make sure you are allowing BPDU's through as this is critical to the FWSM transparent deployment, notice in the FWSM config we are "pairing" the inside/outside interfaces together using bridge groups. In this case I had two protected inside VLANS that needed separate ACLS and subnets, so we broke them out into a second inside/outside pair, each outside with its own SVI on the MSFC.

Hope that helps!

Thanks,

[jt3rry]

I should also add we ended up settling on single context active/standby for the FWSM modules, failover works like a charm

[edwardwaithaka]

Hi terry,

This helps a lot especially on my Serverfarm block which has layer 3 up to the aggregation layer.

Some clarification;

- It seems you decided to go with a collapsed core design (core & access layers only) and do away with the aggregation layer.

In my CAMPUS Block design there are three layers with a "layer-3/routed-access" design. The 6500 at the agg-layer have FWSM and the access consists of 3750/3560s. Question is, do the services modules support/work in a routed access design?

- In my SERVERFARM/DATACENTRE block, I also have 3 layers (Acc/Agg/Core) but luckily layer-3 ends at the aggregation level so I am assured the service modules will work. My main challege is that in this block I have both fwsm and "ACE" service modules.

If you have any heads up of FWSM in a routed access design with all three layers, kindly assist.

Thanks.