05-20-2010 09:51 AM
In CSM we have a default-gateway per Client VLAN, in ACE there is no equivalent command! How does the ACE handles routing in this situation?
Solved! Go to Solution.
05-20-2010 02:15 PM
Hi,
Talk about a deja-vu. I was faced with the exact same challenge about a year ago.
Basically, I think you're looking at two options:
1) Firewall-consolidation - Consolidate your four firewalls into one, having one dedicated interface towards the ace and route all your vips using the ace as
next-hop. It looks like your firewalls are virtual (but I don't know), so it's duable. But I don't know if this is even an option for you.
2) Per. clientvlan context - Context A for vlan1001, Context B for vlan1002 and so on. Each context handles clienttraffic for the respective vlan and since
each context handles it's own routingtable, simply use the firewall-address as your default route. But from your drawing, it looks like your server-vlans
are all connected to the same ace, so you will need to split that up. Assign each servervlan to an ace-context as you do with the clientside-vlans.
Well, a third option would be NAT in your firewall. Unless you have a specific need for the original client-ip the reach the ace, you could nat incoming clientsessions in each of the firewalls to an interface-address on that firewall, hence the ace will see the clientrequest as originating from the firewall and since ace has connected routes to each of the firewall, it wall return traffic to respective firewall and leave it to him to return the traffic to the client.
Since each firewall will present the packets with a unique NAT'ed address, you can apply different policies, parameters etc. for that NAT-address, if this is required.
hth
/Ulrich
05-20-2010 12:04 PM
By clientside, I take you it mean incoming traffic.
One option would be to configure all your clienside VIP-addresses on the same interface. Simply configure each clientside address as a VIP in your class-map and bundle them into one or more multi-match policies and apply them to your clientside ingress traffic. See example below:
class-map MATCH_VIP1
match virtual-address 1.1.1.1 tcp eq xx
class-map MATCH_VIP2
match virtual-address 2.2.2.2 tcp eq xx
class-map MATCH_VIP3
match virtual-address 3.3.3.3 tcp eq xx
policy-map type multi-match PMAP_VIPS
class class-map MATCH_VIP1
... [parameters] ...
class class-map MATCH_VIP2
... [parameters] ...
class class-map MATCH_VIP3
... [parameters] ...
interface vlan yyy
service-policy in PMAP_VIPS
I'm assuming you have a Layer3-device in front of your ACE, so you need to configure a few static routes using the ACE-clientside vlan address as next-hop. And the ACE would use that Layer3-device as its default route.
Works for me, hope it will for you.
/Ulrich
05-20-2010 01:46 PM
The problem is quite different... We have several Layer 3 routers (actually Firewalls) in the client side, all of them can be the default-gateway:
The ACE needs to know how to "route back to the client".
Regards,
Antonio
05-20-2010 02:15 PM
Hi,
Talk about a deja-vu. I was faced with the exact same challenge about a year ago.
Basically, I think you're looking at two options:
1) Firewall-consolidation - Consolidate your four firewalls into one, having one dedicated interface towards the ace and route all your vips using the ace as
next-hop. It looks like your firewalls are virtual (but I don't know), so it's duable. But I don't know if this is even an option for you.
2) Per. clientvlan context - Context A for vlan1001, Context B for vlan1002 and so on. Each context handles clienttraffic for the respective vlan and since
each context handles it's own routingtable, simply use the firewall-address as your default route. But from your drawing, it looks like your server-vlans
are all connected to the same ace, so you will need to split that up. Assign each servervlan to an ace-context as you do with the clientside-vlans.
Well, a third option would be NAT in your firewall. Unless you have a specific need for the original client-ip the reach the ace, you could nat incoming clientsessions in each of the firewalls to an interface-address on that firewall, hence the ace will see the clientrequest as originating from the firewall and since ace has connected routes to each of the firewall, it wall return traffic to respective firewall and leave it to him to return the traffic to the client.
Since each firewall will present the packets with a unique NAT'ed address, you can apply different policies, parameters etc. for that NAT-address, if this is required.
hth
/Ulrich
05-20-2010 03:27 PM
Hi,
Cause the firewalls are physical, the second alternative seems to be the best (with the third one, we loose client info and that could be a problem to some apps).
Thanks,
Antonio
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide