This is small topic about establishing PPPoE session using Cisco devices and its various IP addressing techniques. A Cisco router can act as either of PPPoE client or server. In out simple topology, we have 3 routers in which R1 is our PPPoE client and R2 is PPPoE server. While configuring PPPoE client, we need an special interface, named “dialer interface” which is virtual and will bind to physical interface f0/0 on R1. The default encapsulation of dialer interface is not PPP and we need to set it up manually. Sample configuration of our R1, as a PPPoE client will be like this:
interface Dialer1 ip address negotiated encapsulation ppp dialer pool 5 dialer idle-timeout 0 dialer persistent ppp chap password 0 cisco end
The IP address of the interface will be assigned automatically through PPP negotiation process and the command “ip address negotiated” means the same. The number we’ve used in “interface dialer” command, in our case “1”, is not important and you can use whatever you want, just remember that this number must be unique among other dialer interfaces on local router, if any exists. But the number we uses in “dialer pool” command is important, because we will bind this dialer interface to physical interface by this number. In our case, this number is “5”. “Dialer persistent” command makes the connection always up. But if you want to define interesting traffic, you can use “dialer-list” global and “dialer-group” interface configuration commands. Also, our client must send its username and password to PPPoE server for authentication purpose. By default router will send its hostname as username and “ppp chap password 0 cisco” defines the password that should be send along with username to R2. Because there is no need for R1 to authenticate PPPoE server, we did not run “ppp authentication chap” on R1, so the authentication will proceed unidirectional. At this point we need to bind our virtual dialer interface to physical f0/0 on R1.
interface FastEthernet0/0 no ip address duplex auto speed auto pppoe enable pppoe-client dial-pool-number 5
Now it’s the time for configuring our PPPoE server. Instead on 2-level process that was done on client, the configuration on server has 3 levels. First of all we need to create another type of virtual interface, named “virtual-template” as following:
interface Virtual-Template1 ip address 184.108.40.206 255.255.255.0 no peer neighbor-route peer default ip address 220.127.116.11 ppp authentication chap
The IP address that will assigned to our PPPoE client is determined by “peer default ip address 18.104.22.168” command. This address is in /32 format. The last command enables PPP CHAP authentication on this interface. With addition of “username R1 password cisco” command that is written in global configuration mode, R2 will be able to evaluate the credentials it receives from R1. If you have worked with PPP, then you are familiar with /32 entries that is created by PPP automatically and put inside routing table. If you are not comfortable with this /32 entries inside routing table, you can use “no peer neighbor-route” that deletes these entries. But remember that this command is used just on PPPoE server device and should not written on PPPoE client. The second step is binding this virtual-template interface to special entity, named “bba-group”:
bba-group pppoe TEST_G virtual-template 1
This group is what we will bind to physical interface f0/1 on R2 that acts as PPPoE server.
interface FastEthernet0/0 no ip address duplex auto speed auto pppoe enable group TEST_G
If everything went right, we should be able to ping R2 from R1.
R1(config-if)#dii Interface IP-Address Method Status Protocol FastEthernet0/0 unassigned unset up up Virtual-Access1 unassigned unset up up Virtual-Access2 unassigned unset up up Dialer1 22.214.171.124 IPCP up up Loopback0 126.96.36.199 manual up up
R1(config-if)#do ping 188.8.131.52 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 184.108.40.206, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/25/40 ms
You can see active PPPoE sessions on R2 too:
R2(config)#do sh pppoe session 1 session in LOCALLY_TERMINATED (PTA) State 1 session total Uniq ID PPPoE RemMAC Port VT VA State SID LocMAC VA-st 5 5 c200.19fc.0000 Fa0/0 1 Vi2.1 PTA c201.19fc.0000 UP
Now that we’ve configured our basic PPPoE session between R1 and R2, let’s test another IP addressing method in PPPoE scenarios, that is DHCP. In this method R1 will request its IP address from R2 via PPP negotiation process as before, but R2 will take this request and send it to external DHCP server, R3 in our case. There is no need to change R1’s configuration and R2 will do the main role. To reach our goal, we need some additional commands on R2. First, instead of typing client’s IP address statically in “peer default ip address” command, we will use “dhcp” keyword. This tells R2 to obtain client’s IP address from a DHCP server and then forward that IP to client through PPP negotiation process. But R2 doesn’t know about any DHCP server and we need to set up one. With command “ip dhcp-server” that is written in global mode, we can determine the location of DHCP server, router R3. The configuration of R3 is simple:
ip dhcp excluded-address 220.127.116.11 18.104.22.168 ! ip dhcp pool TEST_DHCP_POOL network 22.214.171.124 255.255.255.0
IP addresses in range 126.96.36.199 to 188.8.131.52 are excluded and then will not be assigned to any DHCP clients. So the first IP address will be 184.108.40.206. Another necessary command is “ip address-pool dhcp-proxy-client” that should be entered on R2 to make it able to act as DHCP proxy device. Without this command R2 will not pass through DHCP requests that are received from R1.
One important trick remains; because R1 has not gotten its IP address yet, then the link between R1 and R2 is not active in L3. This results the routing black hole in our network because R3 does not know anything about 220.127.116.11 network. This prevents DHCP server to send IP address to DHCP proxy, that has IP address in 18.104.22.168/24 range (f0/0 of R2 is our DHCP proxy device). So what we need is a static route on R3 to make it aware of 22.214.171.124 network.
R3(config)#do sh run | inc route ip route 126.96.36.199 255.255.255.0 188.8.131.52
If there were other routers between R2 and R3, we had to write this static route on all of them too. At final step we need to check the whole process.
R3(config)#do sh ip dhcp bind Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type User name 184.108.40.206 0052.31 Mar 02 2002 12:58 AM Automatic
You see that R3, as our DHCP server, has assigned 220.127.116.11 to a client. And to see if our client has received this IP:
R1(config-if)#do sh ip inter b Interface IP-Address Method Status Protocol FastEthernet0/0 unassigned unset up up Virtual-Access1 unassigned unset up up Virtual-Access2 unassigned unset up up Dialer1 18.104.22.168 IPCP up up Loopback0 22.214.171.124 manual up up
And our very last test:
R1(config-if)#do ping 126.96.36.199 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 188.8.131.52, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/48/92 ms