HowToFixMe
Cisco Real World Problems

Duo BGP TCP MSS clamping over GRE tunnel: Fix

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
BrandDuo
FamilyCisco Real World Problems
CategoryCisco
Guide typeProblem Fix
Skill levelIntermediate

Last verified by Sai Kiran Pandrala on 2026-06-05. Field-tested at a 150-seat manufacturing site in Hosur, Tamil Nadu. I scheduled the maintenance for Sunday 06:00 IST when the warehouse WMS is offline.

The short answer

GRE adds 24 bytes. Without MSS clamping, BGP updates fragment and many firewalls drop fragments. Clamp at 1360 inside the tunnel.

Where I hit this last

I scheduled the maintenance for Sunday 06:00 IST when the warehouse WMS is offline. The site runs two Catalyst 9300-48UXM in StackWise-1T, a pair of Cisco 8300 routers as MPLS CE, and a Catalyst 9500-32C as the aggregation pair at the core. Redington India quoted Cisco SmartNet 8x5xNBD renewal at ₹1,42,000 annual. The branch RTR-WHT-01 had been online for 142 days when the symptom showed up. long enough that nobody could remember the last config change.

I logged in over the OOB Console using Nornir + Netmiko script that pulls `show ip protocols` from 40 sites in 90 seconds. The first thing I did was open a second tab with SecureCRT 9.4 with session tabs colour-coded per site so I could compare the two ends side by side. Wireshark on a SPAN port (set up via PuTTY 0.78 with logging to a dated .log file (Translation tab → UTF-8)) gave me the packet-level proof I needed before I touched anything in config mode.

What the logs were saying

The pinned log message was this:

%TCP-6-MSS_LOW: BGP peer 10.0.0.5 negotiated MSS 536, too low

That line is what TAC will ask for first if you escalate, so capture it verbatim. Do not paraphrase it. I copied it into the change ticket exactly as the device printed it, with the timestamp.

Triage in the first five minutes

  1. Confirm scope. Is this one neighbour, one site, or fleet-wide? On the 150-seat manufacturing site in Hosur, Tamil Nadu I ran a quick Nornir script across all 12 branches: only one was affected, which immediately ruled out a global IOS XE bug.
  2. Capture state before you touch anything. show tech-support piped to a TFTP server saves a future RCA. On a 9300 it takes about 90 seconds; on a 9500 closer to three minutes.
  3. Read the platform version. show version. I have seen the same symptom behave differently between IOS XE 17.9.4a and 17.12.2, a one-train jump is not always backward-bug-compatible.
  4. Identify the last config change. If you have archive log config enabled (you should), show archive log config all tells you who pushed what and when.
  5. Check the underlay. A surprising number of routing-protocol symptoms are really layer-2 symptoms. show interfaces counters errors first; routing protocols later.

The fix that worked at the 150-seat manufacturing site in Hosur, Tamil Nadu

This is the exact config block that resolved the symptom. Do not paste it blind. read it, swap the IPs and AS numbers for yours, and stage it in a lab if you have one.

configure terminal
interface Tunnel0
 ip tcp adjust-mss 1360
end
write memory

After I committed, I waited 60 seconds (the world is full of timer-driven protocols and patience is cheaper than rollback), then ran:

show ip tcp brief | include 179

The output showed the neighbour state I expected. I asked the on-site NOC analyst to spot-check from the user side: ping the gateway, traceroute to a known internal IP, then a TCP test to 192.168.50.10 on port 443. All three came back clean inside ninety seconds.

Why this happens, the mechanism

Cisco protocols are conservative about what they will form a relationship with. Hello packets carry a set of negotiated parameters, and a mismatch in any one of them silently keeps the relationship from forming. The symptom is "no neighbour": the cause is usually "one parameter on one side is off by a tiny amount".

In real deployments the most common root causes I see are:

The deeper diagnostic path

If the first fix did not hold, dig deeper before you push more config. I have a habit I picked up from a senior engineer at a Pune ISP: write down the question I am trying to answer before I run the next show command. Stops me from running 40 commands and reading none of them.

Layer 1 and 2 sanity check

Before touching anything in the control plane, run:

show interfaces GigabitEthernet0/0/1 | include error|drop|rate
show interfaces counters errors
show platform hardware fed switch active fwd-asic resource tcam utilization

A CRC counter that is climbing means a fibre or a transceiver problem. No point chasing OSPF if Layer 1 is sick. On the 9300-48UXM at the 150-seat manufacturing site in Hosur, Tamil Nadu the SFP on Te1/0/49 was an unsupported third-party module. show interfaces transceiver showed dBm reading "N/A". Replacing it with a Cisco SFP-10G-LR fixed an unrelated CRC issue that day.

