PPP default route

One of those readers that prefer to remain anonymous has left an interesting comment to my post “Almost-dynamic routing over ADSL interfaces”:

You do not need the route "ip route 0.0.0.0 0.0.0.0 Dialer0 10 track 100" and the tracking if you configure "ppp ipcp route default" on the dialer interface. Works the same way... :-)

You might be wondering why Cisco's engineers decided to pollute IOS with yet another feature. The problem they had was the way PPP over Frame Relay is implemented: it uses virtual interfaces and although you have a very static connection, you cannot bind a static interface name to it. A dynamic interface (with potentially changing name) is cloned from the virtual template every time the PPP-over-Frame-relay session is started. Obviously you cannot configure a static default route pointing to it in advance, so you need yet another feature to do it (I'll not even try to figure out how to create non-default static routes pointing to cloned interface).

Reduce IP addressing errors in lab environment

One of the most tedious tasks in the initial lab setup (at least for me) is the IP address configuration, which usually includes a number of typos and mixups on the WAN links. You can simplify then WAN address configuration if you configure only one end of the WAN link and let PPP do the rest. For example, you could use the following configuration to configure WAN link on your core router …

hostname Core-2
!
interface Serial1/0
 description link to POP
 ip address 10.0.2.1 255.255.255.252
 encapsulation ppp
 peer default ip address 10.0.2.2

… and use IPCP negotiation on the POP router to pick up the WAN IP address:

hostname POP
!
interface Serial1/0
 description link to Core-1
 ip address negotiated
 encapsulation ppp

You should not configure no peer neighbor-route on the router that gets dynamic IP address, as the subnet mask is not assigned with IPCP; you need the IPCP-generated host routes if you want to do hop-by-hop telnet between the routers.

Remove unwanted PPP peer route

When IOS started supporting dynamic allocation of IPCP (IP over PPP) addresses, it also got the mechanism to insert a dynamic host route toward the neighbor's IP address once the IP addresses were negotiated. This mechanism makes perfect sense in dynamic address allocation environments, as the subnet mask is not negotiated with IPCP. Without a host route toward the other end of the PPP link, there would be no easy way to reach the IP prefixes reachable via the PPP link.However, the PPP code got way too aggressive in the recent IOS releases. For example, in the 12.4T train, you get a connected host route toward the IP address of the PPP peer even on a leased line where both addresses are in the same IP subnet. Here's a sample printout from my lab router that illustrates this behavior:

R1#show run interface serial 1/0
Current configuration : 107 bytes
!
interface Serial1/0
 ip address 10.1.0.1 255.255.255.252
 encapsulation ppp
 serial restart-delay 0
end
 
R1#show ip route 10.1.0.0 255.255.255.252 longer | begin Gateway
Gateway of last resort is not set
 
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C       10.1.0.2/32 is directly connected, Serial1/0
C       10.1.0.0/30 is directly connected, Serial1/0

To disable the automatic insertion of the connected host route, use the no peer neighbor-route interface configuration command.

You have to clear the IP routing table or flap the interface to remove the PPP-generated host route

Configure DNS servers through IPCP

After I've fixed the default routing in my home office, I've stumbled across another problem: the two ISPs I'm using for my primary and backup link have DNS servers that reply solely to the DNS requests sent from their own IP address range:

When the traffic is switched from the primary to the backup ISP, I therefore also need to switch the DNS servers. Fortunately, this is quite easy to do on a router; you just need to configure ppp ipcp dns request on the dialer interface and the router starts asking for the DNS server address as part of the IPCP negotiation.
The negotiation process can be debugged with the debug ppp negotiation command; it's a bit more complex than usual in my case since the access server has no secondary DNS (only the primary DNS is configured):

