LTE modem where I can control the MTU
Hi, We have VZ wireless in the data center as a backup to our core infrastructure. We have an issue where if packets have a large MTU they seem to die. Does anyone know of a good 4G modem where I can set the MTU on the cellular connection? TIA. Dovid
On Fri, May 1, 2020 at 10:10 AM Dovid Bender <dovid@telecurve.com> wrote:
Hi,
We have VZ wireless in the data center as a backup to our core infrastructure. We have an issue where if packets have a large MTU they seem to die. Does anyone know of a good 4G modem where I can set the MTU on the cellular connection?
This (likely) isn't a function of the model, but rather whatever the modem connects to -- set the MTU of the interface that the modem connects to to be lower... W
TIA.
Dovid
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
We have VZ wireless in the data center as a backup to our core infrastructure. We have an issue where if packets have a large MTU they seem to die. Does anyone know of a good 4G modem where I can set the MTU on the cellular connection?
I suspect it's a bit more complex than just changing LTE MTU. The time when MTU matters in this situation (larger packets getting lost) is when DF bit is set on the packet - that's the case for all TCP data packets and it often crops up during TLS negotiations. Is that what you're seeing? Consider the following scenario: Your Server-------Switch-------LTE Router-------T'Internet-------Another Network-------Other Server If both "Your Server" and "Other Server" are connected to their relevant local networks at 1500 MTU then they will negotiate a TCP MSS slightly below 1500 bytes (probably 1460 bytes???) because they have no concept of the path MTU. If the MTU between LTE Router and the Internet is below 1500 then the LTE Router will drop larger packets because it's not allowed to fragment them. The solutions are: :: Have the LTE Router reduce the MSS of TCP negotiation packets as they flow through it. This is the approach normally taken by any cheap DSL router so I'd think your current LTE router should be able to do this also :: Have the LTE Router strip the DF bit from packets and fragment them anyway. I don't have any particular experience/opinions either way on this one so I'll leave it to others to comment/berate :: Implement path MTU discovery so your devices are aware of the path MTU and so set their MSS accordingly
I currently have an airlink that is connected directly to a raritan console server. The public IP sits on the raritan. The airlink does not seem to have any MTU options. Ideally I would change the MTU on the interface of the LTE modem wich would force the raritan to send all data < 1400 bytes per packet. I never thought about the reverse so we may need something that would tinker with the MSS as well. On Fri, May 1, 2020 at 11:01 AM Phil Lavin <phil.lavin@cloudcall.com> wrote:
We have VZ wireless in the data center as a backup to our core infrastructure. We have an issue where if packets have a large MTU they seem to die. Does anyone know of a good 4G modem where I can set the MTU on the cellular connection?
I suspect it's a bit more complex than just changing LTE MTU. The time when MTU matters in this situation (larger packets getting lost) is when DF bit is set on the packet - that's the case for all TCP data packets and it often crops up during TLS negotiations. Is that what you're seeing?
Consider the following scenario:
Your Server-------Switch-------LTE Router-------T'Internet-------Another Network-------Other Server
If both "Your Server" and "Other Server" are connected to their relevant local networks at 1500 MTU then they will negotiate a TCP MSS slightly below 1500 bytes (probably 1460 bytes???) because they have no concept of the path MTU. If the MTU between LTE Router and the Internet is below 1500 then the LTE Router will drop larger packets because it's not allowed to fragment them.
The solutions are:
:: Have the LTE Router reduce the MSS of TCP negotiation packets as they flow through it. This is the approach normally taken by any cheap DSL router so I'd think your current LTE router should be able to do this also :: Have the LTE Router strip the DF bit from packets and fragment them anyway. I don't have any particular experience/opinions either way on this one so I'll leave it to others to comment/berate :: Implement path MTU discovery so your devices are aware of the path MTU and so set their MSS accordingly
On Fri, May 01, 2020 at 11:56:57AM -0400, Dovid Bender wrote:
I currently have an airlink that is connected directly to a raritan console server. The public IP sits on the raritan. The airlink does not seem to have any MTU options. Ideally I would change the MTU on the interface of the LTE modem wich would force the raritan to send all data < 1400 bytes per packet. I never thought about the reverse so we may need something that would tinker with the MSS as well.
Not too familiar with airlink but it perhaps doesn't happen to have a (ALG)/Application Layer/Level Gateway in it does it ? If so I could reccomend attempting to turn it off. Ive seen this similiar sort of thing in other routing equipemnt that either didn't work at all or would bomb out on particular services. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
On Fri, 1 May 2020 at 19:00, Dovid Bender <dovid@telecurve.com> wrote:
I currently have an airlink that is connected directly to a raritan console server. The public IP sits on the raritan. The airlink does not seem to have any MTU options. Ideally I would change the MTU on the interface of the LTE modem wich would force the raritan to send all data < 1400 bytes per packet. I never thought about the reverse so we may need something that would tinker with the MSS as well.
Exactly my use-case with ISR4331 + async NIM + 4G NIM (1RU, single integrated power supply). Call home over 4G with unspecified WAN IP with IPSEC. interface Tunnel1 description OM: OOB IPsec DMVPN - local wire out-of-band ip address 100.100.1.18 255.255.255.0 no ip redirects no ip proxy-arp ip nhrp map 100.100.1.1 x.y.163.1 ip nhrp map 100.100.1.2 x.y.164.1 ip nhrp network-id 1 ip nhrp holdtime 300 ip nhrp nhs 100.100.1.1 ip nhrp nhs 100.100.1.2 ip route-cache same-interface ip tcp adjust-mss 1350 load-interval 30 keepalive 10 3 tunnel source Cellular0/2/0 tunnel mode gre multipoint tunnel key 1 tunnel protection ipsec profile OOB hold-queue 3584 in ! !interface Cellular0/2/0 description OM: WAN out-of-band - SINGTEL SIM X ip address negotiated no ip redirects no ip proxy-arp ip access-group FROM:INTERNET in load-interval 30 dialer in-band dialer idle-timeout 0 dialer watch-group 1 no ipv6 nd ra suppress hold-queue 3584 in ! controller Cellular 0/2/0 lte modem link-recovery rssi onset-threshold -110 lte modem link-recovery monitor-timer 20 lte modem link-recovery wait-timer 10 lte modem link-recovery debounce-count 6 -- ++ytti
participants (5)
-
Dovid Bender -
J. Hellenthal -
Phil Lavin -
Saku Ytti -
Warren Kumari