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.
How to configure / enable the l2tp reassembly ?
In the config mode, this gets executed as a subcommand for vpdn
Configure
vpdn
l2tp reassembly
!
end
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>”
-------------------------------
frag_reassembly
Flow: Packets in: 8507 <---- Packets received for reassembly
Flow: Packets out (reinjected): 4003
Flow: Packets out (punted): 257
-------------------------------
or
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>
<snip>
-------------------------------
frag_reassembly
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/spp_frag.so': libspp_frag_pd.so: cannot open shared object file: No such file or directory
Or
spp/errors 0/2/CPU0 1# t4152862400 Node 'frag_reassembly' disposition 1 ('reinject') not found, using 'drop' instead
Or
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