Se1/0 IPCP: O CONFREQ [Closed] id 1 len 22
Se1/0 IPCP:    Address 0.0.0.0 (0x030600000000)
Se1/0 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Se1/0 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Se1/0 PPP: Process pending ncp packets
Se1/0 IPCP: Redirect packet to Se1/0
Se1/0 IPCP: I CONFREQ [REQsent] id 1 len 10
Se1/0 IPCP:    Address 10.0.0.33 (0x03060A000021)
Se1/0 IPCP: O CONFACK [REQsent] id 1 len 10
Se1/0 IPCP:    Address 10.0.0.33 (0x03060A000021)
Se1/0 IPCP: I CONFREJ [ACKsent] id 1 len 10
Se1/0 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Se1/0 IPCP: O CONFREQ [ACKsent] id 2 len 16
Se1/0 IPCP:    Address 0.0.0.0 (0x030600000000)
Se1/0 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Se1/0 IPCP: I CONFNAK [ACKsent] id 2 len 16
Se1/0 IPCP:    Address 10.0.0.34 (0x03060A000022)
Se1/0 IPCP:    PrimaryDNS 10.0.0.10 (0x81060A00000A)
Se1/0 IPCP: O CONFREQ [ACKsent] id 3 len 16
Se1/0 IPCP:    Address 10.0.0.34 (0x03060A000022)
Se1/0 IPCP:    PrimaryDNS 10.0.0.10 (0x81060A00000A)
Se1/0 IPCP: I CONFACK [ACKsent] id 3 len 16
Se1/0 IPCP:    Address 10.0.0.34 (0x03060A000022)
Se1/0 IPCP:    PrimaryDNS 10.0.0.10 (0x81060A00000A)
Se1/0 IPCP: State is Open

The results can be inspected only with the show host command:

GW#show host
Default domain is not set
Name/address lookup uses domain service
Name servers are 10.0.0.10

The access server receiving the call requires no special configuration; the first IP address configured with the ip name-server command is used as the primary DNS and the second one as the secondary. Alternatively, you can configure a different set of DNS servers to pass to the client with the ppp ipcp dns primary-DNS-address secondary-DNS-address interface configuration command.

Unfortunately, the integration with LAN clients is not as seamless as with DHCP; to make the whole solution work, you have to configure the router as a forwarding DNS server and make the LAN clients use the router as the default gateway and DNS server with the DHCP pool configuration:

ip dns server
!
ip dhcp pool LAN
   import all
   network 192.168.0.0 255.255.255.240
   default-router 192.168.0.1
   dns-server 192.168.0.1

Install default route with PPP

In my home office, I'm using DSL access to the Internet with ISDN backup to another ISP, as shown on the next figure:

Obviously, I would like the ISDN backup to kick in whenever the primary connection goes down; two static default routes and reliable static routing on the primary default seem like a perfect solution. However, as I'm using PPP encapsulation on the primary connection, there's another option: PPP can insert a dynamic default route whenever IPCP negotiations succeed (and remove it when the line protocol goes down). To configure this feature (introduced in IOS releases 12.3(11)T and 12.4), use the ppp ipcp route default interface configuration command on the primary dialer interface.Contrary to the DHCP-installed default route, the PPP-installed default route has administrative distance 1 (and is thus impossible to override):

GW#show ip route | begin Gateway
Gateway of last resort is 10.0.0.33 to network 0.0.0.0
 
     10.0.0.0/32 is subnetted, 2 subnets
C 10.0.0.34 is directly connected, Serial1/0
C 10.0.0.33 is directly connected, Serial1/0
     192.168.0.0/28 is subnetted, 1 subnets
C 192.168.0.0 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 [1/0] via 10.0.0.33

Emulate dialup links with serial lines

I had to figure out various PPP parameters (and associated Cisco IOS behavior) and didn't have real dial-up equipment in my lab setup. I could have gone with PPPoE, but it turned out it's way simpler to emulate dialup connections (at least the PPP negotiations work as expected) on fixed serial lines. This is the minimum setup you need on the “caller” side …

interface Serial1/0
 ip address negotiated
 encapsulation ppp
 ppp authentication pap optional
 ppp pap sent-username client password 0 client

… and this is the “server”-side configuration:

interface Serial1/0
 ip address 10.0.0.33 255.255.255.252
 encapsulation ppp
 peer default ip address 10.0.0.34
 ppp authentication pap callin
!
username client password client

To trigger PPP negotiations, shut down and re-enable the serial interface on either side.

Note: As I'm using PAP authentication, I could use the more secure username secret configuration command, which would not work with CHAP.