Guest

Cisco Services Modules

Understanding CSM ARP Behavior

Cisco - Understanding CSM ARP Behavior

Document ID: 63158

Updated: Mar 16, 2006

   Print

Introduction

This document describes Address Resolution Protocol (ARP) behavior on the Content Switching Module (CSM).

This document provides information on:

  • why the CSM may not send ARP requests for certain hosts

  • why the CSM may not refresh entries in its ARP cache

  • why the CSM may refuse connections from certain hosts

Before You Begin

Requirements

Readers of this document should have knowledge of these topics:

  • basic CSM configuration

  • ARP protocol (STD 37)

Components Used

The information in this document is based on these hardware and software versions:

  • all versions of CSM software up to, and including, 4.1.x

Conventions

For more information on document conventions, refer to Cisco Technical Tips Conventions.

CSM ARP Behavior

Network Diagram

This document uses this network setup.

csmarp.gif

In this network diagram, the CSM is shown in routed mode, with one client VLAN and one server VLAN. The client VLAN is referenced, and the server VLAN is shown for completeness only. The important components of the network diagram are:

  1. A router or gateway (192.168.10.1) connecting the client VLAN to other parts of the network.

  2. A client or host (192.168.10.200) in the client VLAN.

  3. The CSM interface (192.168.10.127) in the client VLAN.

CSM ARP Requests

The CSM only sends ARP requests for:

  • configured gateways

  • configured reals

Gateways are configured on the CSM by:

  • using the gateway command

  • a next-hop in a route command

Both commands are applied under the CSM interface configuration:

 

vlan 499 client
  ip address 192.168.10.127 255.255.255.0
  route 192.168.40.0 255.255.255.0 gateway 192.168.10.1
! 

vlan 499 client
  ip address 192.168.10.127 255.255.255.0
  gateway 192.168.10.1
!            

The first example uses a specific route, and the second example uses the gateway command.

Real servers need to be defined under a serverfarm. It is not required that the serverfarm is associated with a vserver for the CSM to send ARP requests for the real servers under a serverfarm. An example of real servers under a serverfarm:

 serverfarm REALWWW
  nat server
  no nat client
  real 192.168.20.200
   inservice
  real 192.168.20.201
   inservice
!

In this example, the CSM sends ARP requests to learn the MAC address of the configured gateways and real servers. When the ARP entry expires (default timeout is 4 hours or 14400 seconds), the CSM refreshes such ARP entries automatically. If the CSM does not get a response to its ARP request, it tries again (the default interval is 5 minutes or 300 seconds). The CSM does not send ARP requests for any other devices than configured gateways or real servers.

CSM ARP Learning

The CSM can learn the ARP mappings of hosts that are not real servers or gateways on the VLANs it is connected to. This happens when such a host makes an ARP request, for example, a virtual IP address of a vserver configured on the CSM. In the network diagram, this could happen if the client (192.168.10.200) makes an ARP request for a virtual IP address in VLAN 499.

The CSM does not accept any connection from a host for which the CSM does not have an ARP entry in that VLAN. The CSM drops packets from a source IP address for which it does not have the corresponding source MAC address. Note that this is not an issue for packets routed through a gateway known to the CSM or sourced by a real known to the CSM. The CSM should always have an ARP entry for such IP addresses, as described in the previous section.

A change in this behavior was introduced with CSM software 3.2.1 via the route lookup feature. In the event that a packet arrives with an unknown source MAC address, this feature determines where to send the return traffic. This feature allows:

  • packets not to be dropped

  • packets to use the gateway of that route to send the return traffic to

CSM ARP Timeout Issues

A possible problem is that a client station (such as 192.168.10.200 in the network diagram) has a longer ARP timeout than the CSM. In this case, the ARP entry for this host would expire sooner on the CSM than on the client station. After this, the CSM does not accept any additional packets from this client station. The same can happen if the packets arrive through a router not known to the CSM, as the CSM may not have its ARP entry for the same reason. A solution to this is to configure these stations under a dummy serverfarm.

Dummy Serverfarms

A dummy serverfarm is simply a serverfarm with hosts (these can be client stations or network devices such as routers) defined in it which may send traffic to the CSM.

As the devices in a dummy serverfarm are considered to be real servers by CSM, the CSM makes ARP requests to those devices, and also refreshes its ARP entries for when they expire. This should eliminate the timeout issues.

A dummyserverfarm also ensure that packets sourced or forwarded by these devices are not dropped for coming from an unknown source MAC address.

Note: It is not necessary to associate a dummy serverfarm with any vserver.

Configuring a Dummy Serverfarm

Complete these steps:

  1. Create a dummy serverfarm.

    cat6000(config-module-csm)#serverfarm myDummy
    
  2. Add the devices which the CSM is to consider as real servers for ARP purposes to this serverfarm, such as directly-connected client stations or routers not configured as gateways on the CSM.

    cat6000(config-slb-sfarm)#real 192.168.10.200
    cat6000(config-slb-real)#inservice
    

Related Information

Updated: Mar 16, 2006
Document ID: 63158