Guest

Cisco CSS 11500 Series Content Services Switches

Understanding and Applying UDP, Content Rules, and Source Groups on the CSS 11000

Cisco - Understanding and Applying UDP, Content Rules, and Source Groups on the CSS 11000

Document ID: 45420

Updated: Jan 31, 2006

   Print

Introduction

User Datagram Protocol (UDP) traffic is uni-directional. The CSS sets up a Flow Control Block (FCB) in one direction, only when a UDP packet is processed. The FCB for the return path is only set up if the response packet arrives. Because of the uni-directional nature of UDP, source groups are often used on the CSS to provide the mapping between the two sides of the UDP flow.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

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

  • CSS 11000/11500

  • WebNS software

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Topics

UDP Content Rules

A UDP content rule is configured to provide load balancing among a group of servers. In this way, it is no different than needing to configure a TCP content rule. The content rule is to provide load balancing.

Configuration
*************************** GLOBAL **************************
  ip route 0.0.0.0 0.0.0.0 10.86.213.1 1
!************************* INTERFACE *************************
interface  2/1
  bridge vlan 10
!************************** CIRCUIT **************************
circuit VLAN1
  ip address 192.168.2.2 255.255.255.0
circuit VLAN10
 ip address 10.86.213.117 255.255.255.0
!************************** SERVICE **************************
service dns_s1
  ip address 192.168.2.3
  active
service dns_s2
  ip address 192.168.2.4
  active
!*************************** OWNER ***************************
owner UDP
  content dns
    port 53
    protocol udp
    add service dns_s1
    add service dns_s2
    vip address 10.86.213.124
	

The client hits the Virtual IP (VIP) address with a DNS request. The CSS load balances the DNS request between the active services on the rule. A FCB is set up for the client to VIP connection.

A UDP content rule must have a corresponding source group to handle the return UDP traffic. In the case of DNS, this is the DNS response to the initial DNS request. If you do not have a source group, the response back from the DNS server will not be NATed to the VIP address, and the DNS client will reject the request. This can be seen by issuing the show flows 0.0.0.0 command.

  CSS# show flows 0.0.0.0
  --------------- ----- --------------- ----- --------------- --- ------- ------
  Src Address SPort Dst Address DPort NAT Dst Address Prt In Port OutPort
  --------------- ----- --------------- ----- --------------- --- ------- ------
  161.44.67.245 2543 10.86.213.124 53 192.168.2.3 UDP 2/1 2/8
  192.168.2.3 53 161.44.67.245 2543 0.0.0.0 UDP 2/8 2/1

161.44.67.245 is the client, 10.86.213.124 is the VIP, and 192.168.2.3 is the server. Notice that the reply flow from the server does not have a NAT Dst Address.

Note: It should also be noted that a Layer 3 (L3) content rule works for UDP in the same manner described above. A L3 content rule does not have the protocol or port configured.

 content layer3
  vip address 10.86.213.124
  add service s1
  add service s2
  active

With this content rule, either UDP or TCP traffic can hit this VIP and load balance to a backend server.

UDP Source Groups in Conjunction with a Content Rule

