[j-nsp] MTU problems over VPLS

Huan Pham drie.huanpham at gmail.com
Wed Feb 13 23:50:21 EST 2013


Hi Luca,

I believe this is expected behaviour.
Your VPLS infrastructure only supports max MTU of 14xx (1500- MPLS/VPLS/TE etc overhead).

If your Layer 3 CPE device connected to the VPLS cloud sets default MTU of 1500 then it will try to send those 1500 byte packets, without knowing that they will get dropped by the first node in the VPLS cloud. Since this first VPLS device is not one of your layer 3 devices along your IP path, it can not send back an "ICMP Fragmentation Needed" message back to the source. It does not even care to do it either. Therefore MTU path discovery protocol breaks!!!

You can get MTU path discovery works by setting MTU on interfaces on any layer 3 CPEs facing VPLS to the actual MTU that the transport link between them can support ( in your case 1500- overheads for the interfaces facing VPLS cloud).

Alternatively, increase the MTU on physical interfaces in your VPLS infrastructure to catter for overheads you introduce.

Hope it helps. 

To Others, pls correct if my understanding is wrong.

Cheers,

Huan

On 13/02/2013, at 8:24 AM, <david.roy at orange.com> wrote:

> Which release do you use ? Experienced some mpls mtu issue on trio platform. Known PR... 
> 
> Envoyé de mon iPad
> 
> Le 12 févr. 2013 à 22:17, "Luca Salvatore" <Luca at ninefold.com> a écrit :
> 
>> I have a few sites connected via a VPLS core.  The core devices are all MX 10 routers connected via 10Gb fibre.
>> I'm having problems doing file copies (SCP between two Centos VMs).
>> 
>> The issue is that the file copy never gets anywhere, on the Centos CLI it sits at 0% then says 'stalled'
>> To fix this issue I have just set the MTU on the Centos machines to be 1400 - when this is in place the copy works and I get nice speeds.
>> 
>> I don't believe I should have to modify the MTU though, shouldn't path MTU discovery take care of this?
>> 
>> For example - I have done some TCPdumps, I can see the sender is sending traffic with the DF bit set, however I don't see any 'ICMP fragmentation needed' coming back from the MX saying the MTU is too big, I assume this should be the case.
>> 
>> I haven't modified any of the MTU's on the MX, everything is just the default.
>> 
>> I also have normal layer 3 running over the fibre between the routers and when I use that I don't see any issues, so it must be something to do with VPLS.
>> 
>> Any thoughts would be greatly appreciated.
>> 
>> Thanks
>> Luca.
>> 
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



More information about the juniper-nsp mailing list