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
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
Hey,
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?
Cisco ISR with NIM-4G-LTE-VZ
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.
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.
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