A UDP source group is used to handle the UDP return traffic. In the example, this is a DNS response to the DNS request, which hit content rule dns. A customer can configure the group in three different ways in order to achieve NATing UDP return traffic.

  1. The backend servers from the content rule can be duplicated within the group. You would need to add a group to the above configuration.

    group dns
      vip address 10.86.213.124
      add service dns_s1 
      add service_dns_s2
      active

    With this configuration, the DNS response arrives from dns_s1 or dns_s2 , and the source group match is made. This causes the packet to be NATed to the VIP address configured on the rule. It is important to understand why the source port is not going to be NATed. Source groups will not NAT the source port if it is a well-known IP port, which are ports less than 1024.

    To recap, the DNS request hits the DNS content rule to be load balanced. In front of the CSS is 161.44.67.245:2586 -> VIP (10.86.213.124):53. Between the CSS and server is 161.44.67.245:2586 -> dns_s1 (192.168.2.3):53. The reply back from the server is Dns_s1(192.168.2.3):53 -> 161.44.67.245:2586. The DNS response matches the source group when it hits the CSS for VIP (10.86.213.124):53 -> 161.44.67.245:2586.

    The show flows command output:

      CSS(config)# show flows 0.0.0.0
      --------------- ----- --------------- ----- --------------- --- ------- ------
      Src Address SPort Dst Address DPort NAT Dst Address Prt InPort OutPort
      --------------- ----- --------------- ----- --------------- --- ------- ------
      192.168.2.3 53 161.44.67.245 2586 161.44.67.245 UDP 2/8 2/1
      161.44.67.245 2586 10.86.213.124 53 192.168.2.3 UDP 2/1 2/8

    Since the source port is less than 1024, and is a well-known port, the source port is not NATed, even though it hit a source group. Only the source IP address will be NATed back to the VIP address.

    For this type of configuration to work properly:

    • The VIP address on the content rule and the source group must be the same.

    • The source port on the response traffic must be well-known. For example Radius, which is port 1645. If the above example was a Radius authentication and response pair, the Radius response would have its source port NATed from 1645 to a source group port (for example, 8192). It is likely this would cause the Radius request to fail. This is the reason that the portmap disable command was added to the source group.

  2. The backend servers from the content rule can be duplicated within the group as destination services. The destination service allows for the source IP address as well as the source port to be NATed when the DNS request comes in from the client. The customer configuration is shown below.

    Configuration
    !*************************** GLOBAL ***************************
      ip route 0.0.0.0 0.0.0.0 10.86.213.1 1
    !************************* INTERFACE *************************
      interface 2/1
      bridge vlan 10
    !************************** CIRCUIT **************************
      circuit VLAN1
      ip address 192.168.2.2 255.255.255.0
      circuit VLAN10
      ip address 10.86.213.117 255.255.255.0
    !************************** SERVICE **************************
      service dns_s1
      ip address 192.168.2.3
      active
      service dns_s2
      ip address 192.168.2.4
      active
      !*************************** OWNER ***************************
      owner UDP
      content dns
      port 53
      protocol udp
      add service dns_s1
      add service dns_s2
      vip address 10.86.213.124
      active
    !*************************** GROUP ***************************
      group dns
      vip address 10.86.213.125
      add destination service dns_s1
      add destination service dns_s2
      active

    Note: For clarity, a different VIP address is put on the source group than on the content rule. The VIP address is 10.86.213.125. This is so that the source address that gets NATed between the CSS and the server is not the same as the VIP address.

    In this case, when the DNS request arrives from the client, both the content rule and source group match are made. The destination IP address will be NATed to the load balanced server. Because the source group was matched via the add destination, both the source IP address and source port will be NATed. In front of the CSS is 161.44.67.245:2644 -> VIP (10.86.213.124):53. Between the CSS and server is 10.86.213.125:8192-> dns_s1 (192.168.2.3):53.

    Since the source group match was made at the time of the DNS request the, portmap entry within the source group was created, and is matched by the DNS response back from the server. The reply back from the server will is Dns_s1(192.168.2.3):53 -> 10.86.213.125:8192.

    The source group port map entry handles NATing the source IP address and the client's original source port. The DNS response passed from the CSS to the client is VIP (10.86.213.124):53 -> 161.44.67.245:2644.

    The show flows command output:

      CSS(config)# show flows 0.0.0.0
      --------------- ----- --------------- ----- --------------- --- ------- ------
      Src Address SPort Dst Address DPort NAT Dst Address Prt InPort OutPort
      --------------- ----- --------------- ----- --------------- --- ------- ------
      192.168.2.3 53 10.86.213.125 8192 161.44.67.245 UDP 2/8 2/1
      161.44.67.245 2644 10.86.213.124 53 192.168.2.3 UDP 2/1 2/8

    With this configuration, the VIP on the content rule can match the source group VIP address but it does not have to. The well-known port (less than 1024) restriction still exists. The destination service configuration should not be used if the server needs to see the real IP address of the client.

  3. There can be no service defined on the group, and the group is preferred for a range of IP addresses via an ACL clause.

      Group dns
      Vip address 10.86.213.124
      active

    The ACL cause statement would look similar to:

    clause 10 permit udp any destination any sourcegroup dns

    Note: This is usually used when the customer does not want to NAT all traffic to or from a certain address. In this manner, they can control what traffic gets NATed.

