Understanding MTU for ADSL

[John Adams]

Hello, I wondered if anyone could help shed some light on this for me.

I've got an 887va. It is used for ADSL2+ - I followed this guide:

https://supportforums.cisco.com/message/3578292#3578292

All works but i've got myself wondering about the MTU settings.

Under the dialer0 interface that example has an MTU of 1492 with the setting 'ip mtu 1492'.

However on other examples on this site i've seen settings under the dialer0 interface for mass adjust such as 'ip tcp adjust-mss 1440'

Can someone help me to understand why different commands might be used and how I got about determining what is the best mtu or mass adjust size for my own connection. How do i determine the settings required?

I'm using pppoa - it is a BT ADSL2+ connection.

Thank you.

John.

[Peter Paluch]

John,

With true PPP-over-Ethernet encapsulation, the additional overhead is 8 bytes: 2B for PPP header and 6B for PPPoE header that comes in front of IP packets and is then put into the Ethernet frame payload. Out of 1500 bytes in Ethernet frame payload portion, only 1500-2-6=1492 bytes remain available for IP and higher protocols.

Decreasing the MTU on PPPoE interfaces below the size of 1492 bytes is not technically necessary. Doing it will cause the router to fragment even those IP packets that would otherwise still fit into the PPPoE encapsulation.

The TCP MSS setting should always be set to the MTU-40 bytes - this is a general rule that follows from the fact that a TCP segment body (controlled by the MSS) plus the TCP and IP header must not exceed the MTU. As the IP and TCP headers each have 20 bytes in length, the MSS should not exceed MTU-40.

To actually try to find out the maximum MTU of a connection that does not require fragmentation, check the following thread:

https://supportforums.cisco.com/message/4117310#4117310

This post describes a generic way to test the maximum supported MTU. Sadly, exactly in that thread, I was not able to actually determine any MTU issues - but at least the instructions hold

By the way, PPPoA is different from PPPoE. With PPPoA, there is no additional Ethernet+PPP-over-Ethernet encapsulation present, and the PPP frames are carried directly over ATM+AAL5. With PPPoA, there are no MTU issues whatsoever, and you simply forget about all MTU and MSS manipulations.

To know if you're running PPPoE or PPPoA, check the configuration of your ATM interfaces. If there is anything like pppoe-client dial-pool-number command present under a VPI/VCI then you're running PPPoE. If there is a protocol ppp dialer command present, you are running PPPoA.

Feel welcome to ask further!

Best regards,

Peter

[John Adams]

Thank you very much for your reply Peter.

So unless I experience an issue i should not enter either of these settings.

If I do - i likely want to  try and see at what point it gets fragmented and then set my MTU accordingly under the dialer0 interface - this may likley be 1492.

I understand you say the tcp mss would be -40 from the mtu - in this case 1452 - would I also need to set that if I set my MTU or does it automatically get set?

Can one work without the other, is there a need to put in both commands?

[Peter Paluch · Accepted solution]

Hi John,

So unless I experience an issue i should not enter either of these settings.

With PPPoE, it is highly recommended to set the MTU to 1492, and MSS to 1452 even if you see no issues.

With PPPoA, no tampering with MTU/MSS is necessary unless you exactly know you need it.

If I do - i likely want to  try and see at what point it gets fragmented  and then set my MTU accordingly under the dialer0 interface - this may  likley be 1492.

Quite right.

I understand you say the tcp mss would be -40 from the mtu - in this  case 1452 - would I also need to set that if I set my MTU or does it  automatically get set? 

You would need to set it manually. The TCP MSS adjustment, sometimes also called a MSS Clamping, is something that routers normally don't perform. The TCP MSS adjustment causes the router to intrude into each TCP session established over the interface, and rewrite one of the TCP options negotiated at the start of every TCP session that is used to advertise the maximum segment size. The net result is that each end TCP session is manipulated into sending segment sizes no larger than the value configured in ip tcp adjust-mss command, avoiding fragmentation at the IP level.

Can one work without the other, is there a need to put in both commands? 

Both commands are independent of each other but they work in tandem: the ip mtu defines the maximum size of any IP packet that passes through the interface (larger packets will be fragmented at the IP level). ip tcp adjust-mss modifies the TCP sessions passing through the interface so that they never generate a segment that would, after getting its TCP and IP headers, become larger than the MTU and thus require fragmentation.

This article is a very good reading (not related specifically to PPPoE but still relevant):

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

Best regards,

Peter

[John Adams]

Thank you again. I've confused myself now if my setup is pppoa or pppoe - can you tell me?

interface ATM0

description *Connection to Dialer0*

no ip address

no atm ilmi-keepalive

(Not sure I understand all the settings either!).

