NetShark : How to use NetShark Cisco LISP Decoding Feature ?

How to use NetShark's Cisco LISP Decoding feature introduced in 10.9 release ?

NetShark release 10.9 supports Cisco LISP decoding. The Cisco LISP (Locator/ID Separation Protocol) uses Routing Locators (RLOCs) and Endpoint Identifiers (EIDs) to route traffic through a network. A network node has one EID but may have multiple and variable RLOCs. Before a packet is sent over the network, an Ingress Tunnel Router (ITR) uses a LISP-supplied mapping service to add an IP header to the packet containing the necessary RLOC (the outer IP header). Once the packet reaches the specified RLOC destination, an Egress Tunnel Router (ETR) strips off the outer IP header and forwards the packet to its destination (the inner, host-supplied IP header). Using RLOCs and EIDs with LISP-enabled edge routers enables a node to maintain a single IP address even when its location changes.

While LISP tunnels aid the routing of packets through a network, packets captured between the ITR and the ETR have an outer IP header that prevents the analysis of the host-supplied EID in the inner IP header. Starting with version 10.9, NetShark Cisco LISP decoding strips the outer IP header from LISP data packets to provide access to the inner IP header for traffic analysis.

NetShark Cisco LISP decoding strips the outer IP header from LISP data packets only. LISP control packets are not decoded. The outer IP header of LISP control packets is not stripped and the LISP header is not analyzed. LISP control packets are treated the same as any other generic packet by NetShark.

A LISP data packet is identified using the following criteria:

Outer IP header

• IPv4 Packets

             Protocol = 17

• IPv6:

             Next Header = 1

UDP header

• Destination port = 4341
• UDP checksum = 0

LISP control packets are identified using the following criteria:

• UDP port = 4342
• UDP checksum = 0

The following inner and outer IP header formats are supported:

• IPv4-in-IPv4
• IPv4-in-IPv6
• IPv6-in-IPv6
• IPv6-in-IPv4

On the NetShark Web interface Configuration > Advanced Settings page the parameter packet_parser.skip_lisp_header=False controls whether the outer LISP header is stripped or not stripped. NetShark Cisco LISP decoding is off by default.

If analyzing local traffic, packet_parser.skip_lisp_header must be set in Packet Analyzer. Edit the value found in the following file:

\Users\<user>\AppData\Roaming\Riverbed\SteelCentral Packet Analyzer\<version>\server\configuration\Pilot.Server.conf

The table below summarizes the results of this parameter’s settings on LISP data packets.

Packet Analyzer Processing

When LISP decoding is enabled (True) all packet processing features (for example storage, capture, microflow indexing, export to NetProfiler or NetFlow v9, send to Wireshark and so forth) work as usual with the decoded LISP-data packets.

Note: All fields in the inner IP header are used “as is” with no preprocessing. The following fields may not present accurate information about the packet:

• TTL (Time to Live)
• TOS (Type of Service)

There are no new views or filters intrdocued in 10.9 for LISP packets.

Troubleshooting

If LISP traffic is not processed properly, please open a TAC case and provide a capture file with a few packets.

NetShark