Avocent ACS – Forcing MTU and MSS per Route

The Situation

A WAN link did not offer the full Ethernet MTU of 1500 bytes (tunnel/overlay overhead). Two effects came together:

• The WAN environment did not advertise the lower MTU properly – ICMP “Fragmentation Needed” (type 3, code 4) never made it back to the sender, so Path MTU Discovery had nothing to work with.
• Fragments were partly routed over a different path and arrived incomplete or not at all.

What it looks like: ping and SSH login work fine, but the session freezes as soon as any real amount of data flows – a directory listing, a file transfer, a config dump. The classic MTU blackhole: small packets get through, large ones disappear silently.

The Fix

Since the path does not signal the MTU correctly, it is pinned locally on the Avocent, per route. Static routes live in /etc/network/st_routes and use plain ip route syntax:

vi /etc/network/st_routes

10.0.0.0/8 via 10.52.192.81 dev eth0 mtu lock 1150 advmss 1100
default metric 0 via 10.52.192.81

This is not possible via the CLI or the web interface on the Avocents – those only expose destination, gateway, interface and metric. The file has to be edited directly.

To test the same route at runtime, without a reload:

ip route replace 10.0.0.0/8 via 10.52.192.81 dev eth0 mtu lock 1150 advmss 1100

What the Parameters Do

Strictly, advmss would be MTU − 40 (20 bytes IPv4 header + 20 bytes TCP header), so 1110 here. The 1100 are deliberately conservative and leave room for TCP options and additional overhead along the way.

Note that advmss only affects TCP, and only connections the device itself opens or terminates. Everything else is covered by the mtu value.

Verification

# Show the route including its metrics
ip route show
ip route get 10.1.2.3
# Find the largest packet that gets through (payload + 28 bytes = total size)
ping -M do -s 1122 10.1.2.3      # equals 1150 bytes
ping -M do -s 1123 10.1.2.3      # must fail
# Probe the path MTU step by step
tracepath 10.1.2.3
# Check the negotiated MSS in the SYN
tcpdump -ni eth0 'tcp[tcpflags] & tcp-syn != 0'

Pitfalls

• Configuration changes overwrite the file. If a static route is touched later through the CLI or the web interface, the Avocent rewrites st_routes and mtu and advmss are silently dropped. Check after every routing change and after every firmware update.
• The default route is untouched. In the example above the reduced MTU applies to 10.0.0.0/8 only. If other relevant traffic takes the default route, it needs the same values.
• Local traffic only. The setting applies to packets the device originates or forwards – not to end devices behind the Avocent.
• Back up the configuration before an update.

Where the Real Problem Sits

Touching the Avocent is a workaround for something that belongs in the WAN. The lasting fixes are:

• Stop filtering ICMP type 3 code 4 along the path so PMTUD works again.
• MSS clamping on the WAN router or tunnel endpoint (--clamp-mss-to-pmtu or a fixed value) – that solves it for every system behind the router at once.
• Check for asymmetric routing or ECMP sending fragments down a different path.

Until that happens, a fixed MTU per route on the Avocent is the pragmatic answer.