- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2015 03:33 AM - edited 03-05-2019 12:29 AM
Solved! Go to Solution.
- Labels:
-
Other Routers
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2015 11:16 AM
Hi Philip,
In your pseudowire-class L2TPVPN-PW, replace the ip local interface ATM0.1 line with ip local interface Dialer0 line. This line refers to the name of an interface whose IP address should be used as the source IP address of the L2TP session. The ATM0.1 interface is not an IP interface, however, as it does not have any IP address assigned. Instead, the PPPoE client is run over the ATM0.1 interface and this client provides its communication services to the Dialer0 interface. The Dialer0 interface is the actual interface that is assigned an IP address from your ISP, thanks to the ip address negotiated command. Therefore, the L2TP session should use the IP address of the Dialer0 interface.
Best regards,
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2015 02:52 PM
Hi Philip,
I am glad it worked!
Regarding the MTU, it is kind of complicated. Your basic connection type is PPPoE that incurs 8 bytes of overhead, causing the MTU of the DSL/PPPoE to be 1500-8=1492 bytes. However, the L2TP/PPP tunnel incurs another 20 (IP) + 8 (UDP) + 8 (L2TP) + 4 (PPP) = 40 bytes. The MTU therefore drops to 1492-40=1452 bytes.
I would need to know more about the way you have determined that the fragmentation occurs beyond 1460 bytes. The outputs do not provide any hints about the occurrence of fragmentation. You also have to be aware that this test is unable to detect whether the resulting L2TP+PPP-encapsulated packets get fragmented, as they are defragmented on the L2TP access concentrator.
It is, in general, suggested that in these scenarios with more complex tunneling and encapsulation, an MTU of 1400 and TCP MSS of 1360 bytes is used, to provide for a certain reserve in maximum packet sizes.
Therefore, what I suggest is this:
- On your Dialer0 interface, use ip mtu 1492 and ip tcp adjust-mss 1452 commands.
- On your Virtual-PPP1 interface, use ip mtu 1400 and ip tcp adjust-mss 1360 commands.
Best regards,
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2015 11:16 AM
Hi Philip,
In your pseudowire-class L2TPVPN-PW, replace the ip local interface ATM0.1 line with ip local interface Dialer0 line. This line refers to the name of an interface whose IP address should be used as the source IP address of the L2TP session. The ATM0.1 interface is not an IP interface, however, as it does not have any IP address assigned. Instead, the PPPoE client is run over the ATM0.1 interface and this client provides its communication services to the Dialer0 interface. The Dialer0 interface is the actual interface that is assigned an IP address from your ISP, thanks to the ip address negotiated command. Therefore, the L2TP session should use the IP address of the Dialer0 interface.
Best regards,
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2015 01:35 PM
Hi Peter,
Thanks for your reply. Your solution works 100%!!!
Another question, if I may
What should the correct MTU and MSS settings be for my connection type, in my routers configuration file?
This is what I tried with the following test. (Not sure if this is the correct approach).
I made sure that my PC (Win Xp) MTU is set to 1500. I also reconfigured all the routers MTU and MSS settings with the following command MTU:ip mtu 1500 , and MSS: ip tcp adjust-mss 1460.
I did a ping test from the Cisco console to a public Ip address with the following command:
ping 197.149.145.113 repeat 1 size 1500
,and from Windows command:
ping 197.149.145.113 -l 1500 -n 1
The highest I could go with the Cisco command without getting fragmentation is:
ping 197.149.145.113 repeat 1 size 1460
,and on Windows: ping 197.149.145.113 -l 1432 -n 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2015 02:52 PM
Hi Philip,
I am glad it worked!
Regarding the MTU, it is kind of complicated. Your basic connection type is PPPoE that incurs 8 bytes of overhead, causing the MTU of the DSL/PPPoE to be 1500-8=1492 bytes. However, the L2TP/PPP tunnel incurs another 20 (IP) + 8 (UDP) + 8 (L2TP) + 4 (PPP) = 40 bytes. The MTU therefore drops to 1492-40=1452 bytes.
I would need to know more about the way you have determined that the fragmentation occurs beyond 1460 bytes. The outputs do not provide any hints about the occurrence of fragmentation. You also have to be aware that this test is unable to detect whether the resulting L2TP+PPP-encapsulated packets get fragmented, as they are defragmented on the L2TP access concentrator.
It is, in general, suggested that in these scenarios with more complex tunneling and encapsulation, an MTU of 1400 and TCP MSS of 1360 bytes is used, to provide for a certain reserve in maximum packet sizes.
Therefore, what I suggest is this:
- On your Dialer0 interface, use ip mtu 1492 and ip tcp adjust-mss 1452 commands.
- On your Virtual-PPP1 interface, use ip mtu 1400 and ip tcp adjust-mss 1360 commands.
Best regards,
Peter
