Routing
Highlighted
Routing

SSH login fails due to MTU mismatch ?

‎06-29-2020 06:22 AM

Hi All,

We have run in to situtaion that turns out to be MTU issue finaly. just wanted some clarification why.

we have such setup:

MX (mtu 9100)......... (default 1514) SW1(9100).........(mtu 9100)SW2 

 

SW1 is newly introduced switch and after insertion, SSH from the MX to any of the swithces fails but ping works. interface at the MX side is in routing-instance VRF. so ping with 1472 payload and -df set was working well but SSH fails. SSH to the same swtiches from other devices behind the MX works!. we fixed the MTU to 9100 everywhere and SSH from the MX to the SWs works. was just curious, why does SSH fail even though 1472 payload goes through without fragmentation.

its only SSH originating from the MX to any of the switches that fails. 

 

Thank you!!

 

4 REPLIES 4
Highlighted
Routing

Re: SSH login fails due to MTU mismatch ?

‎06-29-2020 07:53 AM

Hi Ahmed,

 

The primary reason is : "The SSH response packets have the DF bit set by default ;So SW1 might be dropping the packets on the interface conneting to MX. " 

 

It is always recommended to have the same MTU on both ends of point to point link.  So if you match MUT between MX and SW1 either by reducing the MX MTU or by increasing the SW1 MTU you should not see the problem. 

 

This seems to be a expected behaviour !!

 

 

Hope this helps !!

 Please accept this as a solution if it answers your question so others can benefit from your post.

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !

+++++++++++++++++++++++++++++++++++++++++++++

 

Regards

Arpit 

Highlighted
Routing

Re: SSH login fails due to MTU mismatch ?

‎06-29-2020 08:25 AM

Hi! 

 

My understanding is, fragmentation happens on egress, not ingress. When MX and SW negociate the TCP MSS, it will be a higher value compare to the MX facing interface of SW1. Hence SSH packet will be dropped on the ingress of SW1 when initiating SSH from MX side. if you change the MTU of SW2 facing interface to 1514 and change the MTU of MX facing interface to 9100, I believe you will see SSH failure when initiate from SW2. 

 

As mentioned by Arpit, we already recommand the same MTU value along the path.

 

Best

 

Mu

Highlighted
Routing

Re: SSH login fails due to MTU mismatch ?

‎06-29-2020 10:52 AM

Hi Mu,

 

Do you mean that when MX and SW2 agree on MSS it will result in packets with MTU higher than SW1 ingress interface ? shouldn't be a path MTU discovery in place here ? 

 

 

Regards,
A.A.
Highlighted
Routing

Re: SSH login fails due to MTU mismatch ?

‎06-29-2020 01:27 PM

Hi there

 

I did a quick lab test with my existing topology, and it works fine for me when I setup the MTU as your case.  I further checked and the the TCP path mtu discovery should be enabled by default. 

 

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/tcp-outgoing-connections...

 

Are you using all Juniper devices? and what is the version for the Junos code? It might be helpful to share these information. 

 

Here is the output from my lab:

 

R1 ae1 ----ae1 R2 ae0 ----ae0 R3

 

R1:

 

labroot@r1> show configuration interfaces lo0
unit 0 {
family inet {
address 10.1.1.1/32;
}
family mpls;
}

 

labroot@r1> show configuration interfaces ae1
mtu 9800;
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family inet {

address 10.1.4.1/29;
}
family mpls {
maximum-labels 5;
}
}

 

labroot@r1> show route 10.1.1.5

inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.1.5/32 *[Static/5] 00:20:31
> to 10.1.4.4 via ae1.0

 

 

r2:

 

labroot@r2# show interfaces ae1
mtu 1514;
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family inet {
address 10.1.4.4/29;
}
family mpls {
maximum-labels 5;
}
}

 

 

labroot@r2# show interfaces ae0
mtu 9100;
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family inet {
address 10.4.5.4/29;
}
family mpls {
maximum-labels 5;
}
}

 

R3:

 

labroot@r3# show interfaces lo0
unit 0 {
family inet {
address 10.1.1.5/32;
}
family mpls;
}

 

labroot@r3# show interfaces ae0
mtu 9100;
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family inet {
address 10.4.5.5/29;
}
family mpls {
maximum-labels 5;
}
}

 

SSH are working for both side:

 

r1 to r3:

 

labroot@r1> ssh labroot@10.1.1.5
Password:
Password:
Last login: Mon Jun 29 13:05:35 2020 from 10.1.1.5
--- JUNOS 19.3R1-S1 Kernel 64-bit JNPR-11.0-20190701.269d466_buil
labroot@r3>

 

r3 to r1:

 

labroot@r3# run ssh labroot@10.1.1.1
Password:
Last login: Mon Jun 29 13:09:55 2020 from 10.107.42.95
--- JUNOS 18.4R3.3 Kernel 64-bit JNPR-11.0-20191211.fa5e90e_buil
labroot@r1>

 

Best

 

Mu

Feedback