CSM-S mode -One-Arm-vs- routed

We currently have an environment with CSS running in routed mode. We are building a new data center with 6509s and CSM-S. My question is what is the best mode to run the CSM-S in routed or one-arm and why?

Gilles,
What do you recommend when the traffic flows from the load balanced server are significant?
ie: you are using Oracle application and database servers, load balancing http and https to the app servers. There is significant traffic flow from the app server to the database servers, such that the load balancer in a 2-armed configuration(particularly a CSS11501 w/ 8 10/100 interfaces and a single 1000Base-T interface) would be a significant bandwidth bottleneck.
Also, if Cisco usually does not recommend one-armed config.... why does the latest Server Farm Security Solution Reference Network Design v2.0 (http://www.cisco.com/warp/public/732/systems/docs/dcsrndbk.pdf) recommend a one-armed configuration for the CSS?

Similar Messages

  • Differences between One Arm and Route modes?

    Hi Guys,
    What are the differences between One Arm and Route modes? Can anyone please explain?
    Krishna

    Hi Krishna,
    Have a look at the two links below. They provide configuration examples for each of the two topologies along with explanation on the different commands used.
    http://docwiki.cisco.com/wiki/Basic_Load_Balancing_Using_Routed_Mode_on_the_Cisco_Application_Control_Engine_Configuration_Example
    http://docwiki.cisco.com/wiki/Basic_Load_Balancing_Using_One_Arm_Mode_with_Source_NAT_on_the_Cisco_Application_Control_Engine_Configuration_Example
    I hope this helps
    Daniel

  • 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 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

  • CSM in one armed mode Redundancy

    Hi,
    I have a customer with a one arm setup. However they have no server vlan, only a client vlan. They are using source nat and it is working, however I am unsure how to setup redundancy as the alias command seems to be generally used on the server vlan.
    i am running hsrp and a ft vlan accross the csm's
    Does anyone have any experience of this type of setup, do i need to add any additional config for fault tolerence??
    Cheers
    Scott

    Scott,
    you can use the alias and whatever vlan [client or server].
    It is required if your servers or clients are using the CSM as default gateway.
    There is no special config required when doing fault tolerance in one-armed mode.
    It's the same as inline mode.
    Gilles.

  • 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

  • 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.

  • Is't Single-VLAN One-Armed Mode let the pop-ups error?

    Dear all
      In my network I deployed Single-VLAN One-Armed Mode In this mode,the real server’s default gateway is the upstream router. To ensure the return
    flow traverses back through the load balancer, the IP address of the client isrewritten to that of the load balancer.
      Direct access web was fine ,however when open Pop-ups website will appear error Example, the figure-1 ：
      figure-1
      When I used real Server IP address not through ACE anything will be fine. Example, the figure-2 :
    figure-2
    The Web's Code
    <%@ page language="java" pageEncoding="UTF-8"%>
    <%@ taglib uri="/WEB-INF/hnisi.tld" prefix="hnisi"%>
    <%@ include file="/jsp/framework/head.jsp"%>
    <%@ page import="cn.sinobest.framework.util.DTOUtil,cn.sinobest.framework.util.Util,cn.sinobest.framework.util.ConfUtil" %>
    <%
        //当前登录用户 所属系统机构
        String orgCode = DTOUtil.getUserInfo().getBAE001();
        //操作员ID
        String operId = DTOUtil.getValue("OPERID");
        //角色类型
        String roleType = DTOUtil.getValue("ROLETYPE");
            String fromFuncDesc = DTOUtil.getValue("fromFuncDesc");
        //所选操作员的姓名
        String sOperatorName = DTOUtil.getValue("SOPERATORNAME");
        //权限树 where 条件
        String whereClsTree = " rightid in (  select distinct B.RIGHTID "+
                    " from FW_RIGHT B"+
                    " left join FW_OPERATOR2RIGHT A on LOCATE(B.RIGHTID,A.RIGHTID) = 1"+
                     " where A.AAE100 ='1'"+
                     " and B.AAE100 ='1' and A.operid = '"+operId+"' ";
        //条件：有效角色，当前登录用户只能操作用户所属系统机构及下级机构的角色，以及上级机构的共享角色
        String whereCls =" AAE100 ='1' and (BAE001 like '"+orgCode+"%' or ( IFSHARED = '1' and LOCATE(BAE001,'"+orgCode+"') = 1))";
        if(!Util.isEmpty(roleType)){//角色类型
                 whereClsTree +=" and AUTHTYPE='"+roleType+"' ";
                 String roleType_zdfpzj = ConfUtil.getDict("ROLETYPE", "13");//最大分配角色
            if("2".equals(roleType)){//分配角色包括：分配角色、最大分配角色
                     whereCls += " and ROLETYPE in('"+roleType+"','"+roleType_zdfpzj+"') ";             
            }else{
                           whereCls += " and ROLETYPE='"+roleType+"' ";
        whereClsTree +=" )";
    %>
    <%-- 导航栏标签 --%>
    <hnisi:gNavStr />
        <legend style="cursor:hand;" >
            <span>
                <img id="img_fw_authmngr_geneauth_list_grid" src="${ctx}/themes/default/images/query_icon_right.gif">
            </span>
            <span title="单击展开或收缩">
                <b><%=sOperatorName%></b>已拥有的权限树
                <hnisi:tree id="menus" type="1" whereCls="<%=whereClsTree %>"/>
            </span>
        </legend>
        <form name="roleListForm" method="post">
            <%-- 角色列表--%>
            <hnisi:glt id="fw_authmngr_geneauth_role" whereCls="<%=whereCls %>" />
            <p align="center">
                <%-- 确定按钮 --%>
                <hnisi:btn name="btnQuery" onclick="roleAutoOk()" value="保存" href="javascript:void(0)"/>
                <%-- 清除按钮 --%>
                <hnisi:btn name="btnCls" onclick="cls()" value="清除" href="javascript:void(0)"/>
                <%-- 关闭按钮 --%>
                <hnisi:btn name="btnClose" onclick="winClose()" value="关闭" href="javascript:void(0)"/>
            </p>
        </form>
        <form name="roleForm">
            <input type="hidden" name="OPERID" value="<%=operId %>"/>
            <input type="hidden" name="ROLEIDS">
        </form>
        <script type="text/javascript">
        <!--
        var orgCode ="<%=orgCode%>";
        var operId ="<%=operId%>";
        var roleType ="<%=roleType%>";
         * 权限列表窗口
         * @param roleId:角色ID
        function winRight(roleId){
            var eventId="1";//授权事件(1 查询、2 授权)
                 //弹出模态对话框，并加上时间戳以防止缓存
                 window.showModalDialog("right!left.do?EVENTID=" + eventId+"&ROLETYPE="+roleType+"&ROLEID=" + roleId+"&_t="+new Date().getTime());
         * 确定-保存授权信息
             function roleAutoOk(){
                       $(function(){
                           var roleIds = "";
                           $.each($("input[name='checkbox']:checked"),function(i,o){
                               roleIds += (i==0 ? "" : ",")+o.value;                 
                           if (roleIds == ""){
                                    FWalert("请选择要操作的角色!");                          
                                    return;
                           roleForm.ROLEIDS.value  = roleIds;
                           var params = FWGetForm(roleForm);
                           if(params.ROLEIDS ==""){
                               FWalert("请选择要操作的角色!");
                           }else {
                                    var fromFuncDesc = "<%=fromFuncDesc%>";
                                    //先进入本次权限变更列表页面，确认后再保存
                                    var title = encodeURIComponent('授权确认');//对话框的标题
                               var url = "right!list.do?OPERID="+operId+"&fromFuncDesc="+fromFuncDesc+"&ROLETYPE="+roleType+"&ROLEIDS="+roleIds+"&title="+title+"&_t="+new Date().getTime();
                                    var position="resizable:1;status:0;help:0;scroll:1;center:1;dialogWidth:800px;dialogHeight:500px";
                                    window.showModalDialog(url,window,position);
         * 直接授权:弹出权限树窗口
        function directAuto(){
            var eventId="2";//授权事件(1 查询、2 授权)
                       //弹出模态对话框，并加上时间戳以防止缓存
                 window.showModalDialog("right!left.do?EVENTID=" + eventId+"&ROLETYPE="+roleType+"&OPERID=" + operId+"&_t="+new Date().getTime());
         * 清除：清除已选择的角色 checkbox
        function cls(){
            var c_checkbox=document.getElementsByName('checkbox');
                       for (i=0;i<c_checkbox.length;i++){
                c_checkbox[i].checked=false;
         * 关闭窗口
        function winClose(){
                 window.close();
        //-->
        </script>
    </body>
    </html>
    The ACE's config
    `show running-config`
    Generating configuration....
    boot system image:c4710ace-mz.A4_2_0.bin
    interface gigabitEthernet 1/1
      switchport access vlan 100
      no shutdown
    interface gigabitEthernet 1/2
      shutdown
    interface gigabitEthernet 1/3
      shutdown
    interface gigabitEthernet 1/4
      switchport access vlan 3
      no shutdown
    access-list ALL line 8 extended permit ip any any
    access-list allowany line 8 extended permit ip any any
    access-list allowany line 16 extended permit icmp any any
    probe icmp Ping
      interval 2
      faildetect 2
      passdetect interval 2
      passdetect count 1
      receive 2
    probe tcp TCP6666
      description RPC Client Access
      port 6666
      interval 30
      passdetect interval 60
      connection term forced
      open 10
    probe tcp TCP8888
      description RPC Client Access
      port 8888
      interval 30
      passdetect interval 60
      connection term forced
      open 1
    rserver host YB1
      ip address 110.43.102.241
      inservice
    rserver host YB2
      ip address 110.43.102.245
      inservice
    rserver host YB3
      ip address 110.43.102.246
      inservice
    rserver host YB4
      ip address 110.43.102.247
      inservice
    rserver host YB5
      ip address 110.43.102.248
      inservice
    rserver host YB6
      ip address 110.43.102.242
      inservice
    serverfarm host YB01farm
      predictor leastconns
      probe TCP6666
      rserver YB2
        inservice
      rserver YB3
        inservice
      rserver YB4
        inservice
      rserver YB5
        inservice
    serverfarm host YB02farm
      predictor leastconns
      probe TCP8888
      rserver YB2
        inservice
      rserver YB3
        inservice
      rserver YB4
        inservice
      rserver YB5
        inservice
    parameter-map type http PRESIST-REBALANCE
      persistence-rebalance
    sticky ip-netmask 255.255.255.255 address source YB01-GRP
      timeout 60
      replicate sticky
      serverfarm YB01farm
    sticky ip-netmask 255.255.255.255 address source YB02-GRP
      timeout 60
      replicate sticky
      serverfarm YB02farm
    sticky http-cookie COOKIE1 STICKYYB01
      cookie insert browser-expire
      timeout 3600
      replicate sticky
      serverfarm YB01farm
    action-list type modify http IP-header
      header insert request X-Forwarded-For header-value "%is"
    class-map match-all YB01-slb-vip
      2 match virtual-address 110.43.102.251 any
    class-map match-all YB02-slb-vip
      2 match virtual-address 110.43.102.252 any
    class-map type management match-any remote_access
      description remote-access-traffic-match
      2 match protocol xml-https any
      3 match protocol icmp any
      4 match protocol telnet any
      5 match protocol ssh any
      6 match protocol http any
      7 match protocol https any
      8 match protocol snmp any
    policy-map type management first-match remote_mgmt_allow_policy
      class remote_access
        permit
    policy-map type loadbalance http first-match YB01-slb
      class class-default
        sticky-serverfarm STICKYYB01
        action IP-header
    policy-map type loadbalance http first-match YB02-slb
      class class-default
        sticky-serverfarm YB02-GRP
        action IP-header
    policy-map type loadbalance first-match YB6666
      class class-default
        sticky-serverfarm STICKYYB01
        action IP-header
        insert-http https header-value "on"
    policy-map multi-match client-vips
      class YB01-slb-vip
        loadbalance vip inservice
        loadbalance policy YB6666
        loadbalance vip icmp-reply active
        nat dynamic 100 vlan 100
        appl-parameter http advanced-options PRESIST-REBALANCE
      class YB02-slb-vip
        loadbalance vip inservice
        loadbalance policy YB02-slb
        loadbalance vip icmp-reply active
        nat dynamic 100 vlan 100
    interface vlan 3
      ip address 192.168.50.2 255.255.255.240
      access-group input ALL
      service-policy input remote_mgmt_allow_policy
      no shutdown
    interface vlan 100
      ip address 110.43.102.238 255.255.255.0
      access-group input allowany
      nat-pool 100 110.43.102.239 110.43.102.239 netmask 255.255.255.255 pat
      service-policy input remote_mgmt_allow_policy
      service-policy input client-vips
      no shutdown
    ip route 0.0.0.0 0.0.0.0 110.43.102.112

    Hi,
    The error comes when accessing the website through LB. The error is thrown by the server. Do  we know what does that error indicate and will be thrown by server under what circumstances?
    Can you just try with one server in the serverfarm and check if it works fine?
    Does it load initial page at all or throws error right away.
    What do you see in show conn output? Which VIP is in question here?
    Regards,
    Kanwal

  • 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)

  • Ace4710 one-armed mode case

    hi  all
    If  ace4710 one-armed mode must have two subnet ?
    and sw or router must config pbr or snat ?
    tks

    thank you
    I  config it successful
    but another question
    1：Shutdown left or right realservice ,test ok
    2：Shutdown1.1.1.28 7001 and 1.1.1.29 7002 test result :telnet 1.1.1.19 7001 Ok
    Telnet 1.1.1.19 7002 fail ;but telnet 109.101.108.29 7002 test ok
    3:cross shutdown realservice why only single service ok?
    1.1.1.28
    Tcp port 7001 
    Tcp port 7002
    Tcp port 7009
    1.1.1.29
    Tcp port 7001 
    Tcp port 7002
    Tcp port 7009
    VIP 1.1.1.19
    [BEGIN] 2012/6/17 18:47:48
    sh run
    Generating configuration....
    logging enable
    resource-class RC1
      limit-resource all minimum 10.00 maximum unlimited
      limit-resource rate bandwidth minimum 20.00 maximum unlimited
      limit-resource sticky minimum 10.00 maximum unlimited
    boot system image:c4710ace-mz.A4_2_0.bin
    peer hostname SFMI-2
    hostname SFMI-1
    shared-vlan-hostid 2
    peer shared-vlan-hostid 1
    interface gigabitEthernet 1/1
      shutdown
    interface gigabitEthernet 1/2
      shutdown
    interface gigabitEthernet 1/3
      ft-port vlan 199
      switchport trunk native vlan 1
    --More--
      switchport trunk allowed vlan 1-3,6-8
      no shutdown
    interface gigabitEthernet 1/4
      shutdown
    clock timezone shanghai 8 10
    context Admin
      member RC1
    access-list SFMI-ACL line 10 extended permit icmp any any
    access-list SFMI-ACL line 20 extended permit ip any any
    access-list SFMI-ACL line 30 extended permit tcp any any
    probe tcp 7001
      port 7001
      interval 30
      faildetect 1
      passdetect interval 30
      passdetect count 2
      receive 2
    --More--
      open 2
    probe tcp 7002
      port 7002
      interval 30
      faildetect 1
      passdetect interval 30
      passdetect count 2
      receive 2
      open 2
    probe tcp 7008
      port 7008
      interval 30
      faildetect 1
      passdetect interval 30
      passdetect count 2
      receive 2
      open 2
    probe tcp 7009
      port 7009
      interval 30
      faildetect 1
      passdetect interval 30
    --More--
      passdetect count 2
      receive 2
      open 2
    probe icmp PROBE-ICMP
      interval 10
      faildetect 1
      passdetect interval 2
      passdetect count 1
      receive 1
    rserver host Rserver1
      ip address 1.1.1.28
      inservice
    rserver host Rserver2
      ip address 1.1.1.29
      inservice
    serverfarm host SERVERFARM
      probe 7001
      probe PROBE-ICMP
      rserver Rserver1
        inservice
    --More--
      rserver Rserver2
        inservice
    serverfarm host SERVERFARM2
      probe 7002
      probe PROBE-ICMP
      rserver Rserver1
        inservice
      rserver Rserver2
        inservice
    serverfarm host SERVERFARM3
      probe 7009
      probe PROBE-ICMP
      rserver Rserver1
        inservice
      rserver Rserver2
        inservice
    sticky ip-netmask 255.255.255.255 address source SGROUP1
      timeout 300
      serverfarm SERVERFARM
    sticky ip-netmask 255.255.255.255 address source SGROUP2
      timeout 300
    --More--
      serverfarm SERVERFARM2
    sticky ip-netmask 255.255.255.255 address source SGROUP3
      timeout 300
      serverfarm SERVERFARM3
    class-map match-all VIP-17
      2 match virtual-address 1.1.1.19 any
    class-map match-all VIP-18
      2 match virtual-address 1.1.1.19 any
    class-map match-all VIP-19
      2 match virtual-address 1.1.1.19 any
    class-map type management match-any remote-manage
      2 match protocol telnet any
      3 match protocol ssh any
      4 match protocol icmp any
      5 match protocol https any
      6 match protocol http any
      7 match protocol snmp any
    policy-map type management first-match remote-manage
      class remote-manage
    --More--
        permit
    policy-map type loadbalance first-match VIP-17
      class class-default
        sticky-serverfarm SGROUP3
    policy-map type loadbalance first-match VIP-18
      class class-default
        sticky-serverfarm SGROUP2
    policy-map type loadbalance first-match VIP-19
      class class-default
        sticky-serverfarm SGROUP1
    policy-map multi-match global
      class VIP-19
        loadbalance vip inservice
        loadbalance policy VIP-19
        loadbalance vip icmp-reply active
        nat dynamic 1 vlan 6
      class VIP-18
        loadbalance vip inservice
        loadbalance policy VIP-18
        loadbalance vip icmp-reply active
    --More--
        nat dynamic 1 vlan 6
      class VIP-17
        loadbalance vip inservice
        loadbalance policy VIP-17
        loadbalance vip icmp-reply active
        nat dynamic 1 vlan 6
    interface vlan 6
      ip address 1.1.1.4 255.255.255.0
      peer ip address 1.1.1.5 255.255.255.0
      no normalization
      access-group input SFMI-ACL
      access-group output SFMI-ACL
      nat-pool 1 1.1.1.99 1.1.1.99 netmask 255.255.255.0 pat
      service-policy input global
      service-policy input remote-manage
      no shutdown

  • Cannot ping VIP in One-Arm mode

    Hello.
    I can ping the ip addresses of the vlan and access via management, the real-servers are Active along with the VIP service (ie. show service-policy) but I cannot ping the VIP interface and traces do not show any traffic hitting it because the 6500 the ACE (vc4710ace-mz.A1_8_0a) is connecting to has no ARP entry for the VIP.
    It's in One-Arm mode; one gig-link to core, vlan 141.
    I've attached the config.
    Anyone got any ideas what I'm missing, please?

    Hi,
    the default gateway of your servers is the upstream router.
    Have a look at following link: http://docwiki.cisco.com/wiki/Basic_Load_Balancing_Using_One_Arm_Mode_with_Source_NAT_on_the_Cisco_Application_Control_Engine_Configuration_Example
    Nevermind the picture, it should look more like this: http://docwiki.cisco.com/wiki/SSL_Termination_on_the_Cisco_Application_Control_Engine_Using_an_Existing_Chained_Certificate_and_Key_in_One_Arm_Mode_Configuration_Example
    HTH,
    Dario

  • Please verify the CSS and SCA configuration for one-armed transparent mode

    I have a problem to configure one-armed transparent mode. I cannot access the server with "https://9.9.9.1" even "http://9.9.9.1:80" and "http://9.9.9.1:81" operational. looks CSS cannot communicate properly with SCA.
    I couldn't figure out from CCO sample configuration. please correct the attached configuraiton.
    Thanks,
    ** connectivity ********
    <client>----<router>----<CSS>---<SCA>,<Server>
    - client=7.7.7.100
    - router's e0/0=7.7.7.1, e0/1=8.8.8.3(connect to VLAN2 of CSS)
    - SCA=11.11.11.100, connect to VLAN3 of CSS
    - server=10.147.153.12 and 10.147.153.15 on the same box, connect to VLAN4 of CSS
    ** configuration *********
    CSS11050# sh run
    !Generated on 01/01/2079 00:00:47
    !Active version: ap0500105
    configure
    !*************************** GLOBAL ***************************
    acl enable
    ip route 0.0.0.0 0.0.0.0 11.11.11.100 1
    ip route 7.7.7.100 255.255.255.255 8.8.8.3 1
    ip route 7.7.7.200 255.255.255.255 8.8.8.3 1
    !************************* INTERFACE *************************
    interface e2
    bridge vlan 2
    interface e3
    bridge vlan 3
    interface e4
    bridge vlan 4
    interface e5
    bridge vlan 4
    !************************** CIRCUIT **************************
    circuit VLAN1
    ip address 9.9.9.2 255.255.255.0
    circuit VLAN2
    ip address 8.8.8.2 255.255.255.0
    circuit VLAN3
    ip address 11.11.11.1 255.255.255.0
    circuit VLAN4
    ip address 10.147.153.1 255.255.255.0
    !************************** SERVICE **************************
    service ING_SVC_12
    protocol tcp
    ip address 10.147.153.12
    active
    service ING_SVC_15
    protocol tcp
    ip address 10.147.153.15
    active
    service ING_SVC_SCA
    port 443
    protocol tcp
    ip address 11.11.11.100
    type transparent-cache
    no cache-bypass
    active
    service upstream
    ip address 8.8.8.3
    type transparent-cache
    active
    !*************************** OWNER ***************************
    owner ING_OWNER
    content cnt_443
    add service ING_SVC_SCA
    protocol tcp
    port 443
    vip address 9.9.9.1
    active
    content cnt_80
    add service ING_SVC_12
    add service ING_SVC_15
    protocol tcp
    port 80
    url "/*"
    vip address 9.9.9.1
    active
    content cnt_81
    add service ING_SVC_12
    add service ING_SVC_15
    vip address 9.9.9.1
    protocol tcp
    port 81
    url "/*" <-- If I configure url "/secure/*", not working "http://9.9.9.1:81" from client.
    active
    !**************************** ACL ****************************
    acl 1
    clause 10 permit any any destination any
    apply circuit-(VLAN1)
    acl 2
    clause 10 permit any any destination any
    apply circuit-(VLAN2)
    acl 3
    clause 10 permit any any destination any
    apply circuit-(VLAN3)
    acl 4
    clause 10 permit any any destination any
    apply circuit-(VLAN4)
    ING_SCA# sh run
    # Cisco SCA Device Configuration File
    # Written: Sun Feb 6 01:12:54 2106 MST
    # Inxcfg: version 4.1 build 200211151311
    # Device Type: CSS-SCA
    # Device Id: S/N 11aca8
    # Device OS: MaxOS version 4.1.0 build 200211151311 by reading
    ### Mode ###
    mode one-port
    ### Interfaces ###
    interface network
    auto
    end
    interface server
    auto
    end
    ### Device ###
    ip address 11.11.11.100 netmask 255.255.255.0
    hostname ING_SCA
    timezone "MST7MDT"
    ### Password ###
    password idle-timeout 15
    ### SNTP ###
    sntp interval 86400
    ### Static Routes ###
    ip route 0.0.0.0 0.0.0.0 11.11.11.1 metric 1
    ### RIP ###
    no rip
    ### DNS ###
    no ip name-server
    no ip domain-name
    ### Telnet ###
    telnet enable
    ### Web Management ###
    web-mgmt port 80
    no web-mgmt enable
    ### SNMP Subsystem ###
    no snmp
    ### SSL Subsystem ###
    ssl
    server ING create
    ip address 9.9.9.1
    localport 443
    remoteport 81
    key default
    cert default
    secpolicy default
    sslv2 enable
    sslv3 enable
    tlsv1 enable
    session-cache size 20480
    session-cache timeout 300
    session-cache enable
    no clientauth enable
    clientauth verifydepth 1
    clientauth error cert-other-error fail
    clientauth error cert-not-provided fail
    clientauth error cert-has-expired fail
    clientauth error cert-not-yet-valid fail
    clientauth error cert-has-invalid-ca fail
    clientauth error cert-has-signature-failure fail
    clientauth error cert-revoked fail
    sharedcipher error failhtml
    ephemeral error failhtml
    no httpheader client-cert
    no httpheader server-cert
    no httpheader session
    no httpheader pre-filter
    httpheader prefix "SSL"
    ephrsa
    keepalive frequency 5
    keepalive maxfailure 3
    no keepalive enable
    end
    end

    the problem is the routing.
    You need a route for the client pointing to the SCA like this
    ip route 7.7.7.100 255.255.255.255 11.11.11.100 1
    This is so the reply from the server to the client goes back to the SCA first
    for encryption.
    Gilles.

  • 4710 in one-armed mode

    is it possible to preserve the clients originating IP address somewhere while using the 4710 in one armed mode?  I have a situation where the client source ip is needed, and I am deciding between one-armed mode and inline.  I'd like to use one-armed, so that only load balanced traffic traverses the load balancer, but I haven't seen an example where that can be done without  loosing the clients src address.

    Only thing I can think of is http header-insertion. Create an action-list, that inserts the original client src.ip/port into the http-header. The configuration is quite simple:
    action-list type modify http name
      header insert both Host header-value %is:%ps
    Then apply the action-list to your loadbalance policy-map.
    Take a look at the url below for futher information:
    http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/classlb.html#wp1131842
    But that depends on your situation. If is the original client src.ip/port is expected in the L3/L4 header, this won't cut it. Is this for logging purposes or some form of packet filtering ?
    If you intend to run your ACE in one-arm mode, in my opponion, src.nat and header-insertion is your only option.
    hth
    /Ulrich

  • 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.

  • CSM-S, move to one-arm configuration.

    Hello.
    We  are using a couple of CSM-S with a single subnet bridge and fault  tolerance configuration. Now we are evaluating to move to an one-arm  configuration, so I’m reading some design guides.
    We want to move to this topology because there are some advantages like efficient utilization of resources.
    Because we are serving different areas with different security level I’m looking for best practices also.
    The main question is about security because CSM does not support virtual contexts like ACE.
    Any suggestions?
    Thanks.
    Andrea

    Hello Andrea,
    As you noted, the capability for ACE to be able to keep traffic segregated is much easier to work with than the CSM's.  Basically, you have to utilize both client groups and the VLAN statement under Vservers to be able to keep traffic segregated.  Here is an example:
    module ContentSwitchingModule 4
    vlan 100 client
      ip address 192.168.100.1 255.255.255.0
    vlan 150 client
       ip address 192.168.150.1 255.255.255.0
    vlan 200 client
       ip address 192.168.200.1 255.255.255.0
    vlan 250 client
       ip address 192.168.250.1 255.255.255.0
    natpool POOL-1 192.168.100.2 192.168.250.2 netmask 255.255.255.0
    natpool POOL-2 192.168.150.2 192.168.250.2 netmask 255.255.255.0
    natpool POOL-3 192.168.200.2 192.168.250.2 netmask 255.255.255.0
    natpool POOL-4 192.168.250.2 192.168.250.2 netmask 255.255.255.0
    serverfarm DMZ1
    nat server
    nat client POOL-1
    real 192.168.100.50
      no inservice
    real 192.168.100.51
      inservice
    real 192.168.100.52
      inservice
    serverfarm DMZ2
    nat server
    nat client POOL-2
    real 192.168.150.82
       no inservice
      real 192.168.150.83
       inservice
      real 192.168.150.84
       inservice
    serverfarm DMZ3
    nat server
    nat client POOL-3
    real 192.168.200.75
       no inservice
      real 192.168.200.78
       inservice
      real 192.168.200.90
       inservice
    serverfarm DMZ4
    nat server
    nat client POOL-1
    real 192.168.250.82
       no inservice
      real 192.168.250.83
       inservice
      real 192.168.250.84
       inservice
    vserver DMZ1
      virtual 192.168.100.10 tcp www
      vlan 100
      serverfarm DMZ1
      persistent rebalance
      inservice
    vserver DMZ2
      virtual 192.168.150.10 tcp www
      vlan 150
      serverfarm DMZ2
      persistent rebalance
      inservice
    vserver DMZ3
      virtual 192.168.200.10 tcp www
      vlan 200
      serverfarm DMZ3
      persistent rebalance
      inservice
    vserver DMZ4
      virtual 192.168.250.10 tcp www
      vlan 250
      serverfarm DMZ4
      persistent rebalance
      inservice
    In the above configuration, if any packet comes into vlan 100 destine to 192.168.100.10 on port 80, it can hit the vip.  If the same packet comes into any other vlan, it will not be able to hit the vip.  The "vlan 100" statement under DMZ1 vserver filters the traffic so that only traffic that came into that vlan can hit that specific vserver.
    If you need to do additional filtering, say by source subnet range, you can use client groups to furthur permit/deny traffic at a more granular level.  Here is an example:
    (The access-list is created globally on the 6500 - the access list is then referenced by number in the CSM configuration. ONLY standard access lists can be used!!)
    access-list 2 permit 192.168.0.0 0.0.255.255
    access-list 2 deny   any
    access-list 3 permit 10.10.0.0 0.0.255.255
    access-list 3 deny   any
    policy 192_subnet_filter
      client-group 2
      serverfarm DMZ4
    vserver DMZ4
       virtual 192.168.250.10 tcp www
       vlan 250
      slb-policy 250_subnet_filter
       persistent rebalance
       inservice
    With this configuration, only traffic with a source IP of 192.168.0.0/16 or 10.10.0.0/16 that arrive on vlan 250 will be allowed to hit the vserver. "Client-Group 2" refers to the "Access-list 2" in the global config.
    Note that the serverfarm that used to be under the vserver was removed.  If you leave the serverfarm DMZ4 statement under the vserver along with the slb-policy applied, and traffic that does not match your client group is sent to that serverfarm.  It is another way of filtering traffic out.  If you do not include a fallback serverfarm (like the example above), any traffic that doesn't match the client group is reset.
    Let me know if you have any furthur questions!
    Regards,
    Chris Higgins

Maybe you are looking for