cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1120
Views
0
Helpful
7
Replies

Transparent ACE - 2 VLAN's, 1 context, 2 VIPs

JOHN WAITE
Level 1
Level 1

Hi,

We have a 3 tier application that needs to be load balanced from client to middleware and from middleware to backend.

Usually we do this with multiple context's on the ACE.

This time we are doing this with multiple VLAN's within the same context. Is this possible?

setup

client VIP = 10.0.103.3 which is mapped to IRIS_Reporting serverfarm in VLAN47

middleware VIP = 10.0.103.4 which is mapped to IRIS_Web serverfarm in VLAN41

client VIP hits 10.0.103.3 and then middleware box then hits 10.0.103.4. First part is working fine but middleware cannot open connection to 10.0.103.4 VIP over tcp/80. In the ACE log i see the connection timing out...

Oct  5 2010 15:33:40 INTERNAL-LB: %ACE-6-302022: Built TCP connection 0x39181f for vlan347:10.0.4.18/49731 (10.0.4.18/49731) to vl

an47:10.0.103.4/80 (10.0.103.4/80)

Oct  5 2010 15:33:40 INTERNAL-LB: %ACE-6-302022: Built TCP connection 0x229206 for vlan41:10.0.4.18/49731 (10.0.4.18/49731) to vla

n341:10.0.103.4/80 (10.0.2.149/80)

Oct  5 2010 15:33:45 INTERNAL-LB: %ACE-6-302023: Teardown TCP connection 0x39181f for vlan347:10.0.4.18/49731 (10.0.4.18/49731) to

vlan47:10.0.103.4/80 (10.0.103.4/80) duration 0:00:05 bytes 104 SYN Timeout

Oct  5 2010 15:33:45 INTERNAL-LB: %ACE-6-302023: Teardown TCP connection 0x229206 for vlan41:10.0.4.18/49731 (10.0.4.18/49731) to

vlan341:10.0.103.4/80 (10.0.2.149/80) duration 0:00:05 bytes 232 TCP Reset

thanks,
John.

1 Accepted Solution

Accepted Solutions

This can work, but with some caveats, mostly concerning routing. First thing is regarding how do you ensure that client traffic hits the VIP when it does not belong to either subnets configured on ACE BVIs. Second, you need to ensure that return traffic from your server does not bypass the ACE. Third, the ACE should be able to reach clients over correct vlan if they are not on the same subnet as ACE BVIs. Here you have a default route to 10.0.4.62.

It seems that first two caveats are fine, but in order to fix the third thing, you might need to enable mac-sticky on the interface vlan 41. This will make the ACE return traffic to the same MAC address where it came from.

View solution in original post

7 Replies 7

Hello ,

The vlan 347 is the client side vlan ?

I think that there shouldn't be problems with this setup , if you have the VIPs on the same segment.

Dan

Hi Dan,

VLAN47 is client side (bridged to 347 server side)

VLAN41 is middleware client side (bridged to 341 server side)

VLAN 41 & 47 are on separate subnets.

Cheers,

John.

It would help if you show us your config. This should be possible in general, but the service-policy needs to be applied on the interface where you receive traffic. On ACE you cannot reach VIP applied on one interface through another interface.

Hi Ivan,

Here is the config,

access-list BPDU ethertype permit bpdu

access-list everyone line 10 extended permit ip any any

parameter-map type http HTTP_PARAM

  server-conn reuse

  case-insensitive

  persistence-rebalance

parameter-map type generic SSLID_PARAM

  set max-parse-length 70

parameter-map type ssl SSL_PARAM

  session-cache timeout 300

parameter-map type connection TCP_PARAM

  syn-data drop

  exceed-mss allow

rserver host BL-VAN-CDMSPBI1

  description IRIS Sharepoint Reporting Server

  ip address 10.0.4.15

  inservice

rserver host BL-VAN-CDMSPBI2

  description IRIS Sharepoint Reporting Server

  ip address 10.0.4.18

  inservice

rserver host BL-VAN-ITSM03

  description ITSM Reporting Server

  ip address 10.0.4.16

  inservice

rserver host BL-VAN-ITSM04

  description ITSM Reporting Server

  ip address 10.0.4.17

  inservice

rserver host VM-VAN-CDMSPNT1

  description IRIS Sharepoint Web Server

  ip address 10.0.2.148

  inservice

rserver host VM-VAN-CDMSPNT2

  description IRIS Sharepoint Web Server

  ip address 10.0.2.149

  inservice

serverfarm host IRIS_Reporting

  description IRIS Reporting Servers

  failaction reassign

  fail-on-all

  rserver BL-VAN-CDMSPBI1 80

    inservice

  rserver BL-VAN-CDMSPBI2 80