(Hopefully my settings mean my dialer never goes down when idle - not really sure if all required)

interface ATM0.1 point-to-point

pvc 0/38

encapsulation aal5mux ppp dialer

dialer pool-member 1

interface Dialer0

description *ADSL*

ip address negotiated

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip virtual-reassembly in

encapsualtion ppp

no ip route-cache cef

dialer pool 1

dialer idle-timeout 0

dialer persistent

dialer-group 1

ppp authentication chap callin

ppp chap hostname username@bt.com

ppp chap password 7 password

no cdp enable

[Peter Paluch · Accepted solution]

Hi John,

interface ATM0.1 point-to-point
pvc 0/38
encapsulation aal5mux ppp dialer
dialer pool-member 1

Aaah, yes, this is PPPoA. My example was based on a slightly different ATM AAL5 encapsulation called AAL5SNAP in which a single PVC is shared among different protocols, and individual protocols are identified by inserting a SNAP header before each packet as it is passed over the ATM PVC. The disadvantage of that approach is an additional overhead - it does not influence your MTU but it may result in an additional ATM cell to be sent with each higher packet.

This configuration shown here is based on AAL5 encapsulation called AAL5MUX that devotes the entire PVC just to a single protocol. If only a single protocol is carried by this PVC, additional headers identifying the payload are unnecessary. This use of ATM+AAL5 is more efficient.

In any case, you are running PPPoA here, so you do not need to worry at all about MTU and TCP MSS.

A comment regarding the configuration of your Dialer0 interface: you can safely remove these commands:

dialer idle-timeout 0

dialer persistent

dialer-group 1

ppp authentication chap callin

The first three commands relate to operation of your Dialer0 interface if it was using a dialed connection - but DSL is an always-on technology, there is no dialing, so these commands defining the idle timeout before dropping the connection, keeping the connection always on, and defining the interesting traffic that can cause a dial to be placed, are useless and should be removed. So should also the last command that relates to PPP authentication - this command pops up very often, and is grossly mistaken. It is not related to allowing yourself to be authenticated to ISP, on the contrary: it would require the ISP to authenticate to you if the PPP connection was treated as being incoming. While luckily, IOS treats DSL PPP connections as "dedicated" (i.e. neither callout nor callin), this command is ineffective, but if it ever came into effect, it would require your ISP to authenticate to you, and that would necessarily fail: did you agree on any password your ISP should use to authenticate to you? Surely not.

On the other hand, I am puzzled by the presence of no ip route-cache cef on your Dialer0. Did you ever deactivate routing on your router? Please enter the following commands in your configuration:

ip routing

ip cef

interface Dialer0

ip route-cache

ip route-cache cef

end

Best regards,

Peter

[John Adams]

Thank you. I have removed the 3 dialer lines and ppp line as per your suggestion  -i will try this when I can test at my remote office. (It's not in live production yet).

I've also done the commands you asked - i'm not sure why i had the no no ip route-cache cef command - i think i'd just copied it from an example online - what's wrong with the command and what would it do(or not do and cause problems for?). (And why do I need the ip route-cache and cef lines in?

Thank you.

[Peter Paluch]

John,

If you enter the ip route-cache and ip route-cache cef, they will not in fact appear in the configuration because they are the default setting.

The route cache and CEF are accelerated packet switching mechanisms that allow your router to achieve significantly higher packet routing/switching efficiency that the basic algorithm. Incidentally, you had exactly those mechanisms deactivated. Packets flowing through your router would then be processed in the slowest mechanism we call process switching - it would basically work but it could cause high CPU and noticeably lower throughput, especially with high bandwidths.

This is a document that might be an interesting reading for you here:

http://www.cisco.com/en/US/tech/tk827/tk831/technologies_white_paper09186a00800a62d9.shtml

Best regards,

Peter

[John Adams]

Many thanks - I will update this thread when I get the chance to test the config

[John Adams]

I tried the ping as detailed in your other thread with all the settings suggested.

I got a reply from size 1400 through to 1500. It failed on the following to get a reply for some reason. 1412,1449,1457,1460,

All other mtu sizes got a reply back.

What do we dtermine from that?

[Peter Paluch · Accepted solution]

Hi John,

As you are running PPPoA and not PPPoE, you do not have any issues with MTU. The extended ping sweeping the size range from 1400 to 1500 has proved that.

My personal guess about the failed responses is that the ping request or response simply got lost in transit, or the device you were pinging rate-limited the responses. You can test the specific sizes once again to see if they truly get lost:

ping 158.193.152.2 size 1412 df-bit

Best regards,

Peter

[John Adams]

Hello - I tried again and had a 100% success rate when i pinged a different set of IPs.

I'm happy this issue now looks OK. Thank you for your help.