IP Address Assignment with PPP IPCP Negotiation

PPP provides a way to assign ip address to a remote client on a serial link using IPCP protocol. Remember IPCP is part of PPP protocol suite.

In it’s simplest form, assuming you have the topology shown below;

R2 (s1/2) ———————————-  R3 (s1/2)

Question:

Configure the serial link between R1 & R2 with PPP encapsulation

R2 should assign ip address to R1 interface

Answer:

To configure this, we need to configure an ip address to R2  interface with appropriate mask.

Enable R2 to supply ip address to R1 with “peer default ….” command

And finally disable peer neighbor route on both end of the link

R3:

interface Serial1/2
 ip address negotiated
 encapsulation ppp
 end 

R2:

interface Serial1/2
 ip address 160.1.4.2 255.255.255.0
 encapsulation ppp
 peer default ip address 160.1.4.3
 end

 

Output on R3:

Gateway of last resort is not set

     3.0.0.0/24 is subnetted, 1 subnets
C       3.3.3.0 is directly connected, Loopback0
     160.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
C       160.1.1.0/24 is directly connected, Serial1/0
C       160.1.3.0/24 is directly connected, FastEthernet0/0
C       160.1.4.3/32 is directly connected, Serial1/2
C       160.1.4.2/32 is directly connected, Serial1/2

——–

Serial1/0                  160.1.1.3       YES NVRAM  up                    up     
Serial1/2                  160.1.4.3       YES IPCP   up                    up     
Loopback0                  3.3.3.3         YES NVRAM  up                    up

Output on R2:

Rack1R2#sh ip ro co
     2.0.0.0/24 is subnetted, 1 subnets
C       2.2.2.0 is directly connected, Loopback0
     160.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
C       160.1.1.0/24 is directly connected, Serial1/0
C       160.1.2.0/24 is directly connected, FastEthernet0/0
C       160.1.4.0/24 is directly connected, Serial1/2
C       160.1.4.3/32 is directly connected, Serial1/2

 

You can see from these outputs that ip address assigned to s1/2 interface on R3 is from IPCP. You also noticed that output from “sh ip route” displayed 2 routes with /32 pointing in the direction of the link.

By default, when PPP link is enabled on a link, PPP creates a host routes for it’s peer on that link in it’s RIB and this is why we have one of the /32 route.  Basically, the router adds it remote peer’s ip address to it’s routing table with a /32 mask (And infact on both end of the links). This is applicable to static ip address assignment or negotiated on a PPP enabled link.

Ok, so why is the assigned ip address for R3 displayed with a mask of /32 in R3 RIB ?

When a PPP client peers assigns ip address to it’s remote peer on the link, it by default assigns the route as a /32 route and this is why we have “160.1.4.3/32” in R3 RIB.

There are two issues here:

1) How doe we remove this peer route from the router’s routing table since we really do not need it

2) How do we make IPCP assign the remote peer address with the correct mask (instead of /32).

 

To fix the first issue, we need to add an extra command to the serial links on both end of the link and then shut/no shut. This is shown below

R3:

interface Serial1/2
 ip address negotiated
 encapsulation ppp
 no peer neighbor-route
end 

R2:

interface Serial1/2
 ip address 160.1.4.2 255.255.255.0
 encapsulation ppp
 peer default ip address 160.1.4.3
 no peer neighbor-route
end

One of the Pitfalls to watch out for here is that if the peer neighbor route is not removed, it may cause RIP routes failure if RIP is enabled on this link. The reason for this failure is that when the the 2 routers exchange RIP updates, the router with static /24 address assigned (R2 here) will see the route from R3 as being in a different link since it expects /24 and the updates are being sent from a /32 address. Best Workaround for this RIP issue is to disable source address validation in RIP updates.

So, to the second issue raised above, the way to go about this is by configuring R2 to send /24 mask to R3 during IPCP negotiation. I will test this out and update this post later with the result.

“Do you know…” Series – (General technologies issues)

I have come across some hard facts about why some of the protocols behave the way they do and I want to use this “Do you know ………..” to be tracking all these. This is more like a Question & Answer (Q & A).  As I come across them I will be adding them to this list. As time goes on, I expect this list to be long.

Please note that comments, corrections, further explanations are welcome on this thread……..

Here we go………..

QuestionWhy is it a requirement in OSPF to have all other areas be either physically connected to area 0 or through virtual link or tunnells ?

What I found out about this is the fact that when you observe the behaviour of ospf ABR routers, you realised that what ABR does basically is to summarise reachbale networks within area and then generate LSA Type 3 (Summary LSA) and have this advertised to other areas.

If we reduce OSPF domain within an autonomous system to just the ABRs and their corresponding links, you will see that interchange of LSA Type 3 is done hop by hop (this is basically what happens between any area and area 0).

Hence, to ensure every ospf area has full reachability information from all othe areas, it is a requirement that every area be connected to area 0. With this area 0 has a full reachability detail and it exchanges them with all other areas within the domain.

This is kinda looks like holding daily management meetings everyday in an organisation and every department manager is required to attend and share whatever information they need to share so that every other manager in the meeting can hear it and subsequently share it with their respective teams.

Question: One-way PPP Link Aunthentication

I came across an interesting topic (that I never knew before) that ppp aunthentication does not really have to be configured on both ends of the link for it to work.

I know that for the CCIE lab, PPP encap will probably expect basically 2 types of aunthentication – CHAP & PAP. To enable this chap aunthetication type, we normally need a configuration similar to the one shown below;

  •  hostname R1
    username R3 password 0 cisco
    interface Serial1/1
     ip address 10.10.10.1 255.255.255.0
     encapsulation ppp
     ppp authentication chap

 

  •  hostname R3
    username R1 password 0 cisco
    interface Serial1/1
     ip address 10.10.10.2 255.255.255.0
     encapsulation ppp 
  • ppp authentication chap

But the truth is that we really do not need to have ppp authentication chap enabled on both ends for this link to be authenticated prior to moving it to UP state. All that is required is to have it enabled on one end of the link as shown below.

  •  hostname R1
    username R3 password 0 cisco
    interface Serial1/1
     ip address 10.10.10.1 255.255.255.0
     encapsulation ppp
     ppp authentication chap

 

  •  hostname R3
    username R1 password 0 cisco
    interface Serial1/1
     ip address 10.10.10.2 255.255.255.0
     encapsulation ppp

Now the interesting part to this is that what if we get a question that says make R1 authenticate R3 with chap while on this same link, R3 authenticates R1 with pap ?

For this, all we need to do is to enable ppp authentication pap on R3 and ensure we configure ppp pap sent-usename <name> password <pass> on the R1 end under the interface config. This required because with pap, router do not sent it’s hostname with the shared password, hence this has to be configured on the remote end.

  •  hostname R1
    username R3 password 0 cisco
    interface Serial1/1
     ip address 10.10.10.1 255.255.255.0
     encapsulation ppp
     ppp authentication chap
  • ppp pap pap sent-username R1 password cisco

 

  •  hostname R3
    username R1 password 0 cisco
    interface Serial1/1
     ip address 10.10.10.2 255.255.255.0
     encapsulation ppp
  • ppp authentication pap

Question: Running multicast in hub/spoke network (Frame Relay).

One important thing not to forget is to enable ip pim nbma-mode on the hub router.