Guest

Cisco SCA 11000 Series Secure Content Accelerators

Understanding Telnet, SNMP, and ICMP on the CSS in Transparent SCA Configuration

Cisco - Understanding Telnet, SNMP, and ICMP on the CSS in Transparent SCA Configuration

Document ID: 27787

Updated: Jan 31, 2006

   Print

Introduction

This document explains how Telnet, Simple Network Management Protocol (SNMP), and Internet Control Message Protocol (ICMP) will behave in a Content Services Switch (CSS) configuration that has two default gateways. Although there are several topologies where these certain behaviors have been seen, this document explains how they function in a Secure Socket Layer (SSL) one-armed transparent CSS/Secure Content Accelerator (SCA) configuration.

Before You Begin

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Prerequisites

There are no specific prerequisites for this document.

Components Used

The information in this document is based on the software and hardware versions below.

  • CSS 11000 running version 5.x and higher

  • SCA running 3.x and higher

  • SCA 2 running 4.x and higher

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Telnet, SNMP, and ICMP to the CSS

Telnet, SNMP, and ICMP to the CSS will either fail or perform erratically.

For those unfamiliar with the SCA, it is a stand alone device that encrypts/decrypts SSL traffic. The configuration uses the diagram shown below.

telnet_snmp_icmp.gif

The CSS has the following routes configured:

  • IP route 0.0.0.0 0.0.0.0 IP address of the router

  • IP route 0.0.0.0 0.0.0.0 IP address of the SCA

Clients initiate a HTTP flow to a content rule configured for 443 on the CSS. The CSS should MAC forward this request to the SCA to decrypt SSL traffic. Once the SCA has decrypted the request, it forwards the unencrypted request to another content rule on the CSS. This HTML request should hit a content rule which load balances the unencrypted request to a web server. The reply from the server goes back through the CSS to the SCA to be re-encrypted and forwarded back to the client.

Notice the CSS needs to have two default routes in this configuration, one to the upstream router and one to the SCA device. The default route to the SCA device is needed for the transparent configuration, which means that the client's IP address is not changed on the CSS or SCA device. The SCA can also perform a proxy setup where it changes the clients IP address to the IP address configured on the circuit; in this case, you do not need a second default route. The client’s IP address is not changed, and the reply back from the web server can go directly back to the client and not hit the SCA without this default route to the SCA. If the reply from the server does not get encrypted, the transaction will fail. The default route to the SCA exploits the fact the CSS uses an IP ECMP of prefer ingress. This means that the flow created from the SCA to the web server prefers the SCA port over the default routers port on the way back. This insures that the traffic back from the web server goes back to the SCA and not directly to the client.

Issues with Telnet, SNMP, and ICMP to the CSS

Certain clients are not able to Telnet into the CSS. Telnet will fail because of the two default routes configured on the CSS. The Telnet session could possibly follow the default route to the router and work, or follow the default route to the SCA and fail. Telnetting to a circuit IP address of the CSS is directed to the CSS and not through the CSS. Thus, a Telnet flow to the CSS will not follow the prefer ingress of the CSS. It will use a less specific form of ECMP, which is address based (by default) or round robin. If the IP ECMP address is configured on the CSS, even numbered IP addresses work, while odd numbered IP addresses fail. On the contrary, odd numbered IP addresses may work, and even numbered IP addresses may fail. It is important to understand that only one type of address will work, while the other fails.

Two workarounds for this issue are provided below.

  1. Configure a specific route with the option of originated packets. Originated packets only affect flows sourced from the CSS and not flows through the CSS. If you wanted clients in the 192.168.x.x subnet to Telnet/access the CSS, you would configure the following:

    IP route 192.168.0.0 255.255.0.0 IP address of the router originated-packets
    
    

    Any flows from a client in the 192.168.x.x subnet that needed to route or bridge through the CSS would not use this route.

  2. Configure a specific route without the option of originated-packets. In this case, the specific host subnet will not be able to test or work in the SSL one-armed transparent CSS/SCA configuration. Requests are sent directly back to the client without being sent to the SCA. You would configure the following:

    IP route 192.168.0.0 255.255.0.0 IP address of the router
    
    

    Note: If this subnet is needed for testing, the first workaround is the better choice.

Another issue is that ICMPs/SNMP will not work to the circuit address of the CSS. ICMP and SNMP are not considered flows on the CSS, and as such, the use of originated packets is not an option. Originated-packets only affect flows to the CSS. Originated packets specify that the route is used only by packets that are created using flows or sessions going to and from the CSS (for example, a Telnet session to the CSS). The route is not used by flows or sessions that go through the CSS (for example, between an attached server and a remote client). The optional originated-packets keyword instructs the CSS to use this route for flow and session packets going to and from the CSS (for example, a Telnet session to the CSS). Flows or session packets that go through the CSS (for example, between an attached server and a remote client), do not use this route.

In these cases, the customer will need to create a specific static route on the CSS to the subnet that wishes to access this information. As stated above, this subnet will not be able to test or use the SSL one-armed transparent configuration. All requests will fail.

Related Information

Updated: Jan 31, 2006
Document ID: 27787