Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

ACE design issue


my question is about design.

At the left side, the server and the ACE vlan interfaces are directly  connected to

the same vlan. VIP traffic flow is green, server  management is brown.

The problem is, that with this design i'm restricted to one server vlan per context,

because the server gateway is the ACE and the ACE-gateway is the server-vlan-interface

at the core.


When the VIP is used, traffic flow is:

1) World is routed to the VIP-VLAN Interface on the core

2) Core sends traffic to the VIP

3) ACE sends traffic to the server through server-vlan-interface

4) server sends back to the ACE

5) ACE sends back to core through the VIP VLAN

6) core sends traffic to worl, everything is fine

Now our server admins want to administrate from different locations:

w/o adding host routes to the core:

1) Admin tries to connect to the server

2) World is routed to the Server-VLAN Interface on the core

3)  Core sends traffic to the server

4) server send traffic to default-gw (ACE)

5) ACE drops traffic due to seeing traffic in only one direction, saying no matching session

Todo: Add host route into core to force the traffic to use the ace for

every single server.

with adding host routes to the core:

1) Admin tries to connect to  the server

2) World is routed to the Server-VLAN Interface on the core

3)  Core sends traffic to the ACE server-VLAN-interface, due to host route

4) ACE sending to the server

4) server send traffic to default-gw (ACE)

5) ACE to core via server-vlan-interface (default route), core to world and everything is fine

Now its impossible to add another Server-VLAN interface to the ACE, because the destinations

are all the same (world) and the gateway on the ACE have to be the VLAN routing instance, the core.

So i have a default route to one server-vlan-interface on the core and all traffic passing the ACE uses

this gw. The result is, that the traffic is blocked by our Firewall.

My plan is now to implement a transit-VLAN (shown on the right side of my pic) for making

my job easier (no host routes, no server admin needed (!) to change gateways..... ) and

overcome the different kind of problems.

My question is now:

Is ensured that the ACE will see all it's traffic ?

I think all should be fine, because the traffic path is unique.

Thanks for reading ^^ and for posting some opinions.

regards from germany

Cisco Employee

Re: ACE design issue

If I understand correctly, the servers would not be directly connected to the ACE anymore.

Their gateway would not be the ACE anymore.

Problem with this is to guarantee that server response to a *world* request goes back to ACE.

Without any specific action/config, this won't happen.

The server will forward its response to its gateway which will send it directly to the outside world, bypassing ACE and creating the same asymetry you're trying to solve.

To solve this, you will need to do source nating on ACE.

But then your servers will lose information about client source ip address (no more stats based on that info).

Unless if you configure header insert and modify the server to read that info in each request.

As you can see this is not quite easy.

You could try bridge mode.

Create another vlan, and bridge it (BVI) with existing server vlan.

Keep the servers in their original vlan and connect the gateway to the new vlan (without changing ip addresses).

ACE will then be in the middle of GW and ACE.



Re: ACE design issue

Why don't you choose the simplest option: ACE is the only gateway to the server VLAN and the core has no VLAN interface in that VLAN?

New Member

Re: ACE design issue

I can't use bridge mode, because i can only bridge two vlans which brings back

the problem of having multiple server-vlans on one context whithout creating new

VLANs in the LAN.

All other options (moving server vlans) would require a lot of changes in our LAN,

because we having round about 50+ server VLANs (a conservative estimate) and

my solution should be future-proof. My goal is to minimize the efford and maximize the advantage.

Maybe i can use PBR on the core.

"As you can see this is not quite easy"

You are so damn right.

CreatePlease to create content