Introduction
Layer 2 VPN is being used by many service providers. L2tpv3 is used to provide layer 2 services to the customer over IP/MPLS cloud. In this document, MTU issue has been simulated with its workaround.
How To Check The Status Of Circuit
R1#show l2tun session
L2TP Session Information Total tunnels 1 sessions 1
LocID RemID TunID Username, Intf/ State Last Chg Uniq ID
Vcid, Circuit
50413 45422 23086 20, Fa0/0 est 00:00:46 4
R2#show l2tun session
L2TP Session Information Total tunnels 1 sessions 1
LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit
45423 50414 17633 20, Fa0/0 est 00:00:01 4
Check The Encapsulation Type
L2TP Session Information Total tunnels 1 sessions 1
Session id 20044 is up, tunnel id 59245
Remote session id is 50078, remote tunnel id 25237
Locally initiated session
Call serial number is 4048300002
Remote tunnel name is R2
Internet address is 20.20.20.20
Local tunnel name is R1
Internet address is 10.10.10.10
IP protocol 115
Session is L2TP signaled
Session state is established, time since change 00:00:10
DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
UDP checksums are disabled
FS cached header information:
encap size = 24 bytes
45000014 00000000 FF737F3B 0A0A0A0A
14141414 0000C39E
1 Packets sent, 1 received
60 Bytes sent, 60 received
Encapsulation Type 24 means 20 bytes of IP Header and 4 Bytes of L2tpv3.
Initiate a Ping request of 1500 bytes with df-bit from R0 which is CPE. Before starting a ping check the two given outputs on R2 router.
R2#show interfaces fastEthernet 0/0 switching
FastEthernet0/0
Protocol Other
Switching path Pkts In Chars In Pkts Out Chars Out
Process 0 0 0 40878
Cache misses 0 - - -
Fast 170 52853 158 15680
Auton/SSE 0 0 0 0
R2#sh ip traffic | i fra
0 fragmented, 0 fragments, 0 couldn't fragment
Start the ping from R0 router
R0#ping 192.168.1.3 df-bit size 1500 repeat 10
Now check the outputs again
Show interfaces fa0/0 switching
Protocol Other
Switching path Pkts In Chars In Pkts Out Chars Out
Process 0 0 27 40878
Cache misses 0 - - -
Fast 197 52853 158 15680
Auton/SSE 0 0 0 0
R2#sh ip traffic | i fra
27 fragmented, 54 fragments, 0 couldn't fragment
Nice findings come here. You can R0 is sending packets with DF bit sent and when the packet comes at R1 interface it encapsulate the packet with l2tpv3 but the packet size becomes more than 1500 so the l2tpv3 packet fragments on R1 and sent over l2tpv3 to R2. At R2 again reassemble of fragment packet occurs which can be seen from the above output. Total 27 packets has been sent from R0 but due to fragmentation each packet is divided into two parts and reassemble at R2. This is reason we are getting 54 fragments which is double the sent packets. The main disadvantage of using this is that every time PE tail end router has to reassemble the packet consequence lot of CPU is required. From the “Show interfaces fa0/0 switching”, it is cleared that the packets received as fast switched and processed as process switch.
Solution Of The Problem
The problem can be overcome by using PMTU which is path MTU discovery. Now add ip pmtu command under pseudowire and initiate a ping request from R0 router.
R0#ping
Protocol [ip]:
Target IP address: 192.168.1.3
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.1.1
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: V
Loose, Strict, Record, Timestamp, Verbose[V]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1450
Sweep max size [18024]: 1470
Sweep interval [1]:
Type escape sequence to abort.
Sending 105, [1450..1470]-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
Packet sent with the DF bit set
Reply to request 0 (564 ms) (size 1450)
Reply to request 1 (564 ms) (size 1451)
Reply to request 2 (552 ms) (size 1452)
Reply to request 3 (564 ms) (size 1453)
Reply to request 4 (564 ms) (size 1454)
Reply to request 5 (344 ms) (size 1455)
Reply to request 6 (564 ms) (size 1455)
Reply to request 7 (392 ms) (size 1457)
Reply to request 8 (756 ms) (size 1458)
Reply to request 9 (708 ms) (size 1459)
Reply to request 10 (564 ms) (size 1460)
Reply to request 11 (320 ms) (size 1461)
Reply to request 0 (564 ms) (size 1462)
Unreachable from 192.168.1.3, maximum MTU 1462 (size 1463)
Request 13 timed out (size 1464)
From the above output the packets are being dropped after packet size 1462 and a message is appearing that maximum MTU is 1462.
How MTU becomes 1462? Here is the calculation for MTU
20 Bytes IP Header + 4 Bytes L2tpv3 + 14 Bytes Ethernet = 38 Bytes
1500 Bytes – 38 Bytes = 1462 Bytes
This is in case of Ethernet without dot1q, If dot1q is enabled then we need to add 4 bytes more in this consequence MTU will be reduced to 1458.
Click Here To Download Full Article
regards
shivlu jain
Friday, May 1, 2009
MTU Problem In L2TPV3
Subscribe to:
Post Comments (Atom)
4 comments:
Hi,
first of all, You have a pretty nice blog ;)
Your MTU calculation formula does have an error though - Ethernet header is 18bytes not 14. Which ends up with 1504 bytes. This large packet should be fragmented but it is not. It is the same like when You have a subinterface on port whichs MTU is 1500, You can still get through that port an 1500byte packet without fragmentation. Cisco does not take into account those 4 extra bytes (vlan tag). I think with L2TPv3 is something similar going on, otherwise it just does not go together with the theory.
Hi,
Can you let me know in which series router and IOS did you tried this and router is doing fragmentation and assembly. I have some l2tpv3 x-connects with 1841 and 7200 routers but could not resolve the mtu issue. What I can understand reading this post is R2 and R3 is transparently doing the large packet fragmentation and assemply in-spite of R0 or R4 is sending the pacets with DF bit set. Therefore in L2 circuits the CE router doesn't have to do anything.
But this is not working..in my scenario the packets are simply not passing because fragmentation is not happening.
For this you have to use ip pmtu in xconnect at PE. After adding the command the PE will stop fragmentation. I have tested in 12.4 11 T4 in 7200.
Thanks for the reply, it seems you have understood my post other way round.
I need my routers to do fragment the large packets, which is not happening at the moment.
Post a Comment