Another MTU - Question

[Schnapsbrenner_Jedi_83]

Good morning Community,

just quick question that is really a pain in the arse for me as I can't explain the behaivior of the cisco and the attached devices.

As you can see in the attachment I have a setup that contains basically two VPN Tunnels. As I'm only admin of the two parts of the network (yes the WAN Router is not in my are of responsibility) I want to to verify that my site is green.

To the specs:

R3 und RS3 are VPN-Devices (not Cisco) 

R2 is a Cisco Layer 3 Switch which terminates multiple VLANs and send all packages to

R1 (also a Cisco Router)

From the beginning we had an IP MTU 1350 on the WAN-Link from R2 to R1 and our VPN devices worked as they should.

From one day to another (no changes were made) we started to experience packet loss in the networks behind R3 to RS3 who ended in deny of some services.

When we put an IP MTU of 1349 on the R2 Interface VLAN that connects the VPN device. All tunnels work fine. When we start increase the MTU size to 1350 which is the same like on the WAN site our services start to fail again and we see packet loss.

When we start playing with the WAN MTU (R2 to R1) size we also end in a 1 byte smaller IP MTU on the interface VLAN pointing to the VPN Device. If we take IP MTU of the VLAN Interface our services start going down again. 

We already restarted the VPN Devices a couple of times. The VPN Device sends packets without the fragmantation bit set. Unfortunately we can't change configs on the VPN devices as they are managed by a different organisation. According to them nothing changed and we are the only customers having this issue.

My question:

Why we are always ending in a 1 byte smaller IP MTU?

Kind regards

Hannes

[Georg Pauwen]

Hello,

--> R3 und RS3 are VPN-Devices (not Cisco)

What vendor/models are these devices ? I suspect this is a multi-vendor interoperability problem, which is quite common actually. The MTU sizes you specify are rather unusual. 

On Cisco devices, there is a command 'ip tcp path-mtu-discovery', possibly the other vendor devices have something similar...

[Schnapsbrenner_Jedi_83]

Good morning Gerog,

thanks for the quick reply. 

We are talking about Secunet devices which are not using any MTU Path detection according to the sysadmin. They have a fixed MTU size (Interface) of 1350. 

[Georg Pauwen]

Hello,

are you using any of the SINA L3 boxes ? Either way, I would check with Secunet if they use some sort of VPN fingerprinting. If you yourself are behind the VPN, you can use a site like ipleak.com (click on 'Full Report' at the bottom) and check if the section 'Privacy - Gateway detection & fingerprints' tells you anything.

[Schnapsbrenner_Jedi_83]

Yes it is an L3 Box.

I'll have a look what ipleak says. Thanks a lot Georg.

[Schnapsbrenner_Jedi_83]

Just a quick question. 

Where is the difference between ip mtu cmd on WAN int and on LAN int?

[Georg Pauwen]

Hello,

any progress on the 'issue' ?

There is no difference between the 'ip mtu' command on LAN or WAN interfaces. Typically, there is no need to change the MTU on the LAN, as only WAN technologies (such as MPLS, VPN. etc.) may require a change in MTU size. In your case of course that is an exception...

[Schnapsbrenner_Jedi_83]

Actually no. It seems to be the third party units that are causing the trouble but I can't understand why I have to put the ip mtu cmd on that vlan with an MTU size that is 1 byte smaller than on the WAN interface. Without the ip mtu cmd on that vlan interface I have these packet losses behind the VPN Tunnel.

Its really strange and a pain in the arse  

[Georg Pauwen]

Hello,

did you talk to Secunet ? Either way, maybe you can put a sniffer (e.g. Wireshark) on your network and see if that reveals anything. That -1 byte must come from somewhere...