Slow TCP performance for traffic routed by ACE module

Hi,
the customer uses two ACE20 modules in active-standby mode. The ACE load-balances servers correctly. But there is a problem with communication between servers in the different ACE contexts. When the customer uses FTP from one server in one context to the other server in other context the throughput through ACE is about 23 Mbps. It is routed traffic in ACE:-(  See:
server1: / #ftp server2
Connected to server2.cent.priv.
220 server2.cent.priv FTP server (Version 4.2 Wed Apr 2 15:38:27 CDT 2008) ready.
Name (server2:root):
331 Password required for root.
Password:
230 User root logged in.
ftp> bin
200 Type set to I.
ftp> put "|dd if=/dev/zero bs=32k count=5000 " /dev/null
200 PORT command successful.
150 Opening data connection for /dev/null.
5000+0 records in.
5000+0 records out.
226 Transfer complete.
163840000 bytes sent in 6.612 seconds (2.42e+04 Kbytes/s)
local: |dd if=/dev/zero bs=32k count=5000  remote: /dev/null
ftp>
The output from show resource usage doesn't show any drops:
conc-connections              0          0     800000    1600000          0
  mgmt-connections             10         54      10000      20000          0
  proxy-connections             0          0     104858     209716          0
  xlates                        0          0     104858     209716          0
  bandwidth                     0      46228   50000000  225000000          0
    throughput                  0       1155   50000000  100000000          0
    mgmt-traffic rate           0      45073          0  125000000          0
  connections rate              0          9     100000     200000          0
  ssl-connections rate          0          0        500       1000          0
  mac-miss rate                 0          0        200        400          0
  inspect-conn rate             0          0        600       1200          0
  acl-memory                 7064       7064    7082352   14168883          0
  sticky                        6          6     419430          0          0
  regexp                       47         47     104858     209715          0
  syslog buffer            794624     794624     418816     431104          0
  syslog rate                   0         31      10000      20000          0
There is parameter map configured with rebalance persistant for cookie insertion in the context.
Do you know how can I increase performance for TCP traffic which is not load-balanced, but routed by ACE? Thank you very much.
Roman

Default inactivity timeouts used by ACE are
icmp 2sec
tcp 3600sec
udp 120sec
With your config you will change inactivity for every protocol to 7500sec.If you want to change TCP timeout to 7500sec and keep the
other inactivity timeouts as they are now use following
parameter-map type connection GLOBAL-TCP
set timeout inactivity 600
parameter-map type connection GLOBAL-UDP
set timeout inactivity 120
parameter-map type connection GLOBAL-ICMP
set timeout inactivity 2
class-map match-all ALL-TCP
match port tcp any
class-map match-all ALL-UDP
match port tcp any
class-map match-all ALL-ICMP
match port tcp any
policy-map multi-match TIMEOUTS
class ALL-TCP
connection advanced GLOBAL-TCP
class ALL-UDP
connection advanced GLOBAL-UDP
class ALL-TCP
connection advanced GLOBAL-ICMP
and apply service-policy TIMEOUTS globally
Syed Iftekhar Ahmed

Similar Messages

  • NNM iSPI Performance for Traffic silentInstall*.properties missing for Linux

    HP -- I've been trying to figure out a way to get this information to you, and this is the best I could find.  When performing a silent installation of HP NNM iSPI Performance for Traffic, you need the silentInstallExt.properties, silentInstallMaster.properties, and silentInstallLeaf.properties files.  These files are not supplied with the Linux installation DVD image (Software_NNM_iSPI_Perf_Traf_Linux_9.20_Eng_TB770-15009.iso) -- you might want to remedy that.  If anyone needs to find the files for a silent install on Linux, you can get them from the Windows installation DVD image (Software_NNM_iSPI_Perf_Traf_10.00_Win_TB770-15014.iso) in the Traffic_NNM_Extension, Traffic_Master, and Traffic_Leaf directories.

    HP -- I've been trying to figure out a way to get this information to you, and this is the best I could find.  When performing a silent installation of HP NNM iSPI Performance for Traffic, you need the silentInstallExt.properties, silentInstallMaster.properties, and silentInstallLeaf.properties files.  These files are not supplied with the Linux installation DVD image (Software_NNM_iSPI_Perf_Traf_Linux_9.20_Eng_TB770-15009.iso) -- you might want to remedy that.  If anyone needs to find the files for a silent install on Linux, you can get them from the Windows installation DVD image (Software_NNM_iSPI_Perf_Traf_10.00_Win_TB770-15014.iso) in the Traffic_NNM_Extension, Traffic_Master, and Traffic_Leaf directories.

  • Question in regard to management VLAN for each Context in ACE module

    Dear Pros,
    I know this will be a simple questions to answer, and I have searched the forum, but I am not able to find the answer I need.
    1) Does the ACE module require an Management IP address for each Context? Should the same VLAN be applied to each context, with larger size subnet to supply host address?
    2) If it does require that, what IP address should I used for default route in each context.
    I will be utilizing "Bridge Mode" for my application to transition the current network from Foundry to ACE. I will later on apply the "Routed Mode" model.
    Each ACE module will have 3 seperate Context, for a total of 4 including the Admin.
    Any suggestions or if you can point me to location as always will be greatly apprecaited.
    Thanks and best regards.
    Raman Azizian

    Hi,
    you have several options to choose from.
    1. Use Admin context for management
    You can use the Admin context for management. Give it an IP address in your managment VLAN, default route to upstream router, and login and change to contexts from there.
    + Easy and straightforward
    - snmp and syslog are using the ip from each individual context and not the management IP
    2. Use a Large subnet and assign an IP address in each context for management.
    You can configure 1 managment VLAN and assign an IP address to each context in this subnet. Create static routes to the management stations that need to access this management address.
    + each context has its own managment address
    - static routes need to be added
    3. Use your client-side ip address (or BVI) as management address.
    You management traffic will be inline and use the same path as your data. Default route is already configured and also valid for the management.
    + no static routes needed
    - inline management
    Personally, I choose option 1. That is, if the people that need to manage the ACE is the same team.
    If other teams (serverteam for context 1, other serverteam for context 2) need to manage the ACE, than I would choose option 3.
    HTH,
    Dario

  • Slow svn performance for svn:// style links

    I have a large collection of scripts out my control. One of the things they do, is call svn with links in form  "svn://...".
    The problem is, that calling:
    svn info "svn://..."
    stops everything for 2 minutes and then starts authentication with ssh.
    Calling directly:
    svn info "svn+ssh://.."
    takes less then a second.
    What could be the problem? I don't see the same problem in other centos systems so it must be something with the newer subversion.
    Does anyone has any ideas what's happening (or not happening)?

    I check strace, noticed, that it was timing out on polls on the ip of the svn repo. That seemed strange.
    In the end I found that adding this:
    #/etc/hosts
    127.0.0.1 <myhostname>
    fixed it.. no clue why.

  • Waas traffic interseption with ace

    i will use ACE for waas traffic interception and i need help in:
    1. if i used ace so there is no need to wccp for traffic interception Right?
    2.if i used ace should i make 3 vlans vlan10 for clints(face wan) vlan12 for waes & vlan11 for datacenter
    make in 6500 interface vlan10 and give it ip 10.1.1.1 should i give interface vlan10 in ACE 10.1.1.1 (the same ip in 6500& ace) is taht logical to give same interafce vlan ip in two devices or will taht generate duplicated ip error
    3.if it right can i make static route in ACE to 6500 interface vlan10"ip route 0.0.0.0 0.0.0.0 10.1.1.1"?
    4.when i define access-list in ace to define traffic which could be routed through ACE if I deny certain network (permit only network that i wand to redirect to WAEs)will the other traffic routed through 6500 to core) i will use "transparent" in server farm & no ip normal. in other words can i consider access-list in ACE like access-list i'm using in wccp.
    5.the topology i have 2 6500 and i will install 2 ACE (1 ACE in each 6500) and i will attach 1 WAE in each 6500 switch one vlan for WAEs and i will make server farm and allocate 2 WAEs in it and i will define server farm in 2 ACEs and make default route in to ACEs to interface vlan 10.1.1.1 in this way will ACE load balance btween 2 WAEs and traffic interception work well or not?
    and finally i'm sorry for these many questions but i think i will find the answers.

    Usama,
    Here are the answers to your questions:
    1. Correct.
    2. You would not configure the same IP address on the ACE and MSFC. As far as how the VLANs should be configured, that somewhat depends on your deployment. What you have described would be common if you are deploying ACE in bridged mode. In routed mode, you can deploy ACE in a one-arm configuration.
    3. Yes.
    4. ACE does not pass traffic by default. You must explicitly permit the traffic you want to pass. Said differently, if you do not permit the traffic in your ACL, it will be dropped.
    5. If you are using a single context in ACE, they will be active/passive (i.e. only one ACE module will handle traffic at any given point in time). The configuration will automatically be synchronized between the active and passive modules.
    How are you planning to get traffic to the ACE module?
    Zach

  • Kapsel Fiori Client (FC): self-built iOS FC shows very slow UI performance

    Hi Experts,
    I have used KapselSDK to build our own FC using:
    SMP3.0 KapselSDK SP07_PL00
    Cordova 3.6.3
    Xcode 6.2
    OS X 10.10.2 Yosemite
    Enterprise distribution certificate for deplyment
    .ipa for iPhone4S, 5 (tested)
    ipd also inside Airwatch (tested)
    App config:
      SMP proxy is not used.
    The issue:
    We use FC to launch the Fiori Launchpad where there are some Fiori apps. The problem is that after type usr pwd, it took very long time to see the Launchpad UI. Tried the standard FC from Apple Store, and it worked very fast.
    Does anyone have any idea? I see some info about the slow UI performance for Android devices which can be solved using crosswalk, but my understanding is that crosswalk is not for iOS.
    Thanks.
    Dong

    Have you tired testing the same URL through Mobile Safari to see if it is slow also?
    We have had reports of slowness on iOS and we are researching.  The details are iOS uses HTTP pipelining when the connection is slow. This means iOS bundles several requests (2-3 to our observations) together but the ICM does only response to one of them and ignores the others. After a timeout of about 1 minute (transparent to the FLP) the Safari automatically repeats the ignored requests. It may happen that this happens a second time, but not a third time – then the requests are not repeated anymore.  Seems to happen in Mobile Safari Browser more often than Fiori Client and doesn't happen in Mobile Chrome on same device.
    Thanks,
    Kevin Bates
    SAP AGS

  • ACE Module vs ACE Appliance

    Hello,
    What is the difference between ACE Module and ACE Appliance? why the ACE Module is better? or ACE Appliance, what is the advantage between Module and Appliance.
    anyone can explain me?
    Best Regards

    In the past Cisco has been shipping two line of Loadbalancing products
    First line ( modules dedicated for 6500/7600 chassis ) includes CSM & CSM-S & SSLSM (for ssl offloading)
    The other line comprises of appliance based CSS series products.
    ACE module is a next generation module replacing CSM modules that fits into 6500/7600 chassis.
    It gives you upto 16Gbps throughput (versus CSM's 4Gbps throughput).
    ACE appliance is a next gen replacement of CSS line of appliance based products.
    CSS appliances were used to come in different Hardware models with varied
    performance capacities. ACE appliance is a single hardware with various licenses
    used to scale the performance/features.Ace appliance supports upto 4Gbps of throughput.
    Previously CSS & CSM code terminologies & command set was different. For example a real server
    was termed as "service" in CSS & was called "real" in CSM . Similarly "probe" in CSM was "keepalive"
    in CSS.
    With ACE line of products you get the same terminologies & command sets for both
    modules & Appliances.
    ACE Appliance & ACE modules are functionality vise coming closer with every new release but
    still there are some differences.
    For example following ACE appliance features are not available in ACE module:
    Appl optimization (flash forward, Delta Encoding)
    Embedded Device manager
    Http compression
    Which one is better than the other really depends on your requirement
    From Performance perspective Module give you much higher performance then Appliance.
    SO if performance is your criteria the ACE module is better than ACE appliance.(Some performance metrics at the end of the post).
    If you are looking for Application optimization & HTTP compression along with Loadbalancing
    then it can only be achieved with ACE appliance.
    If you are not using 6500/7600 series chassis in your environment then you can only use ACE appliance
    (unless you are open to buy module+chassis due to performance requirement).
    Some performance metrics
    Ace Appliance supports 1 Million concurrent connections where as Ace Module supports 4 Million.
    Ace Appliance supports 120K L4 conn/sec where as Ace Module supports 380K L4 conn/sec.
    Ace Appliance supports 40K L7 conn/sec where as Ace Module supports 133K L7 conn/sec.
    Ace Appliance supports upto 4Gbps throughput where as Ace Module supports 16Gbps throughput .
    HTH
    Syed Iftekhar Ahmed

  • ACE module SSL url rewrite and path rewrite

    Hi all,
    I'm hoping some of you helpful people on this forum can guide me or suggest a solution to a problem I'm faced with.
    I am currently load balancing exchange 2010 traffic via an ACE module.  Software version is A2(3.3).  I have most parts of it working fine however I am having an issue when it comes to SSL termination for Outlook Web Access (OWA).
    The problem comes down to a HTTP header (field is location).  I have configured an action list to re-write the SSL pure URL as per page 96 of the "Cisco Application Control Engine Module SSL Configuration Guide".  example:
    ssl url rewrite location bnecas\.mycompany\.com sslport 443
    That part works, the http header location field that comes back from the GET request is changed to https://cas.mycompany.com which is great.  However, in addition to that url, there is also a path or something following that part.  The actual string that is returned is:
    https://cas.mycompany.com/owa/auth/logon.aspx?url=http://cas.mycompany.com/owa/&reason=0
    The first bit of it, (https://cas.mycompany.com) is changed by the ssl url rewrite command, however the last part (http://cas.mycompany.com/owa/&reason=0) isn't changed.
    This is where I've been trying to get the http Header Rewrite command to do something.  I don't know if it can work in conjunction with the ssl url rewrite function however with the ssl rewrite function it seems it can't change bits of the string that aren't the pure URL at the front.
    The end result is that while I have an SSL connection to the OWA login page, when I do login to OWA it reverts back to HTTP.  I'm fairly sure it is because of the last part of the location string above.  Is there a way to change that location string to do the following:
    1.  change the first part of the string to be https://cas.mycompany.com (like the ssl url rewrite function)
    2.  change the last part of the location string to put https in there instead of http
    Ideally I would love to have this string
    http://cas.mycompany.com/owa/auth/logon.aspx?url=http://cas.mycompany.com/owa/&reason=0
    replaced with this one
    https://cas.mycompany.com/owa/auth/logon.aspx?url=https://cas.mycompany.com/owa/&reason=0
    I had originally tried the following in the action list:
    header rewrite response location header-value "(owa/auth/logon\.aspx\?url=)http(://bnecas\.thiess\.aus/owa/&reason=0)" replace "%1https%2"
    ssl url rewrite location bnecas\.mycompany\.com sslport 443
    but it didn't work.  I'm probably screwing up the regex somewhere however there doesn't seem to be very clear examples anywhere I can find.
    Any help will be greatly appreciated and of course I will be sure to rate every post that responds to my plea for help.
    Brad

    Hi Brad,
    try this:
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-qformat:yes;
    mso-style-parent:"";
    mso-padding-alt:0in 5.4pt 0in 5.4pt;
    mso-para-margin:0in;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:11.0pt;
    font-family:"Calibri","sans-serif";
    mso-ascii-font-family:Calibri;
    mso-ascii-theme-font:minor-latin;
    mso-fareast-font-family:"Times New Roman";
    mso-fareast-theme-font:minor-fareast;
    mso-hansi-font-family:Calibri;
    mso-hansi-theme-font:minor-latin;
    mso-bidi-font-family:"Times New Roman";
    mso-bidi-theme-font:minor-bidi;}
    action-list type modify http X
      header rewrite response Location header-value "http://(.*url=)http://(.*)" replace "https://%1https://%2"
    we wont be using ssl url rewrite in this case
    Also we will be needing persistence rebalance applied through application parameter map and apply that under the VIP class

  • Want to know about ACE module in 6509 : load-balancing concept

    Hi,
    I am quite new in this field , where i need to configure and understand the concept of load-balancing through ACE.
    In my existing network set-up , i have some application servers as well as some other servers where i am looking for load-balancing.
    I have gone through some of the site and cisco site as well and i came across ACE module which can be installed in 6509 switch.
    I have 6509 switch as well but before going for installing the ACE module I am keen to understand below things:
    1) what is difference between CSM or any other product load-balancer and ACE module :
    Gone through site as well , but not getting proper answer or comparison.
    1) I have some of the server configured with clustering and getting one virtual IP, In this case , will ACE work ?
    2) If suppose i go for configuring different IP address with all server IP :
    How do i achieve it ?
    3) what is Virtual IP concept in ACE because i do not have and other ACE module then why do i need virtual IP ?
    4) will the load-balancing happens based on destination based or session based ?
    Please share the knowledge. It would be great help for me to go ahead with ACE and configure it and understand all the application ?

    Hello,
    1) what is  difference between CSM or any other product load-balancer and ACE  module :
    There are several differences but to say simply, you get higher performance and more features with ACE module/appliance comparing others.
    One big difference is that with ACE seriese, you can configure multiple contexts on one box (virtual load-balancers on one box) that makes us possible to provide a virtual load-balancer to a customer. In that way, the customer can access and makes changes on only the virtual box. You can split management domain for each customers. Also using contexts, you can assign certain resources available on the hardware for each contexts according to their service contract.
    ACE serise has specific hardware chip for supporting SSL termination but some others do not.
    For instance, you need a CSM-S, or a CSM and a SSL module to terminate SSL.
    The other thing I should mention is that our most recent product is ACE serise that means it has longer product roadmap.
    Let me try clarifying your other questions.
    3)  what is Virtual IP concept in ACE because i do not have and other ACE  module then why do i need virtual IP ?
    4) will the load-balancing happens  based on destination based or session based ?
    I think I'd better to put 3) and 4) first.
    Virtual ip  address (VIP) is the address to which client accesses.
    VIP is tied with a  serverfarm or serverfarms, in a serverfarm one or multiple rservers can  be configured.
    "serverfarm" is a group of "rservers".
    "rserver" means  real-server that has an ip address and processes transactions.
    When a client  accesses to the VIP, ACE picks up a rserver according to algorithm.
    If you configure a  VIP that is tied with a serverfarm where only one rsever is  configured, client accesses to the virtual ip address are
    all forwarded to  the rserver.
    If you configure a  VIP that is tied with a serverfarm where multiple rsevers are  configured,  client accesses to the virtual ip address are
    balanced among  those rservers.
    If you configure  multiple VIPs, client accesses to those VIPs are forwareded to  corresponding rservers according to configuration.
    1)  I have some of the server configured with clustering and getting one  virtual IP, In this case , will ACE work ?
    ACE load-balances connections to configured rservers.
    If the clustered servers are sharing one virtual ip address and you configure the virtual ip address as a rserver, all connections are
    sent to the virtual ip address. That is not "load-balancing" on ACE... You need multiple rservers to which ACE load-balances connections.
    2) If suppose i go for  configuring different IP address with all server IP :
    How do i  achieve it ?
    You can configure those ip addresses as rserver ip address.
    Multiple rservers are tied into a group, "serverfarm".
    I'm not certain about your culstered servers but I guess you can configure each ip addresses in the culster as rservers.
    Then put those rservers in a serverfarm.Client accesses to a virtual ip address configured on ACE for the serverfarm.
    This way connections are load-balanced among those rservers depending on load-balancing algorithm you choose.
    Above is just an overveiw. ACE gives you granular control not mentioned above.
    I can provide more specific information if you tell me details of what you are trying to archive with ACE.
    Regards,
    Kimihito.

  • ASA5500: TCP state bypass for traffic, coming from IPsec tunnel

    Hello!
    We have problems on central firewall with restricting traffic coming from remote office from IPsec. (The network sheme is attached)
    All branch offices are connected to central asa though IPsec.
    The main aim is to rule access from branch offices only on the central firewall, NOT on each IPsec tunnel
    According to the sheme:
    172.16.1.0/24 is on of the branch office LANs
    10.1.1.0/24 and 10.2.2.0/24 are central office LAN
    The crypto ACL looks like  permit ip 172.16.1.0/24 10.0.0.0/8
    The aim is to
    restrict access from 172.16.1.0/24 to 10.1.1.0/24
    When packets are generated from host 10.1.1.10 to 172.16.1.0/24 all is ok -  they are dropped by acl2
    When packets are generated from 172.16.1.0/24 to 10.1.1.10 they are not dropped by any ACL - the reason is stateful firewall - traffic bypasses all access lists on a back path
    I thought that TCP State Bypass feature can solve this problem and disable stateful firewall inspection for traffic coming from 172.16.1.0/24 to 10.1.1.0/24, but it didn't help.
    The central asa 5500 is configured according to cisco doc http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_tcpstatebypass.html
    access-list tcp_bypass_acl extended permit tcp 172.16.1.0 255.255.255.0 10.1.1.0 255.255.255.0
    class-map tcp_bypass_map
    description "TCP traffic that bypasses stateful firewall"
    match access-list tcp_bypass_acl
    policy-map tcp_bypass_policy
    class tcp_bypass_map
    set connection advanced-options tcp-state-bypass
    service-policy tcp_bypass_policy interface outside
    service-policy tcp_bypass_policy interface inside
    Does anyone know, how to make TCP State Bypass works properly?

    I understand the pain of creating diffrent crypto for diffrent tunnels but i never come across better solution. However TCP state bypass is not going to help in regards to restrict access. TCP state bypass is a way to for FW to act like router which does not do statefull and I dont think that fits in your scenario.
    You can still control access on center site by using vpn-filters.
    http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00808c9a87.shtml
    Thanks
    Ajay

  • NAT list getting hit for traffic from WAN IP

    I have an 871 setup at home with a fairly basic configuration (NAT, Firewall, EasyVPN, Wireless). What I've noticed is that for traffic going from the WAN interface (FastEthernet4), it seems to be hitting the ACL in place for NAT. My config:
    interface Loopback0
    ip address 192.168.254.1 255.255.255.255
    interface FastEthernet4
    description Cable Modem Connection
    bandwidth 384
    ip address dhcp
    ip nat outside
    ip nat enable
    no ip virtual-reassembly
    duplex auto
    speed auto
    interface Vlan1
    no ip address
    bridge-group 1
    interface BVI1
    ip address 192.168.1.1 255.255.255.0
    ip nat inside
    ip virtual-reassembly
    ip nat inside source list NATLIST interface FastEthernet4 overload
    ip access-list extended NATLIST
    permit ip 192.168.1.0 0.0.0.255 any
    deny ip any any log
    Seems to work just fine, but I will see this in my logs:
    Oct 30 17:21:38 PDT: %SEC-6-IPACCESSLOGP: list NATLIST denied udp 76.22.98.39(0) -> 68.87.69.146(0), 1 packet
    Oct 30 17:21:38 PDT: %SEC-6-IPACCESSLOGP: list NATLIST denied udp 76.22.98.39(0) -> 140.142.16.34(0), 1 packet
    Oct 30 17:21:56 PDT: %SEC-6-IPACCESSLOGDP: list NATLIST denied icmp 76.22.98.39 -> 24.64.94.41 (0/0), 1 packet
    Oct 30 17:23:38 PDT: %SEC-6-IPACCESSLOGP: list NATLIST denied udp 76.22.98.39(0) -> 207.188.29.230(0), 1 packet
    Oct 30 17:25:38 PDT: %SEC-6-IPACCESSLOGDP: list NATLIST denied icmp 76.22.98.39 -> 121.18.13.100 (0/0), 2 packets
    Oct 30 17:27:38 PDT: %SEC-6-IPACCESSLOGDP: list NATLIST denied icmp 76.22.98.39 -> 24.64.94.41 (0/0), 1 packet
    Where 76.22.98.39 is the dynamic IP address from the cable provider. If the traffic isn't passing through the router, why is it trying to NAT it?
    IOS Version is 12.4(6)T9

    Hello Brom,
    I am facing the same situation that I can see a whole bunch of log-entries which state that IP-packets with the source address of the routers own WAN-interface-address are trying to reach a variety of IPs somewhere out there.
    I don't feel fine with just ignoring something - in only very rare situations this has been a good advise. I believe this is not a solution.
    There's just one naging question you should be able to answer.
    Since when needs the routers traffic translation? If the router sends packets because it want's to reach a destination for some reason it uses as source-address the address of the interface the traffic is supposed to leave and send's it directly there, doesn't it?
    So why in the world are there thousends of packets denied by the NAT-process (ofcourse, the NATACL doesn't allow this address), all showing the same pattern
    (pattern == protocol=udp AND source=ownWANIP AND port=0 AND destination=someIPoutthere AND port=0) as you can see from the following output, cause I think this is supicious and tryed it - wow! How do these packets get to the NAT-process anyway?!
    000894: Oct 10 06:57:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000895: Oct 10 06:58:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 4 packets 
    000896: Oct 10 06:59:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000897: Oct 10 06:59:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000898: Oct 10 07:02:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000899: Oct 10 07:04:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 16 packets 
    000900: Oct 10 07:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 
    000901: Oct 10 07:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 
    000902: Oct 10 07:08:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000903: Oct 10 07:09:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 5 packets 
    000904: Oct 10 07:11:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000905: Oct 10 07:11:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000906: Oct 10 07:13:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000907: Oct 10 07:14:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 14 packets 
    000908: Oct 10 07:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 
    000909: Oct 10 07:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 
    000910: Oct 10 07:18:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 
    000911: Oct 10 07:19:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 2 packets 
    000913: Oct 10 07:22:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 
    000914: Oct 10 07:22:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 3 packets 
    000915: Oct 10 07:23:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 
    000916: Oct 10 07:24:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 8 packets 
    000917: Oct 10 07:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 3 packets 
    000918: Oct 10 07:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 
    000919: Oct 10 07:29:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 3 packets 
    000920: Oct 10 07:30:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 2 packets 
    000921: Oct 10 07:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 3 packets 
    000922: Oct 10 07:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 3 packets 
    000923: Oct 10 07:34:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 
    000924: Oct 10 07:35:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 24 packets 
    000925: Oct 10 07:38:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 
    000926: Oct 10 07:38:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 
    000928: Oct 10 07:39:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 3 packets 
    000929: Oct 10 07:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 1 packet 
    000930: Oct 10 07:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 
    000931: Oct 10 07:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 
    000932: Oct 10 07:44:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 
    000936: Oct 10 07:47:35: %SEC-6-IPACCESSLOGP: list FAE00IN denied tcp 222.173.130.154(6000) -> 212.152.155.204(1433), 1 packet 
    000937: Oct 10 07:49:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 2 packets 
    000938: Oct 10 07:49:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 
    000939: Oct 10 07:49:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 
    000940: Oct 10 07:50:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 
    000941: Oct 10 07:54:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 5 packets 
    000942: Oct 10 07:54:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000943: Oct 10 07:54:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000946: Oct 10 07:56:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 
    000947: Oct 10 08:00:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 7 packets 
    000948: Oct 10 08:00:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 
    000949: Oct 10 08:00:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 
    000950: Oct 10 08:01:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000951: Oct 10 08:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 15 packets 
    000952: Oct 10 08:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000953: Oct 10 08:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000954: Oct 10 08:06:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000956: Oct 10 08:10:26: %SEC-6-IPACCESSLOGDP: list FORNAT denied icmp 212.152.155.204 -> 172.16.0.151 (0/0), 1 packet 
    000957: Oct 10 08:10:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 6 packets 
    000958: Oct 10 08:10:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000959: Oct 10 08:10:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000960: Oct 10 08:11:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000961: Oct 10 08:14:49: %SEC-6-IPACCESSLOGP: list FAE00IN denied tcp 216.133.175.69(2087) -> 212.152.155.204(5900), 1 packet 
    000962: Oct 10 08:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000963: Oct 10 08:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 11 packets 
    000964: Oct 10 08:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 
    000966: Oct 10 08:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 
    000968: Oct 10 08:21:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000969: Oct 10 08:21:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 6 packets 
    000970: Oct 10 08:21:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000971: Oct 10 08:21:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000972: Oct 10 08:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 
    000973: Oct 10 08:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 3 packets 
    000974: Oct 10 08:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000975: Oct 10 08:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000976: Oct 10 08:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000977: Oct 10 08:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 29 packets 
    000978: Oct 10 08:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 
    000979: Oct 10 08:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 
    000980: Oct 10 08:38:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000981: Oct 10 08:39:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000982: Oct 10 08:39:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000983: Oct 10 08:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 
    000984: Oct 10 08:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 1 packet 
    000985: Oct 10 08:44:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000986: Oct 10 08:44:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000987: Oct 10 08:49:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 2 packets 
    000988: Oct 10 08:50:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000989: Oct 10 08:50:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000990: Oct 10 08:52:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000991: Oct 10 08:54:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 5 packets 
    000992: Oct 10 08:59:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 6 packets 
    000993: Oct 10 08:59:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000994: Oct 10 08:59:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000995: Oct 10 09:00:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    000996: Oct 10 09:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 17 packets 
    000997: Oct 10 09:07:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    000998: Oct 10 09:07:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    000999: Oct 10 09:09:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    001002: Oct 10 09:10:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 7 packets 
    001003: Oct 10 09:15:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 14 packets 
    001004: Oct 10 09:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    001005: Oct 10 09:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    001006: Oct 10 09:17:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    001007: Oct 10 09:21:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 6 packets 
    001008: Oct 10 09:24:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    001009: Oct 10 09:24:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    001010: Oct 10 09:26:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    001012: Oct 10 09:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 4 packets 
    001013: Oct 10 09:32:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 26 packets 
    001014: Oct 10 09:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    001015: Oct 10 09:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    001016: Oct 10 09:35:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    001017: Oct 10 09:37:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 1 packet 
    001018: Oct 10 09:41:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    001019: Oct 10 09:41:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    001020: Oct 10 09:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 
    001021: Oct 10 09:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 1 packet 
    001022: Oct 10 09:48:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 74 packets 
    001023: Oct 10 09:50:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 
    001024: Oct 10 09:50:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 
    001027: Oct 10 09:52:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

  • Slow TCP duplex handling on remote connections

    Hi!
    I am working on a TCP client server architecture for a RPC-based LV code execution.
    Now, when running TCP with one TX and one RX in the same while loop everything becomes extremely slow. The RX-TX of data goes to about 2Hz when running on a remote machine on my network, and to about 1000Hz when i run the same locally.
    Could I have some explanation of this by some NI engineer? Am I missing something obvious here?
    Attached a project zip containing a TCPDuplex vi.
    Thankful for help,
    Roger Isaksson
    Attachments:
    TCPDuplex.zip ‏18 KB

    RogerI wrote: 
    Now, when running TCP with one TX and one RX in the same while loop everything becomes extremely slow. The RX-TX of data goes to about 2Hz when running on a remote machine on my network, and to about 1000Hz when i run the same locally.
    Could I have some explanation of this by some NI engineer? Am I missing something obvious here?
    Attached a project zip containing a TCPDuplex vi. 
    Shot in the dark here, but I'm going to guess that this is not a LabVIEW issue.  Have you been able to demonstrate that this doesn't happen with code written in another language?
    I suspect that Nagle's algorithm is disabled for loopback connections, and enabled for remote ones.  This could explain the speed difference you're seeing, because data going to the local machine would not be delayed, but data for the remote machine would be.  It would also make sense to disable Nagle's algorithm for local data since there's no penalty in overhead and network traffic.  If you search this forum for Nagle Algorithm you can find ways to disable it; see if that makes a difference.
    EDIT: By the way, if this turns out to be the correct explanation, you could probably solve it by using a single TCP connection for communication in both directions.  What is the advantage in your application to establishing two separate connections?  Also, your ZIP file is missing the Data Client VI.
    Message Edited by nathand on 03-28-2010 06:26 PM

  • ACE Module Routed design

    Hi all,
    I have a requirement to install 2 ACE Modules into two 6509 chassis'
    We want to run the ACE modules in a live/live scenario so we can utilise the two ACE modules
    So we want to split the VIPS so we have some live on one ACE and others on the other.
    Also the ACE modules will be setup in routed mode. We have a number of subnets we want to use on the client side - 3 to be exact, and there will be another 3 different subnets on the server side
    A few points which are confusing me
    For each subnet would i have to configure a SVI? And if so you can only have 1 SVI per contect so that would mean creating a context and a SVI for each subnet?
    Are there any example configs which could help me out?
    Any help would be appreciated
    Thanks
    James

    See the config example here:
    http://www.cisco.com/en/US/products/hw/modules/ps2706/products_configuration_example09186a00809c3048.shtml
    Normally you only need one client-side subnet per context, but multiple ones work too.
    You'd create an SVI on MSFC for the client-side subnets only, otherwise server traffic would bypass the ACE.
    Also keep in mind when you do active/active, it's done on the context level.
    That means you need to create at least two contexts in addition to the Admin context. (although you can technically run things in /Admin)
    Go through the example above, and the config guides below and you'll be all set:
    http://www.cisco.com/en/US/products/ps6906/tsd_products_support_model_home.html

  • ACE module rservers multiple routed hops away

    Hi all, deploying a ACE module in a cat6k. Just want to figure out, can I add to a serverfarm, rservers which are multiple routed hops away from the ACE or the cat6k in which it is deployed. please look at the attached diagrams. I have my servers at two subnets, and I want to add all 5 servers to the same server farm and load balance between them
    Is this possible, if any what are the caveats ?
    Thanks all

    Hi,
    You can do this, but ypu have to use client-NAT to force the return traffic to pass back through the ACE. You also then need static routes in the ACE context to point at each server.
    The following extract from a configuration shows the basic principle:
    rserver host master
    ip address 10.199.95.2
    inservice
    rserver host slave
    ip address 10.199.38.68
    inservice
    serverfarm host FARM-web2-Master
    description Serverfarm Master
    probe PROBE-web2
    rserver master
    inservice
    serverfarm host FARM-web2-Slave
    description Serverfarm Slave
    probe PROBE-web2
    rserver slave
    inservice
    class-map match-any L4VIPCLASS
    2 match virtual-address 10.199.80.12 tcp eq www
    3 match virtual-address 10.199.80.12 tcp eq https
    policy-map type management first-match REMOTE-MGMT-ALLOW-POLICY
    class REMOTE-ACCESS
    permit
    policy-map type loadbalance first-match LB-POLICY
    class class-default
    serverfarm FARM-web2-Master backup FARM-web2-Slave
    policy-map multi-match L4POLICY
    class L4VIPCLASS
    loadbalance vip inservice
    loadbalance policy LB-POLICY
    loadbalance vip icmp-reply active
    loadbalance vip advertise
    nat dynamic 1 vlan 384
    service-policy input L4POLICY
    interface vlan 383
    description ACE-web2-Clientside
    ip address 10.199.80.13 255.255.255.248
    alias 10.199.80.12 255.255.255.248
    peer ip address 10.199.80.14 255.255.255.248
    access-group input ACL-IN
    access-group output PERMIT-ALL
    no shutdown
    interface vlan 384
    description ACE-web2-Serverside
    ip address 10.199.80.18 255.255.255.240
    alias 10.199.80.17 255.255.255.240
    peer ip address 10.199.80.19 255.255.255.240
    access-group input PERMIT-ALL
    access-group output PERMIT-ALL
    nat-pool 1 10.199.80.20 10.199.80.20 netmask 255.255.255.240 pat
    no shutdown
    ip route 0.0.0.0 0.0.0.0 10.199.80.9
    ip route 10.199.95.2 255.255.255.255 10.199.80.21
    ip route 10.199.38.68 255.255.255.255 10.199.80.21
    HTH
    Cathy

  • Continued SLOW online performance after two Archive & Installs

    Hi.
    I have been living with slow online performance – pages slow to load, movies very slow to load, movies don't play back smoothly, constant buffering – for some 3-4 months before trying to do something about it... (this timeline coincides with a potential Security Update 2008-006 issue discussed here: http://discussions.apple.com/thread.jspa?threadID=1730909&tstart=0 , but I don't have enough savvy to know if that's the problem.)
    Equivalent slow performance in both Safari and Firefox... I've compared the same sites I visit on other peoples workstations, PC and Mac, various ISPs – all of their pages and movies light up and play instantly.
    Tried to research and do as much as I could before coming here, but I don't have great diagnostic skills... here's what I've got so far:
    By late November, I managed to eliminate the ISP (Earthlink) as a cause of the problem... however, due to their direction to change DNS numbers, I can no longer automatically connect online upon booting, but must repeatedly connect via Internet Connect (separate issue?)... via these forums, I've reset the DNS to 208.67.220.220, 208.67.222.222.
    Neither hard drive is even half full.
    I did an initial Disk and Permissions Repair prior to first A&I... they needed repair then, but subsequent verifications check out clean.
    After the first A&I (using the original OS X 10.4 install disk), I downloaded a complete full 10.4.11 update, including all current Security Updates... performance wound up much the same as before.
    After the second A&I, and before any updating, I tested online performance – still slow... this time I downloaded only the Mac OS X 10.4.11 Combined Update from November 07, looking to avoid the 2008-006 Security Update... general browsing speed is slightly improved, but any site with a movie or rich graphics behaves like dial-up, as before... Mail is just ok – not fast, but not problematic.
    Otherwise, the Mac works well enough, but it's never been a real speed-burner, imo... mainstream graphics apps (Adobe CS2, Quark 6)... the only atypical thing I might have is a Wacom graphics tablet (Intuos 3), but it's always worked fine... no games or brand-X playtime software.
    The only other thing I'd be suspicious of is Network Settings, after getting the runaround at Earthlink... but the fact that I can get online at all might rule that out.
    I've been at this for days, and am out of ideas... little help?
    Thanx.

    OK, network settings is the scary stuff that I DO NOT understand...
    BDAqua wrote:
    Make a New location in Network>Location>New, try it without PPoE, just Using DHCP under the TCP/IP tab>IPv4 setting. You can always switch back if it doesn't work.
    I found the PPPoE subpane.
    Made the New location, it seemed to work briefly, then didn't, then I fumbled my way back to prior settings... I'm willing to try it again, BUT...
    What scared me was that after setting New Location, the browser window opened to something called *Internet Configurator*, never seen this before... it asked for my email and password... is this normal?... I've got major privacy and security concerns and DO NOT want to put that password out there if I don't have to.
    Please advise before I do this... thanks.

Maybe you are looking for