ACE Multi-Context Shared VLAN?

[davemit]

I will be deploying the ACE with two virtual contexts in routed mode.  Each context will have its own separate server VLAN, but I am wondering if I can share the Client side VLAN  between contexts?  Is this possible, or does each context need it's own client VLAN for routing back to the network core?

I was planning on using VIPs selected from the Client VLAN subnet.  If I do share that VLAN between two contexts, would there be any issues with each context responding correctly to the VIP's configured on it?

Thanks!

[Cesar Roque]

Hi David,

You can use the same VLAN on different Context but each Context should have its own IP address.

http://tools.cisco.com/squish/880AF

Cesar R

[davemit]

Thanks for the answer.  Are there any issues with the two contexts responding to VIP's when they're assigned from the shared client VLAN?

[Marko Leopold]

Yes, you can not access the VIP on context A from context B. Or the VIP of context B from context A. That's forbidden by security reasons.

[davemit]

What do you mean by "can not access the VIP"?

If servers behind Context A need to talk to a VIP in Context B, will it not work in this scenario?

Thanks!

[Marko Leopold · Accepted solution]

Yep, you are right. Cisco says its forbidden by security reasons. So if you want them to talk together you better use two seperate VLANs.

[davemit]

Wow, okay thanks.  I will definitely set up separate VLANs for this!

[Cesar Roque]

Hello David

This is correct.  however, a easy way to fix this and still using the same VLAN is configuring the servers in both Context.

Cesar R.

[davemit]

Huh?  The Real Servers are in separate VLANS (one in each Context).  How would I "configure the servers in both contexts"?

[Cesar Roque]

Hi David,

To expalin this better, I have this two Contexts:

context test

  allocate-interface vlan 144

  member test

context test2

  allocate-interface vlan 144

  member test

The config of test is this:

rserver host test

  ip address 10.198.16.93

  inservice

serverfarm host test

  rserver test

    inservice

class-map match-all test

  2 match virtual-address 10.198.44.180 tcp any

policy-map type loadbalance first-match test

  class class-default

    serverfarm test

policy-map multi-match test1

  class test

    loadbalance vip inservice

    loadbalance policy test

    nat dynamic 1 vlan 144

interface vlan 144

  ip address 10.198.44.150 255.255.255.0

  access-group input Allow_Access

  nat-pool 1 10.198.44.180 10.198.44.180 netmask 255.255.255.0 pat

  service-policy input NSS_MGMT

  service-policy input test1

  no shutdown

ip route 0.0.0.0 0.0.0.0 10.198.44.4

The config of test2 is:

rserver host test

  ip address 10.198.44.24

  inservice

serverfarm host test

  rserver test

    inservice

class-map match-all test

  2 match virtual-address 10.198.44.181 tcp any

policy-map type loadbalance first-match test

  class class-default

    serverfarm test

policy-map multi-match test1

  class test

    loadbalance vip inservice

    loadbalance policy test

    nat dynamic 1 vlan 144

interface vlan 144

  ip address 10.198.44.160 255.255.255.0

  access-group input Allow_Access

  nat-pool 1 10.198.44.181 10.198.44.181 netmask 255.255.255.0

  service-policy input NSS_MGMT

  service-policy input test1

  no shutdown

ip route 0.0.0.0 0.0.0.0 10.198.44.4

From the rserver 10.198.44.24, I can get to the VIP of  Context test 10.198.44.180.

Here is the output:

ACE-M3/test# sh conn

total current connections : 2

conn-id    np dir proto vlan source                destination           state

----------+--+---+-----+----+---------------------+---------------------+------+

2584127    2  in  TCP   144  10.198.44.24:52872    10.198.44.180:80      ESTAB

2584134    2  out TCP   144  10.198.16.93:80       10.198.44.180:1029    ESTAB

The condition here is that the ACE is not the default gateway of the servers.  There is another L3 device that routes the traffic to the VIP.

Cesar R

[davemit]

Got it, thanks Cesar.  The difference is that you are running One-Arm Mode on both contexts.  I will be in-line routed mode, so if I understand properly I will need to have separate client VLANS for both contexts in order to avoid this problem.

[nickjacobs]

You can add a host route for the VIP of the other context via the upstream router on the context you want access from - it works (but its a bodge that relies on redirects and chews bandwidth!). Also if you run one context on one appliance in a HA pair, and the other context on another is another even bigger bodge that also works.

Re-address to non shared client VLAN is really the only solid way as you say.