Balancing Tunneled Traffic Based on Client IP Addresses

Load Distribution

Platform
Intel® PAC
Napatech SmartNIC
Content Type
User Guide
Capture Software Version
Link™ Capture Software 12.8

Distributing tunneled traffic for different IP addresses between streams

Traffic to and from different client IP addresses inside a tunnel can be distributed between streams based on an inner tunnel hash key, so that traffic to and from one client goes to one stream and traffic to and from another client goes to another stream (or to the same stream).

Tunneled traffic monitoring over network TAP

In a mobile network, tunneled traffic can be monitored over network tap as shown in this figure.


Assume a client has an IP address 192.168.0.1 and it connects to remote IP addresses Y and Z. All the traffic from/to IP address 192.168.0.1 should end up in the same stream regardless of the destination IP address Y and Z. Also assume that all uplink traffic is on port 0, all downlink traffic is on port 1 and all tunneled traffic is IPv4. The idea is to generate a hash value from a key that only contains the client IP address. In uplink traffic coming from port 0, the address will be the source address, and in downlink traffic from port 1, the address will be the destination. This can be expressed in the following NTPL commands:

Define HashUp = Hash(HashWord0_3=InnerLayer3Header[12]/32)
Define HashDown = Hash(HashWord0_3=InnerLayer3Header[16]/32)
Define FilterUp = Filter(Port==0 AND InnerLayer3Protocol==IPV4)
Define FilterDown = Filter(Port==1 AND InnerLayer3Protocol==IPV4)

Assign[StreamId=(0..3); Hash = HashUp] = FilterUp
Assign[StreamId=(0..3); Hash = HashDown] = FilterDown

Tunneled traffic monitoring over SPAN port

This figure shows an example of the tunneled traffic monitoring over span port.


Consider the case where similar functionality is wanted, but instead of having one port for uplink and one for downlink, the connection is a SPAN/mirror port. In this case the IP addresses of the possible gateways in and out of our network (SGSN and GGSN) must be known in order to be able to figure out if a packet is uplink or downlink. The uplink traffic has SGSN as source address or GGSN as destination address. The downlink traffic has SGSN as destination address or GGSN as source address. The up/down filters can in this case be defined like this:

Define SGSN = Macro("3")
Define GGSN = Macro("4")
Define IPv4SrcField = Field(Layer3Header[12]/32)
Define IPv4DstField = Field(Layer3Header[16]/32)
Define HashUp = Hash(HashWord0_3=InnerLayer3Header[12]/32)
Define HashDown = Hash(HashWord0_3=InnerLayer3Header[16]/32)

KeyType[Name=kt_IPv4; Access=Full] = {32}
KeyDef[Name=IPv4Src; KeyType=kt_IPv4] = (IPv4SrcField)
KeyDef[Name=IPv4Dst; KeyType=kt_IPv4] = (IPv4DstField)
KeyList[KeySet = SGSN; KeyType = kt_IPv4] = ([10.10.10.1])
KeyList[KeySet = GGSN; KeyType = kt_IPv4] = ([172.20.20.1])

Assign[StreamId=(0..3); Hash= HashUp] = Key(IPv4Src) == SGSN OR Key(IPv4Dst) == GGSN
Assign[StreamId=(0..3); Hash= HashDown] = Key(IPv4Src) == GGSN OR Key(IPv4Dst) == SGSN
Note: This example does not apply to NT200A01 running on the 2 × 100 Gbit/s capture/replay image.