pppoe-client ppp-max-payload command results in wrong dialer mtu

[pointless_l]

My ISP supports RFC 4638 on my VDSL connection and requests me to set an MTU of 1508 on the VLAN interface and an MTU of 1500 on the PPPoE interface. I used this Cisco document and made the following change to my config:

interface Ethernet0.6
 encapsulation dot1Q 6
 pppoe enable group global
 pppoe-client dial-pool-number 1
 pppoe-client ppp-max-payload 1508

The ppp-max-payload command does something funny to my Dialer config as it adds the following line item:

interface Dialer1
 mtu 1508

IMO this should be 1500 (b/c of the 8 bytes overhead). During the PPP negotiation I get the following handshake:

*Jul 19 11:25:00.749: %DIALER-6-BIND: Interface Vi2 bound to profile Di1
*Jul 19 11:25:00.757: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
*Jul 19 11:25:00.757: Vi2 PPP: Sending cstate UP notification
*Jul 19 11:25:00.757: Vi2 PPP: Processing CstateUp message
*Jul 19 11:25:00.757: PPP: Alloc Context [1C360B4]
*Jul 19 11:25:00.757: ppp7 PPP: Phase is ESTABLISHING
*Jul 19 11:25:00.757: Vi2 PPP: Using dialer call direction
*Jul 19 11:25:00.757: Vi2 PPP: Treating connection as a callout
*Jul 19 11:25:00.757: Vi2 PPP: Session handle[28000007] Session id[7]
*Jul 19 11:25:00.757: Vi2 LCP: Event[OPEN] State[Initial to Starting]
*Jul 19 11:25:00.757: Vi2 PPP: No remote authentication for call-out
*Jul 19 11:25:00.757: Vi2 LCP: O CONFREQ [Starting] id 1 len 14
*Jul 19 11:25:00.757: Vi2 LCP:    MRU 1508 (0x010405E4)
*Jul 19 11:25:00.757: Vi2 LCP:    MagicNumber 0x44F6D48D (0x050644F6D48D)
*Jul 19 11:25:00.757: Vi2 LCP: Event[UP] State[Starting to REQsent]
*Jul 19 11:25:00.773: Vi2 LCP: I CONFREQ [REQsent] id 183 len 19
*Jul 19 11:25:00.773: Vi2 LCP:    MRU 1500 (0x010405DC)
*Jul 19 11:25:00.773: Vi2 LCP:    AuthProto CHAP (0x0305C22305)
*Jul 19 11:25:00.773: Vi2 LCP:    MagicNumber 0x7A9FF786 (0x05067A9FF786)
*Jul 19 11:25:00.773: Vi2 LCP: O CONFACK [REQsent] id 183 len 19
*Jul 19 11:25:00.773: Vi2 LCP:    MRU 1500 (0x010405DC)
*Jul 19 11:25:00.773: Vi2 LCP:    AuthProto CHAP (0x0305C22305)
*Jul 19 11:25:00.773: Vi2 LCP:    MagicNumber 0x7A9FF786 (0x05067A9FF786)
*Jul 19 11:25:00.773: Vi2 LCP: Event[Receive ConfReq+] State[REQsent to ACKsent]
*Jul 19 11:25:00.773: Vi2 LCP: I CONFACK [ACKsent] id 1 len 14
*Jul 19 11:25:00.773: Vi2 LCP:    MRU 1508 (0x010405E4)
*Jul 19 11:25:00.773: Vi2 LCP:    MagicNumber 0x44F6D48D (0x050644F6D48D)
*Jul 19 11:25:00.773: Vi2 LCP: Event[Receive ConfAck] State[ACKsent to Open]
*Jul 19 11:25:00.785: Vi2 PPP: Phase is AUTHENTICATING, by the peer
*Jul 19 11:25:00.785: Vi2 LCP: State is Open

So it seems the remote side is requesting 1500 but the Cisco insists on 1508. It's not possible to reconfigure the Dialer interface to 1500, it then defaults to the MAX value of 1492 and you'll have to reload to correct this.

As the default MTU is 1500 this doesn't cause any practical problems but I think the behavior is weird. Am I missing something or is this a bug? I'm running Version 15.8(3)M4 on a Cisco 897VA-B.

[paul driver]

Hello

for ppoe try the follwing to make sure your not incurring fragmentation,  and reduce accordingly if you have additional header overheads such are GRE/IPSEC

int dialer 1
ip mtu 1492 < non tcp packets
ip  tcp adjust-mss 1452 <  tcp packets

or 
ip mtu 1400 
ip  tcp adjust-mss 1360 

[pointless_l]

Hi Paul, thanks for your reply. The goal was to configure the router with support for larger (> 1492) PPPoE MTU as per RFC 4638. More and more ISP's support this and Cisco supports this as well but their implementation requests the wrong MTU from the ISP (in my case VLAN is 1508 so Dialer should be 1508-8=1500).

BTW as I said the configuration I have does work and fragmentation does not occur at large sizes:

#ping 8.8.8.8 size 1500
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms

---

@paul driver wrote:

Hello

for ppoe try the follwing to make sure your not incurring fragmentation,  and reduce accordingly if you have additional header overheads such are GRE/IPSEC

int dialer 1
ip mtu 1492 < non tcp packets
ip  tcp adjust-mss 1452 <  tcp packets

or 
ip mtu 1400 
ip  tcp adjust-mss 1360 

---

---

[paul driver]

Hello
Apologies, but curious are you iniciating the ping from the router itself if so you may not see fragmentation, Try from behind the router?

[pointless_l]

I do get a different result but this expected (subtract 28 bytes for ICMP and IP headers as explained here

 ping 8.8.8.8 -f -l 1472

Pinging 8.8.8.8 with 1472 bytes of data:
Reply from 8.8.8.8: bytes=68 (sent 1472) time=18ms TTL=118
Reply from 8.8.8.8: bytes=68 (sent 1472) time=17ms TTL=118
Reply from 8.8.8.8: bytes=68 (sent 1472) time=14ms TTL=118
Reply from 8.8.8.8: bytes=68 (sent 1472) time=18ms TTL=118

Ran in Powershell with do not fragment flag on. 1472 is the highest size I can ping as opposed to 1500. So I think all is working correctly, it's just that the router should request an MTU of 1500 from the remote server and not 1508.

[Giuseppe Larosa]

Hello @pointless_l ,

the payload size should be the size of what is carried within a PPP frame.

So I would try to use a size of 1500 for the command taking in account 8 bytes of PPPoE overhead.

Hope to help

Giuseppe

[pointless_l]

Hi Guiseppe, I was thinking the same thing but when I configured

 pppoe-client ppp-max-payload 1500

the connection worked but fragmentation occurred when the size was > 1492 so a ping with size 1492 would work but a ping with a size of 1493 would not. I thus think that the ppp-max-payload of 1508 is correct but the dialer mtu should be 1500 and not 1508 (but there is no way to set this)