tcp adjust mss on bridged 887va

[casperionx]

Ok, so I've got a strange situation where MSS clamping (or lack thereof) is killing my web browsing (and more importantly that of my kids and wife).

My current set up is an IPOE vDSL connection that is terminated with a Cisco 887VA configured as a straight bridge. I have an XR1000 netgear as my router to allow proper nat hair pinning as if I configure it with the cisco, it kills the CPU and massively reduces my download.

Now browsing some websites doesnt work in this configuration, even after changing the MTU on the router. 

Testing seems to indicate, its an MSS issue. Now if I configure tcp-adjust mss xxxx on the VLAN interface that is bridged with the wan interface on the cisco would it do anything? Im under the impression that it wont. 

ANy ideas would be appreciated (I'll post config a little later as Im away from home at present)

[M02@rt37]

Hello @casperionx,

Before enabling MSS clamping, I would recommend investigating further to try to identify the root cause of the issue. You may want to try running some network diagnostics and troubleshooting steps, such as checking for packet loss, running traceroutes, and analyzing network traffic.

[Joseph W. Doherty]

A BVI or a SVI interface?  Would expect MSS adjust to work with the latter, because transit traffic uses interface's MAC, but the former doesn't, so wouldn't expect it to work with the former.

Are you using a value of 1492?

[casperionx]

Heres the config:

!
hostname COREHPG
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
memory-size iomem 10
clock timezone AEST 10 0
!
!
no ip routing
!
!
!
!

!
!
!
!
no ip cef
no ipv6 cef
!
!
multilink bundle-name authenticated
license udi pid CISCO887VA-SEC-K9 sn xxxxxxx
!
!
username casperionx privilege 15 secret 5 xxxxxxxxxx
!
!
!
!
!
controller VDSL 0
operating mode vdsl2
firmware filename flash:VA_A_39m_B_38h3_24h.bin
sra
!
!
!
!
!
!
!
!
!
!
interface Ethernet0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip virtual-reassembly in
no ip route-cache
bridge-group 1
!
interface ATM0
no ip address
no ip route-cache
shutdown
no atm ilmi-keepalive
!
interface FastEthernet0
no ip address
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
!
interface FastEthernet3
switchport access vlan 2
no ip address
!
interface Vlan1
no ip address
no ip route-cache
bridge-group 1
!
interface Vlan2
ip address 192.168.1.252 255.255.255.0
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
!
!
!
control-plane
!
bridge 1 protocol ieee
!
!
line con 0
exec-timeout 0 0
privilege level 15
no modem enable
line aux 0
line vty 0 4
privilege level 15
login local
transport input all
!
!
end

---

[casperionx]

Based on what I have learnt over the years in cisco land it should just straight up pass packets and not change the mtu on them. But on the router Im using at the moment I have to deduct 8 bytes, even though Im using IPOE...which shouldnt need any over head...

[Elliot Dierksen]

MTU on the actual physical interface is something that can usually not be increased beyond a certain limit. If you are using a tunneling protocol like PPPoE then you lose bytes to the overhead of the tunnel. The best solution I have seen is on the interface with the limit (Dialer0 or something like that), put "ip tcp adjust-mss 1460" or something like that depending on the amount of overhead for the tunneling protocol. What that does is causes the router to revise the maximum segment size during the TCP connection opening. The host would say "I can do 1500 maximum segment size". The router adjusts that down so you don't overrun the MTU or cause packet fragmentation. Adjusting the MTU down will either cause fragmentation or a failure (ICMP packet too big).

[Joseph W. Doherty]

PPP authentication, I believe, is what imposes the 8 bytes of overhead.

mss-adjust, for TCP, on any in-line L3 hop, should deal avoid TCP fragmentation issues that would otherwise be caused by this overhead.  NB: this doesn't, though, help with other 1500 byte non-TCP packets.

For such, you would need to change IP MTU at either the end host (ideal) or also on a L3 transit hop, the latter though still has considerations.

Lastly, again, for a BVI, you're transiting the interface as L2, not L3, so likely IP MTU and/or mss-adjust don't come into play.

[casperionx]

Yeah, its a bizarre situation, and it makes no sense. especially since it is a IPOE service, which means there's no PPP overhead.