One-armed ACE with servers gateway to ACE (no SNAT?)

Hello ACE experts, I have two questions;
Design;
One-armed ACE appliance where the servers use the ACE as default gateway? (and ACE of course a default route to the router)
Apparently it works in my lab… But since it’s not documented I wonder what the gotcha’s are?
(This would eliminate the SNAT requirement for one-armed)
I know I need;
-no icmp-guard                 to allow ‘asymmetric icmp’
-no normalisation            to allow asymmetric traffic when not using VIP (router to server is direct, but server response uses the ACE)
And other question;
Bandwidth license, apparently ALL traffic counts to this limit, even only routed traffic, is this true?
So In routed mode, all traffic from server backend that needs to be routed over ACE - a backup!? - counts?
Regards Kristof

Hi
the reason I use "process every packet" was it was one of the advantage being offerd by one arm mode to not to process every packet. The main reason for one arm deployment, as i mentioned previously also, is ease in placement of ACE. We can have servers in any vlan and can put ACE altogther iin different VLAN. i guess this advantage is of no use for you because servers are already in same segment as that of ACE.
The main cause ,which i understand, customer don't like the concept of SNAT is because of its restriction on reporting and security. Client IP will be hide, so any reporting on servers for sessions source (or for monitoring attacks) will not be fruitfull. Although with feaures like XFF we can overcome this fault for HTTP traffic, but still customers don't like the consept of hiding details of IP accessing their servers.
regarding B/w count in bridge mode i am not 100% sure but beleive here again every passing traffic will count as ACE still monitor every packet and decide whether its a passing traffic or part of loadbalancing or hitting any of its confiugred policy.