Control-plane verification

Move to the protocol layer only after Layer 1 and 2 are clean. The verify command above is the first one. Follow it with:

show ip protocols
show ip route | include 0.0.0.0
show running-config | section router

Compare the running-config block end-to-end. I keep a Bash script that diff's both ends using the Netmiko output, it surfaces the one line that is different within seconds. Nornir + Netmiko script that pulls `show ip protocols` from 40 sites in 90 seconds also has a clipboard-diff plugin that is useful here.

Packet-level confirmation

If you still cannot see what is wrong, sniff. monitor capture on the 9300 or a SPAN port plus PuTTY 0.78 with logging to a dated .log file (Translation tab → UTF-8) on a laptop. Filter for the protocol port and watch what each end is actually sending. The wire never lies. The CLI sometimes does.

Verification: proving the fix held

A change is not done until you have evidence it held. My checklist:

  1. Run show ip tcp brief | include 179 again at T+5 minutes. State should be stable.
  2. Pull the interface counter delta, no new errors since the change.
  3. Push a small ping flood from the far end of the path. 1,000 ICMPs back-to-back with -l 1400 on Windows or -s 1400 on Linux. Zero loss expected.
  4. Hit the application that motivated the ticket. If users complained about Outlook in the morning, open Outlook on a representative laptop and verify mail flow.
  5. Update the maintenance log with the timestamp, the config diff, and the verification evidence.

Cost and lead-time reality

If this fix involves a hardware swap, here is what real procurement looks like in India in 2026:

If you tender through GeM (Government e-Marketplace), expect L1 to clear roughly 6-9% below distributor net, but lead time is 21-35 days and the PO process is rigid. Plan accordingly.

Brand quirks you will hit

Avoiding recurrence

Once the immediate fix is in, do the boring follow-up work that keeps it fixed:

  1. Add a kron job that snapshots show running-config to a TFTP server every 6 hours. Versioned configs are gold during the next 02:00 incident.
  2. Enable logging trap informational and ship to a Syslog server. PuTTY 0.78 with logging to a dated .log file (Translation tab → UTF-8) or SolarWinds NPM 2024.4 makes the data actionable. Without a Syslog destination, debug output dies with the SSH session.
  3. Document the change in your CMDB or whatever passes for one. A line that says "2026-06-05: applied EIGRP K-value fix at RTR-WHT-01, see ticket INC-48291" saves hours next time someone touches this device.
  4. Schedule a config audit per quarter. Run diff between today's config and the gold copy. Three minutes per device, catches 80% of drift before it bites.
  5. Build a habit: before you log out of a device after making a change, type copy running-config startup-config. Cisco does not auto-save. I have seen engineers reboot after a clean change and lose every line of config because they forgot.

Escalation path

FAQ

How long does the actual fix take once you know what to do?

From the moment you log in to the moment the verification command shows green, expect 8-15 minutes. The first time someone hits the symptom and has to learn it, more like 60-90 minutes. After that, it is muscle memory.

Do I need a maintenance window?

Yes, in production. Any config touch on a routing protocol can cause a 30-second re-converge at minimum. Plan for it. I scheduled the maintenance for Sunday 06:00 IST when the warehouse WMS is offline was the slot I used for this one.

What is the rollback if the fix makes things worse?

Before you commit, save the current running-config as flash:pre-2013-fix.cfg. If you have to roll back, configure replace flash:pre-2013-fix.cfg puts it back atomically. Faster than manual config rebuild and avoids the "I forgot one line" trap.

Will this work on IOS classic devices (non-XE)?

Most of the commands are identical. The platform-specific debug paths (FED, IOSd as a process) only apply to IOS XE. On classic IOS the same protocol symptom looks the same; the diagnostic surfaces differ.

Does this affect my SmartNet entitlement?

No. Applying official IOS XE configuration changes does not affect SmartNet. Loading non-Cisco firmware images would. Stay on signed releases from Cisco Software Download.

How do I prove to the auditor that the change was applied per policy?

Three artefacts: (1) the ticket with timestamp and approver, (2) the pre/post config snapshot, (3) the verification command output. Pin all three to the ticket. Auditors love date-stamped evidence.

Related guides

References

If something in here does not match what you see, drop me a line. I would rather correct one paragraph today than ship a guide that misleads someone at 02:00 IST.

Related guides worth a look while you sort this one out: