ACE design issue

Unanswered Question
Apr 27th, 2010
User Badges:

Hi,


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.

sshot-2.png

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Gilles Dufour Tue, 04/27/2010 - 08:58
User Badges:
  • Cisco Employee,

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.


Gilles.

Peter Koltl Tue, 04/27/2010 - 13:54
User Badges:
  • Silver, 250 points or more
  • Community Spotlight Award,

    Member's Choice, March 2016

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?

Ivo Grossmann Wed, 04/28/2010 - 09:30
User Badges:

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.

Actions

This Discussion