UDP Source Groups for NAT Only

Another use of source groups with UDP traffic is to NAT traffic from the private IP address space behind the CSS to public IP addresses. In this case, no content rule is required because no load balancing is required. The UDP source group will be used to simply NAT the traffic. The backend services can be added with the private IP addresses, as shown in the example below.

  group dns_private
  vip address 10.86.213.124
  add service dns_s1
  add service_dns_s2
  active

Or, no services can be added to the group, and the source group can be preferred via an ACL clause.

  group dns_private
  vip address 10.86.213.124
  active

The DNS request comes in from the backend server and matches the source group. The FCB is created and the NAT transformation is done. The source group portmapper entry was internally created when the DNS response is received. On the return flow the source group lookup is done, the internal portmap entry retrieved, the FCB created, and the DNS response gets NATed back correctly.

No content rule is required because no load balancing is required. The source group handles the NAT transformation on the response back because it uses the portmapper information created on the request.

The well-known port restriction (less than 1024) is still adhered to. A well-known source port will not be NATed, but ports greater than or equal to 1024 will be NATed.

UDP Configuration Options

With releases 5.0, 7.10, and 7.20 the command parameter, dnsflow [enable|disable] is available. enable is the default, and means that the FCB is created for DNS flows. disable causes no FCB to be created though the content rule, and source group matching functions will be the same. With release 6.10, the noflow command functionality was extended via the configuration parameter.

flow-state [5060|161|162|53] udp [flow-disable|flow-enable][nat-disable|nat-enable]

The port numbers correspond to SIP(5060), SNMP(161), SNMP(162), and DNS(53).

The idea behind noflow was purely performance. A UDP response/request protocol such as DNS (SNMP and RADIUS are two other common ones) gains no benefit from the CSS function of mapping a FCB in the fastpath, and in fact, the overhead can slow down the performance of processing this type of traffic. In addition, since UDP traffic is uni-directional and has no terminator packet (such as the TCP RST or FIN), the UDP flow is only deleted via garbage collection, which adds more overhead. The implementation details of noflow, however, have effected the configuration requirements.

Releases 5.0 and 2G CSS 11500 releases only have the dnsflow disable command parameter at this time. Release 6.10 has the flow-state configuration table, which can do flow-disable for SNMP, SNMP traps, and DNS UDP flows.

The source group is not required for the examples in the UDP Source Groups in Conjunction with a Content Rule or UDP Source Groups for NATing Only sections of this document if the dnsflow disable or flow-disable commands have been issued. When the noflow command is issued, an internal source group is used to keep track of the no flow packets, and thus this internal portmapper entry, which is not associated with any configured source group, handles the return traffic.

This information is provided to be as detailed as possible. The BU, however, recommends that the source group be configured in the no flow cases. This is to be consistent between flow and noflow configurations, and also the source group allows the user to see hit counters, which the internal one does not.

Caveats

It is hard to document how UDP content rules and source groups are supposed to work because there are bugs that have caused odd and unexpected behavior, such as DDTS CSCec02038. This is specific to Release 6.10, only without a content rule and the configuration.

flow-state [161|162|53] udp flow-disable nat-enable

The return UDP request would fail, and the CSS would return an ICMP unreachable. There is a general problem with load balancing UDP traffic using the content rule configured in the UDP Source Groups in Conjunction with a Content Rule section of this document, if the UDP request uses the same source and destination port. This happens most often with Radius (source and destination port will be 1645). The CSS identifies the flow.

[ip source address|ip source port|ip dest address|ip dest port]

This is how the FCB and fastpath mappings are identified. When a client sends out UDP packets using the same source and destination port, they are only load balanced once, the first time, and then mapped in the fastpath. Unless the FCB gets garbage collected, which is at least 15 seconds for UDP, all future requests go to the same server.

Related Information

Updated: Jan 31, 2006
Document ID: 45420