Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

L2TP Reassembly troubleshooting Guide

L2TP Reassembly

This feature supported on asr9k deployed as LAC ( l2tp access concentrator). Only IPv4 fragmented packets will be reassembled.

This feature is by default disabled and all the fragmented packets are dropped.    

Screen Shot 2013-10-21 at 10.09.52 PM.png

How to configure / enable the l2tp reassembly ?

In the config mode, this gets executed as a subcommand for vpdn



l2tp reassembly



Will this feature work on NP3c based LC’s?

NP3C is not supported. Only NP4C based LC’s are supported.

Can it handle if i get fragmented packets from 2 line cards ?

No. Currently we don’t support fragmented packet arrives from 2 different LC’s. This is current limitation. if the 2nd fragment has the More Fragements(MF) bit set everything gets flushed.

What is the PPS supported ?

10K PPS per line card. 2K concurrent flows per LC.

How many fragments are supported ?

Up to 2 fragments are supported now. More than 2 fragments, it will be handled by RP.

Troubleshoot Fragmentation Reassembly

How do i check the packets arrived for reassembly?

run “show spp node-counter location <location of LC>”



Flow: Packets in:   8507   <---- Packets received for reassembly

Flow: Packets out (reinjected):   4003

Flow: Packets out (punted):     257



Run :

RP/0/RSP1/CPU0:GOT#show spp reasse statistics location 0/2/cpu0

Reassembled packets: 0

              L2TP: 0

Too many fragments: 0

Reassembly timeouts: 0

   Out of resources: 0

   Fragment errors: 0

If there are no counters shown for the frag_reassembly plugin, it means no packets are reaching or it isn't running.

How do i check the packets are reassembled ?

Now look at the "Flow: Packets out (reinjected)" counter. This should be increasing, to indicate that fragments are being successfully reassembled and reinjected into the hardware.

Flow: Packets out (reinjected):   9008 -> Packets reassembled and reinjected back.

What If i see a WARN counter keep getting incremented?

Please find the details of the WARN details.

Warn: Timed out (punted)

One   fragment has been received, but the other fragment has not been received within   the given window of approximately 2 seconds.

Warn: Timed out (dropped)

Same as   above, except that there was not enough room to punt the packet so it has   been dropped.

Warn: Packet has options

The   packet contains IP options fields. These packets cannot be reassembled by the   plugin.

Warn: No datagram space

There   are too many datagrams in flight. Currently, the maximum supported number of   datagrams in flight is 2048.

Warn: Max fragments exceeded

The   datagram has more than 2 fragments.

What if i see ERR counter keep getting incremented?

Err: Input interface not set

The 'input interface handle' context metadata has not been   set.

Err: VRF ID not set

The 'VRF ID' context metadata has not been set.

Err: Netwk start not set

The 'network start' context metadata has not been set by   hardware.

Err: Netwk start out of range

The 'network start' context metadata set by hardware is   outside the range of the packet data.

Err: Header too short

The length of the packet is shorter than the IPv4 header.

Err: Data too short

The length of the packet is shorter than the length given   in the IPv4 header.

Err: Not IPv4

The packet is not an IPv4 packet and shouldn't have been   sent.

What are various counter means ?

There are 4 counters Flow, Info,Warn and Err. As mentioned above the counters can be viewed by running show spp node-counter location <loc>. In the output look for section frag_reassembly.

RP/0/RSP1/CPU0:GOT #show spp node-cou loc <0/2/cpu0>




             Flow: Packets in:   8507

Flow: Packets out (reinjected):   4003

   Flow: Packets out (punted):     257

             Info: Reassembled:   4003

               Info: Retained:     504

     Warn: Timed out (punted):     257

     Warn: Timed out (dropped):     244

The "Flow" counters give a high-level view of the packets going in and out of the plugin. Note that in general the number of packets leaving the plugin will be less than the number of packets going in, because the plugin reassembles multiple packets into one.

The "Info" counters indicate informational conditions that happen as part of the plugin's normal operation. For example, packets which have been reassembled or fragments which have been retained pending another fragment.

The "Warn" (warning) counters indicate fragments which couldn't be reassembled, due to conditions that are expected (such as fragments timing out, or running out of space). These packets are punted to the RP.

The "Err" (error) counters indicate fragments which couldn't be reassembled due to problems with the code or a seriously malformed packet -- these errors should never occur. These packets are punted to the RP.

When should you contact deployment team ?

If you see the reassembly is not running by hit with any one of the following condition.

RP/0/RSP1/CPU0:GOT #show spp trace errors loc 0/2/cpu0

Oct 17 08:46:01.550 spp/errors 0/1/CPU0 1# t4152862400 Failed to load plug-in '/pkg/lib/': cannot open shared object file: No such file or directory


spp/errors 0/2/CPU0 1# t4152862400 Node 'frag_reassembly' disposition 1 ('reinject') not found, using 'drop' instead


If you don’t find the following entry

RP/0/RSP1/CPU0:GOT#show spp graph location 0/2/cpu0 ( Check for section frag_reaseembly)

[4] frag_reassembly:

     ->[2] reinject   <--- Number of entries and the names and numbers

     ->[3] rp_punt  

The contact the deployment team for help with the following info.

  • •1.   Full configuration
  • •2.   Short note on topology
  • •3.   Show platform
  • •4.   Show install active summary
  • •5.   Show spp node-co loc <loc>
  • •6.   Complete console logs
  • •7.   Show spp trace errors
  • •8.     Show tech-support spp