serverfarm host IRIS_Web

  description IRIS Front End Web Servers

  failaction reassign

  fail-on-all

  rserver VM-VAN-CDMSPNT1 80

    inservice

  rserver VM-VAN-CDMSPNT2 80

    inservice

serverfarm host ITSM_Reporting

  description ITSM Reporting Servers

  failaction reassign

  rserver BL-VAN-ITSM03 80

    inservice

  rserver BL-VAN-ITSM04 80

    inservice

class-map match-all IRIS_REPORTING_HTTP

  2 match virtual-address 10.0.103.3 tcp eq www

class-map match-all IRIS_WEB_HTTP

  2 match virtual-address 10.0.103.4 tcp eq www

class-map match-all ITSM_HTTP

  2 match virtual-address 10.0.103.1 tcp eq www

class-map type management match-any PING

  10 match protocol icmp any

  20 match protocol snmp any

policy-map type management first-match PING-POLICY

  class PING

    permit

policy-map type loadbalance first-match IRIS_REPORTING_HTTP-l7slb

  class class-default

    serverfarm IRIS_Reporting

policy-map type loadbalance first-match IRIS_WEB_HTTP-l7slb

  class class-default

    serverfarm IRIS_Web

policy-map type loadbalance first-match ITSM_HTTP-l7slb

  class class-default

    serverfarm ITSM_Reporting

policy-map multi-match int41

  class IRIS_WEB_HTTP

    loadbalance vip inservice

    loadbalance policy IRIS_WEB_HTTP-l7slb

    loadbalance vip icmp-reply active

    loadbalance vip advertise active

    appl-parameter http advanced-options HTTP_PARAM

    connection advanced-options TCP_PARAM

policy-map multi-match int47

  class ITSM_HTTP

    loadbalance vip inservice

    loadbalance policy ITSM_HTTP-l7slb

    loadbalance vip icmp-reply active

    loadbalance vip advertise active

  class IRIS_REPORTING_HTTP

    loadbalance vip inservice

    loadbalance policy IRIS_REPORTING_HTTP-l7slb

    loadbalance vip icmp-reply active

    loadbalance vip advertise active

    appl-parameter http advanced-options HTTP_PARAM

    connection advanced-options TCP_PARAM

interface vlan 41

  description Client-Side VIP for Internal WEB LB

  bridge-group 2

  no icmp-guard

  access-group input BPDU

  access-group input everyone

  service-policy input PING-POLICY

  service-policy input int41

  no shutdown

  ip route inject vlan 41

interface vlan 47

  description Client-Side VIP for Gen Applications LB

  bridge-group 1

  no icmp-guard

  access-group input BPDU

  access-group input everyone

  service-policy input PING-POLICY

  service-policy input int47

  no shutdown

  ip route inject vlan 47

interface vlan 341

  description Server-Side for Internal WEB

  bridge-group 2

  no icmp-guard

  access-group input BPDU

  access-group input everyone

  service-policy input PING-POLICY

  no shutdown

interface vlan 347

  description Server-Side for Gen Applications

  bridge-group 1

  no icmp-guard

  access-group input BPDU

  access-group input everyone

  service-policy input PING-POLICY

  no shutdown

interface bvi 1

  ip address 10.0.4.58 255.255.255.192

  alias 10.0.4.59 255.255.255.192

  peer ip address 10.0.4.57 255.255.255.192

  no shutdown

interface bvi 2

  ip address 10.0.2.186 255.255.255.192

  alias 10.0.2.187 255.255.255.192

  peer ip address 10.0.2.185 255.255.255.192

  no shutdown

ip route 0.0.0.0 0.0.0.0 10.0.4.62

I think that this wont work.

The "Internal WEB" wont be functional.

The return traffic to clients from both segments ( Internal WEB and Gen Applications ) will exit the BVI1 in this case

This can work, but with some caveats, mostly concerning routing. First thing is regarding how do you ensure that client traffic hits the VIP when it does not belong to either subnets configured on ACE BVIs. Second, you need to ensure that return traffic from your server does not bypass the ACE. Third, the ACE should be able to reach clients over correct vlan if they are not on the same subnet as ACE BVIs. Here you have a default route to 10.0.4.62.

It seems that first two caveats are fine, but in order to fix the third thing, you might need to enable mac-sticky on the interface vlan 41. This will make the ACE return traffic to the same MAC address where it came from.

Thanks for reminding me about the mac-sticky command. Yes we need to ensure traffic return path is consistant with multiple interfaces and that fixed it.

Cheers,

John.