This post is a little off-topic from the CCIE study material, but still relevant in terms of PPP. Anyways I recently had some ethical problems with my ISP (BT) and their BT Infinity product (if you’re from the US assume I’m talking about a provider like Comcast, or if you are from from France assume it’s Orange, or just some big ISP). It’s basically a Fiber To The Cabinet (FTTC) product, and then copper from the cabinet in the street to your home. Since BT reserve the right to remote-manage the router they supplied (even though it’s not a managed service and the customer technically owns the router), they regularly push updates, firewall changes and other stuff to the box using a protocol called CWMP. Long story short, their constant updates rebooted the router on a regular basis, and now I am replacing the router with a Cisco 887VA. The configuration required to get the PPPoE WAN side working is shown below. Note that shutting down the ATM0 interface is absolutely required in order to get this to work. The 887VA comes with an ADSL/VDSL combination interface and you can only use the ADSL OR the VDSL. By shutting down the ATM0 interface, it allows you to use the VDSL connection.

interface Dialer1
ip address negotiated
encapsulation ppp
ip tcp adjust-mss 1452
dialer pool 1
ppp mtu adaptive
ppp authentication chap callin
ppp chap hostname bthomehub@btbroadband.com
ppp chap password 0 bt

interface ATM0
no ip address
shutdown

interface Ethernet0.101
encapsulation dot1Q 101
pppoe-client dial-pool-number 1
I will now run over some of the technicalities below.

MTU explination

Ethernet uses a standard 1500 byte MTU to transmit data. However when we use PPPoE, it adds an extra 8 bytes of overhead (6 bytes for the PPP header and 2 bytes for the PPP Protocol ID) when it encapsulates the datagram with PPP. So this means that in order to make sure we do not exceed the Ethernet 1500 byte MTU, we have to ensure we restrict the MTU size of the PPP frame to 1492. So when PPP encapsulates the frame and adds 8 bytes onto it, then it will not exceed 1500 bytes. The way I’ve done this in the configuration is by using #ppp mtu adaptive on the dialer interface. Where, when the negotiation of the link parameters is determined using Link Control Procol (LCP), it just simply accepts the MTU provided by the peer.

The way I checked that the peer wasn’t going to give me some funky MTU value, was just to enable a debug, shown below. Note, I also took my adaptive mtu setting off temporarily to show why we actually need it (ideally).

router#debug ppp negotiation
router#config t
router(config)#int di1
router(config)#no ppp mtu adaptive
router(config)#shut
router(config)#no shut

Feb 10 22:46:15.060: %DIALER-6-BIND: Interface Vi2 bound to profile Di1
Feb 10 22:46:15.064: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
Feb 10 22:46:15.064: Vi2 PPP: Sending cstate UP notification
Feb 10 22:46:15.064: Vi2 PPP: Processing CstateUp message
Feb 10 22:46:15.064: PPP: Alloc Context [8551EED0]
Feb 10 22:46:15.064: ppp4 PPP: Phase is ESTABLISHING
Feb 10 22:46:15.064: Vi2 PPP: Using dialer call direction
Feb 10 22:46:15.064: Vi2 PPP: Treating connection as a callout
Feb 10 22:46:15.064: Vi2 PPP: Session handle[85000004] Session id[4]
Feb 10 22:46:15.064: Vi2 LCP: Event[OPEN] State[Initial to Starting]
Feb 10 22:46:15.064: Vi2 PPP: No remote authentication for call-out
Feb 10 22:46:15.064: Vi2 LCP: O CONFREQ [Starting] id 1 len 10
Feb 10 22:46:15.064: Vi2 LCP: MagicNumber 0x87665B00 (0x050687665B00)
Feb 10 22:46:15.068: Vi2 LCP: Event[UP] State[Starting to REQsent]
Feb 10 22:46:15.104: Vi2 LCP: I CONFREQ [REQsent] id 88 len 19
Feb 10 22:46:15.104: Vi2 LCP: MRU 1492 (0x010405D4)
Feb 10 22:46:15.104: Vi2 LCP: AuthProto CHAP (0x0305C22305)
Feb 10 22:46:15.104: Vi2 LCP: MagicNumber 0x7CCF52D6 (0x05067CCF52D6)
Feb 10 22:46:15.104: Vi2 LCP: O CONFNAK [REQsent] id 88 len 8
Feb 10 22:46:15.104: Vi2 LCP: MRU 1500 (0x010405DC)
Feb 10 22:46:15.104: Vi2 LCP: Event[Receive ConfReq-] State[REQsent to REQsent]
From the output we can see that the incoming Maximum Receivable Unit (MRU) is 1492 (note that the red colored “I” denotes that this is an incoming message. Likewise, “O” means outgoing). My router then stated he didn’t want to use this MRU, and wanted to use 1500 (default Ethernet MTU size). So to get this setting corrected I just used the #ppp mtu adaptive command, which just listens to what the other side of the PPP session wants to use, and just accepts that value. Another way you can do this is just by setting the MTU on the dialer using #mtu 1492. Note, this is not the same as #ip mtu 1492, which a lot of people have mistakenly put on their configurations. The #IP mtu command would just influence the maximum size of the layer 3 PDU that can be encapsulated into the PPP payload. However, I’m not trying to do that. Instead I’m trying to tell the PPP neighbor that my MRU is 1492, which is nothing to do with any upper layer protocols such as IP.

Command: #ip tcp adjust-mss

This command adjusts the Maximum Segment Size (MSS), otherwise known as payload, that is allowed to be used when sending TCP segments.

So we know that Ethernet has an MTU/payload of 1500 bytes. So everything from all the upper layer protocols must fit into this 1500 byte data field in the Ethernet frame before it gets transmitted across the link. We also know PPP adds 8 bytes of headers, IP adds 20 bytes of headers, and TCP adds 20 bytes of headers. So 1500-8-20-20 = 1452. So the maximum amount of data that we could possibly send in the TCP segment would be 1452 bytes. So this is therefore our MSS value. If we were to exceed this value, then it would not fit inside the Ethernet frame, and device would notify the upper layer protocols that fragmentation needs to occur in order to transmit the data across the link.

Miscellaneous

In order for the VDSL card to work inside the 887VA, you have to actually shutdown the ATM interface. So that is why I included that in this configuration. The actual VDSL configuration is done on the Ethernet 0 interface (I bet you always wondered why that interface was there! I know I did lol). Also, BT advise for PPPoE to work on their network, we have to use VLAN 101, which is the reason for the encapsulation on the Ethernet interface.