ACE 4710/Module Routed vs. Bridged Mode

[robert.horrigan]

I understand routed vs bridged mode configuration fairly well, however, I do not understand the pros/cons between using them.  Can someone please provide comments and a link to describe pros and cons installing these load balancers in routed or bridged mode?  I would appreciate any feed back.

/r

Rob Horrigan

[chrhiggi · Accepted solution]

Hello Ron!

  Realistically, there is no pro/con to running either.  ACE does not behave differntly in one vs. the other (The CSM did act differently, the CSS and ACE don't.)  The choice relates to how your want to deploy the ACE within your current network configuration and how much you need/want to change.

  Here are a few food for thought items:

-=Routed Mode=-

-VLANs can be shared between contexts.

-Servers behind ACE use ACE as a gateway.  That means that you have to change the subnet/gateway on your server to point directly to ACE and create a new IP subnet on the server/ACE. (note that the server would not have to be L2 adjacent necissarily, but you will need to create 2 subnets on ACE and the server should be behind one of them in a manner where all traffic to/from the server only traverses that path.  If the routing behind the server has a path around the ACE, you will have to use source NAT or PBR to make sure loadbalanced flows are symetric.)

-Non-loadbalanced flows can be NATted

-Access to the servers chagnes because of the new subnet.  You can configure static NAT on ace to reach the servers via the old IP's if needed - or update the routing within the network to reach the servers through ACE.

-=Bridged Mode=-

-VLANs that are bridged can not be shared between contexts.

-Servers behind ACE use the same gateway as previously.  The only change to the existing topology is L2 VLANs.  You will put your servers on a new L2 vlan behind ACE. ACE will bridge the new VLAN with the existing VLAN to allow traffic flow.

-Non-loadbalanced flows can not be NATted. (this is probably the only real limitiation between bridged and routed.)

-Clients can access the servers directly, the same as before the change, no special routing/natting will need to be done.

Regards,

Chris Higgins

[robert.horrigan]

Chris,

Thanks a lot, exactly what I needed. 5of5.

/r

Rob

[pzpgd1mlf]

Hello Guys,

Can both mode coexist per context? For example, having 10 contexts in bridge mode and 10 contexts in routed mode, also, knowning all their limitation and difference as previously described. Or does it have to be either one or the other? I have gone through the design guides but I did not find any imperative answer. Please, would mind sharing your thoughts?

Thank you

[chrhiggi]

Yes and no.

You can share routed vlans across multiple context.  You can also bridge together vlans in each context uniquely. However, you cannot use either vlan in a bridged pair in any other context at the same time.

i.e.

Admin

route vlan 3 (say this is your management vlan)

context C1

bridge vlans 1 and 2

route vlans 3, 4, and 5

bridge vlans 6 and 7

context C2

route vlans 3, 4, and 10

bridge vlans 11 and 12

context C3

route vlans 3, 9, 10, and 13

context C4

route vlan 3

bridge vlans 14 and 15

  The idea behind being able to use a routed vlan in more than 1 context is that any traffic headed into a context will be doing so via the destination MAC address pointing to the interface IP on a specific context.  In other words, it is routed into the context from an external entity.

  In bridge mode, packets that are not desine directly to a Vlan or Virtual address are bridged to the second vlan in the BVI. Since there is no specific destination context for this type of packet, there would be no way to define which context to send it to as it physically enters the ACE.  Hence, you can never use the same vlans in more than 1 BVI at a time.

Hope that helps!

Chris

[ivan.garrido]

Hi Cristopher,

We have an scenario with two CAT65000 in HA, with one FWSM and one ACE mod in each one.

The ACE mod has two bridged context; inside context and dmz context.

The inside context has VLAN 41 for client side and VLAN 42 for server side.

The dmz context has VLAN 50 for client side and VLAN 52 for server side.

Both had configured "bridge-group 1" to bridge both VALN in each one.....

The last sunday we maked a  configuration for add two new context to the ACE Mod, appling the next commands:

In CAT6500

no svclc vlan-group 30 41,50,99

no svclc vlan-group 40 42,51,62

svlclc vlan-group 30 40,41,46,50,99

svlclc vlan-group 40 39,42,47,51,62

after that...we can see loggs in the CAT6500, like that:

dmz : %ACE-4-412001: MAC 00.1d.45.37.0e.80 moved from vlan50 to vlan51.

and after,  this same MAC moved from vlan 51 to vlan 50 ,  from vlan41 to vlan 42 and from vlan 42 yo vlan41 too....!!!!!! in different context!!!

this event, that appear like a l2 loop impact to  any service on vlan50 and vlan42..

after we reload the FWSM and ACE module, and after of reload some servers in vlan 50 (DHCP server), the service was restored.

I think that configuration of the same brigge-grouo 1 in each context, are triggering a l2 loop...between both two context..

Please can you tell me your feeback.

Thanks !!!

Iván

Regards.

Iván

[chrhiggi]

Ivan-

  Too many moving pieces to the puzzle to know for sure.  One thing to keep in mind... ACE utilizes the same MAC address for all VIPs, interfaces, and NAT pools across a single context.  If you didn't have both vlans in the bridge in the svclc vlan group, then you open it up, the switch at that point will always see the same mac off 2 different vlans. However, it should never see it bounce across different ports on the switch for the same single vlan.  I would somewhat assume something like proxy-arping on the firewall could be a culprit here, but I would need a set of traces on the vlans involved to konw for sure.