Similar Messages

  • CSS One Arm Configuration with VIP(non-shared)/IP Interface Redundancy

    With Reference to the following CCO documentation;
    1). "How to Configure the CSS to Load Balance Using 1 Interface"
    In this example, the Real Server's (10.10.10.2 etc) gateway are pointed to the router's gateway(10.10.10.1) and used the 'add destination service' command to NAT the RealServer's IP address back to the VIP (10.10.10.6).
    2). "Understanding and Configuring VIP and Interface Redundancy on the CSS11000".
    In the interface redundancy configuration, the gateway of the Real Server are configured as the CSS11000's Interface Redundancy Address (192.168.1.1), not the Router's gateway.
    Can anyone help to advise on the preferred one arm configuration with VIP/IP redundancy?
    (i). Is the reason for configuring the gateway of the Real Server to CSS11000's Interface Redundancy Address in 2) same as using 'add destination service' command in 1)? That is to make sure that the return path from Real Server back to Client passes through the CSS and is NAT back to the VIP.
    (ii). To configure VIP(non-shared)/IP Interface redundancy(Active/Backup Mode) in a one arm configuration, my understanding is that there are 2 methods of configuration. Is it correct? Which method is preferred?
    Method a)
    1.Configure the Real Server's gateway to Router's Gateway
    2.Configure 'add destination service' command on the CSS to NAT the RealServer's IP address back to the VIP
    3.Configure VIP(non-shared) redundancy for the VIP on the CSS
    4.IP Interface Redundancy on the CSS is not required as the Real Server's gateway is already pointing to the Router's gateway. (Assuming that HSRP redundancy is already running on the Router)
    Method b)
    1. Configure the Real Server's gateway to the CSS's IP Interface Redundancy IP Address
    2. Configure IP Interface Redundancy on the CSS (as the Real Server's gateway)
    3. Configure VIP(non-shared) redundancy for the VIP on the CSS

    if you use method a) (server gateway is the router) you need the CSS to nat
    the source ip address of the client in order to force the server to send traffic back to the CSS.
    The issue then is that the server does not see the IP address of real client.
    The server only see connections with source IP address = CSS ip address.
    With method b) you don't have the above problem, but connection initiated by the servers are sent to the CSS that will then send it to the router.
    You have a performance issue because the traffic will cross 2 times the one-armed interface.
    If this is a new design, it is strongly recommended not to use one-armed setup.
    Regards,
    Gilles.

  • ACE 4700 one-arm design with SSL termination

    Hi,
    We are evaluating the one-arm design for the ACE 4700 and need some clarifications:
    1. Are there any limitations in the one-arm design and the SSL offloading
    2. Can the ACE be configured with an IN and an OUT vlan to the router
    CLIENT -> Router -> ACE IN -> ACE OUT -> Router -> Server Vlan
    so that the SSL and the clear text traffic is in a separate Vlan?
    3. In some sample configuration i saw SNAT configuration on the ACE to modify the client IP. This i assume is for instructing the return traffic from the server to go through ACE? Using SNAT we eliminate the requirement for NAT or PBR on the router? Will i still be able to insert the client IP address after the SSL offload?
    I would appreciate if you can share some sample configs
    Regards,
    George Georgiou

    There are two ways to implement One Arm topology.
    1. One Arm with PBR & 2.One Arm with SRC NAT
    PBR/Source Nat is needed to ensure that the return traffic from Real Servers should not bypass ACE.
    1. Are there any limitations in the one-arm design and the SSL offloading
    The limitations/config issues I can think of are following
    One ARM with PBR:
    Direct access to Servers require the enabling of Assymtric routing (by turning off Normalization). If direct server access is not required then you dont need to enable assymtric routing. Now for these assymetric connection (Direct Server Access return traffic) its required to purge idle connections more frequently (default being one hour).
    One ARM with SRC NAT:
    You will loose the client information. Server logs will show the connections initiated from NAT IP Pool configured on ACE.
    2. Can the ACE be configured with an IN and an OUT vlan to the router
    CLIENT -> Router -> ACE IN -> ACE OUT -> Router -> Server Vlan
    so that the SSL and the clear text traffic is in a separate Vlan?
    Yes you can do that but wouldnt it make it routed mode topology?
    3. In some sample configuration i saw SNAT configuration on the ACE to modify the client IP. This i assume is for instructing the return traffic from the server to go through ACE? Using SNAT we eliminate the requirement for NAT or PBR on the router? Will i still be able to insert the client IP address after the SSL offload?
    As I said earlier you loose the Source IP address with SRC NAT. But with ACE you have an option to use header-insert and insert this source ip as an HTTP Header.
    Details at
    http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A1/configuration/slb/guide/classlb.html#wp1040008
    HTH
    Syed Iftekhar Ahmed

  • One-armed LB with Trunk

    What are the downsides of using a one-armed LB solution? I am trunking multiple VLANs across one interface instead of using multiple interfaces to connect to my server farm. The servers still have their default gateway as the CSS.

    Thee are performance issues if the CSS has to LB over one interface. These should not be under estimated !!
    However if you are trunking in to the CSS, you may not have this. It depends on how you configure your "logical" network. You could use one physical interface, but run two vlans over it (a trunk), these vlans are two logical interfaces, so in fact you are not running true one-armed. On CSS the vlans bind to the circuits to form the interfaces, it is only when you are LB over one circuit that you get performance issues.
    Hope that made sense :-)

  • Can I configure csm as one arm and routing mode at the same time?

    My csm currently is configured as the routing mode and bridge mode, resently I have a service requirement which I think the one arm mode should be the best resolution. Can anybody let me know if there will be any affect if I add the one arm mode to the currently production environment?
    Thanks in advance.
    Jason

    Gille,
    Thanks for your quick response. I notice you have same opinion about the one arm mode in your other post, but I think in the multi-tire data center design with fw in bridge mode and csm in one arm mode with RHI, do give us a lot of flexibilty. If I use policy routing instead of source nat, can I overcome these limit you metioned?
    Do you know who csm could handle the TFTP traffic? I may have too much question, I am realy looking for your suggestion.
    Thanks
    Jason

  • ACE in one-arm model. VIP on Client Side, servers in other vlan

    Hello All
    i have a LAN whit many servers,but only 2 need to be balanced. So i think in one-arm model, due to the higth trafic that not be pass trought ACE.
    i have a vlan 900 where is the client side and the VIP also. (10.0.9.64/26)
    the servers are in vlan 503 (10.12.3.0/24)
    it mi first design with ONE-arm but i thinks something is missing, because doesn't work.
    the configuration is the next:
    MSFC:
    svclc module 1 vlan-group 1,2,
    svclc vlan-group 1 503,900-902
    svclc vlan-group 2 511
    interface Vlan503
    description OSS_&_Otros
    ip address 10.12.3.253 255.255.255.0
    standby 10 ip 10.12.3.254
    standby 10 priority 150
    standby 10 preempt delay minimum 305
    interface Vlan900
    description MSF_<->_ACE
    ip address 10.0.9.126 255.255.255.192
    end
    access-list 101 permit ip 10.12.3.0 0.0.0.255 10.0.9.64 0.0.0.63
    access-list 101 deny ip any any
    route-map From_Server_OSS_to_ACE permit 10
    match ip address 101
    set ip next-hop 10.0.9.125
    ACE_1/admin#
    ip route 0.0.0.0 0.0.0.0 10.0.9.126
    context OSS
    allocate-interface vlan 511
    allocate-interface vlan 900
    allocate-interface vlan 902
    member Max20
    ACE_1/OSS# sh run
    Generating configuration....
    access-list EVERYONE line 10 extended permit ip any any
    access-list EVERYONE line 20 extended permit icmp any any
    rserver host OSS_FES_1
    description OSS_Front_End_Server_1
    ip address 10.12.3.140
    inservice
    rserver host OSS_FES_2
    description OSS_Front_End_Server_2
    ip address 10.12.3.150
    inservice
    serverfarm host SERVER_farm_OSS
    rserver OSS_FES_1
    inservice
    rserver OSS_FES_2
    inservice
    class-map match-all VIP-OSS
    2 match virtual-address 10.0.9.66 any
    policy-map type loadbalance first-match OSS-LB-POLICY
    class class-default
    serverfarm SERVER_farm_OSS
    policy-map multi-match OSS-POLICY-MAP
    class VIP-OSS
    loadbalance vip inservice
    loadbalance policy OSS-LB-POLICY
    loadbalance vip icmp-reply
    interface vlan 900
    description Clients-side
    ip address 10.0.9.125 255.255.255.192
    access-group input EVERYONE
    access-group output EVERYONE
    service-policy input OSS-POLICY-MAP
    no shutdown
    ip route 0.0.0.0 0.0.0.0 10.0.9.126
    maybe a i need to allocate the vlan 503 in OSS Context, any advice?
    Thanks in advace,
    Gianni From Chile

    Since you server are not behind the ACE in either bridge or routed mode add the follwoing to your config and use nat to get the traffic back to the ace.
    This is how one-armed mode works.
    ACE_1/OSS# sh run
    Generating configuration....
    access-list EVERYONE line 10 extended permit ip any any
    access-list EVERYONE line 20 extended permit icmp any any
    rserver host OSS_FES_1
    description OSS_Front_End_Server_1
    ip address 10.12.3.140
    inservice
    rserver host OSS_FES_2
    description OSS_Front_End_Server_2
    ip address 10.12.3.150
    inservice
    serverfarm host SERVER_farm_OSS
    rserver OSS_FES_1
    inservice
    rserver OSS_FES_2
    inservice
    class-map match-all VIP-OSS
    2 match virtual-address 10.0.9.66 any
    policy-map type loadbalance first-match OSS-LB-POLICY
    class class-default
    serverfarm SERVER_farm_OSS
    policy-map multi-match OSS-POLICY-MAP
    class VIP-OSS
    loadbalance vip inservice
    loadbalance policy OSS-LB-POLICY
    loadbalance vip icmp-reply
    nat dynamic 10 vlan 900
    interface vlan 900
    description Clients-side
    ip address 10.0.9.125 255.255.255.192
    nat-pool 10 0.9.126 10 0.9.126 netmask 255.255.255.192 pat
    access-group input EVERYONE
    access-group output EVERYONE
    service-policy input OSS-POLICY-MAP
    no shutdown

  • Probe fail on Standby ACE in One-armed mode

    Hi there
    I'm Kilsoo.
    I made One-armed mode using ACE.
    Real servers are in away Vlan from ACE.
    So, I configured the PBR with ACE alias ip address for the next-hop on the real server's gateway interface.
    And, the probe from active ACE works well.
    But, the probe from standby ACE was fail.
    At this point, my first question
    Is it normal situation that the probe fail from standby ACE????
    So, I made the route-map for PBR like below for temporary solution.
    route-map deny PBR 5
    match ip address Probe_ACL
    route-map permit PBR 10
    match ip address L4_ACL
      set ip next-hop <Alias IP address>
    ip access-list extended Probe_ACL
      pemit ip any <Standby ACE's IP address>
    ip access-list extended L4_ACL
    permit tcp <Real server's IP address> eq 80 any
    Second question...
    Do you have any other good solutions???
    Thanks

    Hi Cesar
    Thanks for your reply.
    But I think I was confuse when I wrote the message.
    I used both ace's vlan ip address for next-hop ip address like your advice.
    Do you know the standby ace can't check probe without route-map in one-armed mode like below diagram???
    Backbone Router
             |
             |
             |
    Supervisor --------------------ACE(vserver: 172.19.100.100)
             |         (vlan 200)
             |
             |
             |(vlan 110)
             |
             |
    Real servers
    (172.19.110.111)

  • ACE One Arm Mode vs Routed Mode

    Gents,
    When is it required to use the One Arm Mode and one do I use the routed mode? Actually I am confused and would really like to know the pros and cons of each?
    Regards,
    Hesham                  

    Hi Hesham,
    When you do not want to change the physical topology of your network then you usually go with ONE ARM mode.
    Such as default gateway on server, IP addressing on servers. In this case client can access the server directly as well.
    Its a flat network topology where your VIP and servers are in the same network ( VLAN ).
    You use routed mode when you want to segregate the servers in seperate vlan and don't want to allow client to access it directly.
    Client and VIP in same VLAN >>> ACE >>>>>> Server VLAN ( In this case we usually point the default gateway to ACE)
    hope it helps.
    regards,
    Ajay Kumar

  • ACE inline VS one-armed based

    Hello Forum, ;-)
    I have 2 basic questions I am having doubts about it and would love to have some clarifications:
    1) I configure in one ACE4710 (running 4.2.2) context a bridged interface and in another context the same interface, like here below :
    ---- Context Microsoft ----
    ACE1/Microsoft# sh run
    interface vlan 503
       bridge-group 3
       access-group input NONIP
       access-group input ALL
       access-group output ALL
       service-policy input POLICY
       no shutdown
    interface vlan 1503
       bridge-group 3
       access-group input ALL
       access-group output ALL
       no shutdown
    interface bvi 3
       ip address 120.223.22.30 255.255.255.0
       no shutdown
    Then I move to the Juniper context and I try to create an interface (either L-2 or L-3) but it doesn’t work:
    ---- Context Juniper----
    ACE1/Juniper(config)# int vlan 503
    Error: VLAN creation is not allowed, shared bridged VLAN exists in another context
    ACE1/Juniper(config)#
    It gives  ERROR!!
    So if I configure an interface as bridged in one Context, I cannot configure it in another context??
    2) If I want to migrate in context Microsoft from One-armed to inline (L-2 bridged), can I migrate one service at the time ( I.e. the config i showed above for context Microsoft, would it work also for one-armed based???)
    Thanks so much for your explanations!!
    Giulio.

    Hello Giulio-
    You can only share vlans in one-armed or routed modes.  Think of it this way:
      Interface vlan 10 and 11 are bridged on context C1. (bridged mode)
      Interface vlan 12 and 13 are configured on context C2. (routed mode)
      When you have routed mode, your server's gateway is configured to point to the ACE interface IP (or alias if you are have FT.) If a packet comes into the physical interface on the ACE, the processor has to decide which context it belongs to.  Since the mac address is the interface on context X, it knows instantly where it goes. It will either hit a VIP, or be routed via the routing table.
      If a packet arrived on vlan 12 or 13 and the MAC address did not belong to the ACE, it would drop the packet by basic routing rules. (think a client connected to a hub sees a packet destine to a MAC that is not its own, it drops/ignores the packet.) 
      In bridged mode, the gateway for your server is the router on the other side of the bridged vlan.  I.e., you server is on vlan 10, the gateway is on vlan 11 and ace is bridging them together.  When packets arrive to the physical interface, ACE knows the traffic arrived on vlan 10 or 11 which belongs to context C2. If the MAC address is not a VIP, ACE simply hucks the packet out of the other vlan.  If you send traffic to the interface MAC that does not belong to a VIP, ACE drops it because it would not make sense to send a packet out the other vlan that has a MAC address that belongs to the interface of the ACE itself.
      One-armed mode is simply routed mode with a single vlan and source NAT. Nothing special applies to how ACE handles the traffic versus routed mode with only a single vlan.
    Now imagine this:
      Interface vlan 10 and 11 are bridged on context C1.
      Interface vlan 11 and 12 are configured on context C2.
    Remember 3 things:
    a.) ACE conserves MAC addresses - so the VIPs share MAC addresses with the interface.
    b.) ACE will never communicate between 2 contexts directly.
    c.) If you are in a routed mode and share vlans between 2 contexts, ACE will make each vlan have a unique MAC address. If you create unique vlans on each context, ACE uses the same single MAC across all vlans for all contexts.
    With traffic that is destine to ACE's MAC address and the IP is a VIP,  its not a problem - ACE could figure out which context the traffic  belongs to (especially since vlan 11 would have unique mac addresses on each context.  However, what if ACE recieved a packet to the interface 10 and 12 MAC  address? How would it know if it belonged to the bridged or routed context if it was not a VIP IP? What about traffic that arrives that doesn't have the MAC of any of the interfaces?  2 different entirely behaviors would occur, ACE should drop the packet on the bridged context, and route the packet on the routed context.
      So the bottom line is - you can't determine which context a packet would need to apply to in all circumstances if you tried to share vlans in a bridge mode across multiple contexts.
    Regards,
    Chris Higgins

  • ACE 4710 one-arm L4 load balancing removes accept-encoding?

    We have built a simple one-arm PAT config to round robin load balance two Varnish servers. In the "Default L7 load-balancing action" we have left compression to "N/A". It looks like the ACE removes "Accept-Encoding: gzip, deflate" from the client header.
    Is this normal behaviour? We would like the Varnish to do the compression. Do we need modify the headers to get this through the ACE?

    Hi,
    Yes this does seem to be the behavior. Please read below:
    HTTP compression is a capability built into web servers and web browsers to improve site performance by reducing the amount of time required to transfer data between the server and the client. Performing compression on the ACE offloads that work from the server, thereby freeing up the server to provide other services to clients and helping to maintain fast server response times.
    When you enable HTTP compression on the ACE, the appliance overwrites the client request with "Accept-Encoding identity" and turns off compression on the server-side connection. HTTP compression reduces the bandwidth associated with a web content transfer from the ACE to the client.
    So ACE rewrites the ACCEPT-ENCODING header to IDENTITY to indicate to the server that it should not compress the return data. That would be done by ACE.
    Also, default method is used when client comes with both gzip or deflate for "ACCEPT ENCODING". For compression to work, a client must send a request with an ACCEPT-ENCODING method of gzip or deflate. If a client sends both methods, then the ACE uses the configured method(default method).
    Also, you can see if ACE is compressing the packets or in "show service-policy detail.
    switch/Admin#
    show service-policy L7_COMP_SLB_POLICY detail
    Status     : ACTIVE
    Description: -----------------------------------------
    Interface: vlan 1 108
      service-policy: L7_COMP_SLB_POLICY
        class: vip
         VIP Address:    Protocol:  Port:
         2.0.5.1         tcp        eq    80
          loadbalance:
            L7 loadbalance policy: pm
            VIP ICMP Reply       : ENABLED
            VIP state: OUTOFSERVICE
            Persistence Rebalance: ENABLED
            curr conns       : 0         , hit count        : 0
            dropped conns    : 0
            client pkt count : 0         , client byte count: 0
            server pkt count : 0         , server byte count: 0
            conn-rate-limit      : 0         , drop-count : 0
            bandwidth-rate-limit : 0         , drop-count : 0
            L7 Loadbalance policy : pm
              class/match : h
                ssl-proxy client : c
                LB action :
                   primary serverfarm: sf1
                        state: DOWN
                    backup serverfarm : -
                hit count        : 0
                dropped conns    : 0
                compression      : on  <------------------------------ Compression is enabled if the value is "on"
    compression  bytes_in  : 0       bytes_out : 0  <--- Number of bytes transmitted after compressing the server response
    Compression ratio : 0.00%  <------------------------------ Percentage of data compressed
    Gzip: 0               Deflate: 0  <--------------- Number of times the method is used
    compression errors:                                     _
    User-Agent  : 0               Accept-Encoding    : 0   |
    Content size: 0               Content type       : 0   |
    Not HTTP 1.1: 0               HTTP response error: 0   |-- Check these error counters to see if they are increasing
    Let me know if you have any questions.
    Regards,
    Kanwal

  • How to see the Source IP Address of a client using ACE One-armed-mode to load balance HTTP proxy request

    I'm using an Ace 4710 Appliance deployed in One-Armed mode, using Source NAT to loadbalance HTTP request to a couple of Proxy servers.
    Everything is working fine, but the thing is that I can't see the Clients IP addresses on Proxy's logs, so I can't keep track of them.
    The Interfaces and Nat configs are:
    interface vlan 200
      description Server-Side-VLAN
      bridge-group 5
      nat-pool 5 10.1.1.5 10.1.1.5 netmask 255.255.255.0 pat
      service-policy input VIPS
    interface vlan 300
      description Client-Side-VLAN
      bridge-group 5
    interface bvi 5
      ip address 10.1.1.3 255.255.248.0
      description Client-Server-Virtual-Interface
    ip route 0.0.0.0 0.0.0.0 10.1.1.1
    and the policy map looks like this
    policy-map multi-match VIPS
      class Port80
        loadbalance vip inservice
        loadbalance policy Port80
        nat dynamic 5 vlan 200
    Resource assignment:
    sticky ip-netmask 255.255.255.255 address both RESOURCE-CLASS
      timeout 5
      serverfarm Service80
    Any suggestions will be appreciated,
    Thanks

    Hi Kanwal,
    Thanks for your quick reply,
    I've already tried this but it didn't work. The problem is that I don't manage the proxy servers so I rely on their skills to see the logs.
    The Proxies are Squid. Do you know if they need to do something else on the servers to see that field of the HTTP header?
    But I'll try again tomorrow and let you know how it goes.
    Thank you again.

  • Sniffer Trace on ACE w/VACLs and One-Arm Design

    Wow...that was a mouthful of a title!
    Here is what I'm trying to accomplish. There is an application that is having issues. This application is being load balanced by the ACE. The ACE is configured in a One-Armed design. Essentially the application flow is as follows:
    client --> ACE VIP --> SNAT Pool --> rserver and then the reverse.
    The vlan for my ACE is 3002. It is the only vlan in this context. I have a WildPackets OmniEngine connected to port on the 6500. Here is its config:
    interface GigabitEthernet x/xx
    switchport
    switchport trunk encapsulation dot1q
    switchport mode trunk
    switchport nonegotiate
    switchport capture
    switchport capture allowed vlan 3002
    no ip address
    no cdp enable
    Here is the problem. When I take a trace I only see the back half of the conversation. That is I only see from the SNAT pool IPs to the rservers and back. I need to be able to see the conversation between the client IPs and the VIP. Does anyone know how this can be done? If you need more details or have questions please fire away! Thanks for the help...
    bc

    This can be done by setting up a monitor session on the Sup, with the
    TenGig/1 as SPAN
    source, and a trunk port as SPAN destination.
    For example, if the ACE is in slot X, the configuration would be:
    monitor session 10 source interface TeX/1
    monitor session 10 destination interface Giy/z
    The configuration for this port would be:
    int giy/z
    switchport
    switchport trunk encapsulation dot1q
    switchport mode trunk
    switchport nonegotiate
    Syed Iftekhar Ahmed

  • ACE implementacion with servers Lan in other Router

    Hi,
    I need help in this topology, I need to design an escenario, where the Lan Servers  are  in other Router, the conexion between the ACE module and the Lan Server is throught a routing protocols using a Layer 3 device like an ASA.
    I have a confusion of using a Context in routed mode or One Armed mode. i dont know what is the best option.
    I need help.
    Attached a Diagram of the  escenarios.
    Regards,
    Fidel Gonzalez

    Hi Fidel,
    This should work in Routed or One-Armed, the only thing you need to be sure is that the response of the servers is going back to the ACE instead of going directly to the client.
    You probably will need to use source nat when the ACE sends the traffic to the servers.
    Cesar R
    ANS Team

  • Source IP in One armed Mode ACE

    Hi,
    How do we find actual Client Source IP address in One armed mode ACE for NON-HTTP application like LDAP,FTP and etc....

    It's not possible. Insertion within header works only for HTTP and HTTPS with SSL offload.

  • CSS 11503 One-arm Design and Server Default Gateway

    Our problem is determining the correct default gateway for our web servers. All IP addresses are in the same subnet (VIP, interfaces, and servers). Should the servers default gateway be the L3 switch, or the CSS?
    Thanks!
    Tom

    Hi Tom,
    If you have one arm mode, you might have problems with asymmetric flows, due that the CSS behaves similar to a firewall when it comes to flows, as it needs to see both sides of the flow ( client and server side ) in order to handle things correctly. Having this kind of setup, and even when the server pointing to the CSS as its default gateway, ICMP redirects might force the traffic to change dynamically.
    You can put as default gateway the L3 switch, but you need to force the traffic that has been load balanced by the CSS to go back to the CSS, otherwise the flow would fail. You can do this by using a group on the CSS, adding the service with the following command: 'add destination service xxxx'. This would NAT the client's IP address for the VIP that you use on the group and would force the flow to go back to the CSS.
    Another thing that you can do is to use the CSS as the server's DG, but you must make sure that all L3 devices, including the CSS have ICMP redirects turned off on this subnet. If you have a firewall on this subnet, you would need to turn off proxy ARP as well.
    I hope you find this helpful. Thanks!
    Regards,
    Jose Quesada.

Maybe you are looking for

  • Sales By Vendor Report

    I'm trying to run a report or query based on total sales by vendor but can't get it working. I'm pretty new to BO and was wondering if someone could help.

  • Download Dialog Box in Page Process

    I know this has been beat to death, but I just can't get it working. I am using Apex 3.0 on iAS 10g on Unix I have a report that displays locations and map coordinates and a check box for each line. The user checks the lines they want to "Map" and th

  • How to Start/Stop from Server Manager

    Hello, I am trying to figure out how to start/stop/restart my coldfusion servers from server manager.  I have seen the instruction at this link: http://help.adobe.com/en_US/ColdFusion/9.0/Admin/WSfd7453be0f56bba4-2a6b48f122a6582c7f-7ff e.html However

  • SubmitToSAP button is not working

    Hello Experts, I have Webdynpro Java application along with Interactive form. I have created onSubmit action in webdynpro for Interactive UI element. Now I am trying to pass control to webdynpro framework by using submitToSAP1 button from Webdynpro N

  • Ring tones visible, but only one selectable

    I made some custom ringtones using the Ringtones app.  These did not appear when selecting Sounds::Ringtone or individual contacts, so I transferred them to itunes and then dropped them onto my iphone.  (I tested them on the mac:  The icons say "RING