A huge shout-out to the Reno RS workshop in Reno this week. You guys (Vicki included) rock!!! Thanks for all your hard work, and making it so fun. I am having a blast! One of the students asked about a client configuration for PPPoE. This blog post serves as working example of a client and server configuration. Thanks for the request Louie!
About 10 years ago, when preparing for the CCIE exam, I learned to use dialer profiles with dial on demand routing for use with ISDN. Some things seem to keep hanging on forever. Of course, ISDN has gone the way of the pay-telephone and is no longer on the lab. Dialer groups, however are still alive for use with PPPoE.
Here is the diagram for our configurations, and yes I know it is a complex one
.
Let’s start by creating a PPPoE server out of R1. We’ll name this router server, for ease of verification regarding which device we are looking at during the configuration and verification.
Best wishes,
About 10 years ago, when preparing for the CCIE exam, I learned to use dialer profiles with dial on demand routing for use with ISDN. Some things seem to keep hanging on forever. Of course, ISDN has gone the way of the pay-telephone and is no longer on the lab. Dialer groups, however are still alive for use with PPPoE.
Here is the diagram for our configurations, and yes I know it is a complex one
.Let’s start by creating a PPPoE server out of R1. We’ll name this router server, for ease of verification regarding which device we are looking at during the configuration and verification.
R1(config)#hostname serverLet’s set the interface to it’s default, so there is nothing left to the imagination.
server(config)#default int fa 0/0 Building configuration... Interface FastEthernet0/0 set to default configurationNext we will create a PPPoE group, and associate a virtual template with it.
server(config)#bba-group pppoe GROUPA server(config-bba-group)#virtual-template 1 server(config-bba-group)#exit %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to upBecause we know that we’ll be using PPP, lets set up a local user name and password for the client (also named client).
server(config)#username client password ciscoNext, we will set up a loopback interface in preparation for using ip unnumbered with it, on virtual-template 1 (coming up).
server(config)#int loop 0 server(config-if)#IP address 10.12.0.1 255.255.255.0 %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to upOk, so now lets create the virtual template, and tell it to use the IP address of our loopback 0. We’ll also configure the virtual template to hand out IP addresses from a local pool named POOL1. We will specify that we want to use PPP CHAP authentication, to authenticate the clients who are connecting.
server(config)#interface virtual-template 1 server(config-if)#ip unnumbered loop 0 server(config-if)#peer default ip address pool POOL1 server(config-if)#ppp authentication chap callinIt doesn’t work too well to hand out IP addresses from a pool that doesn’t exist. Lets fix that now by creating the pool we just referred to in the template.
server(config)#IP local pool POOL1 10.12.0.50 10.12.0.254So far, so good. The only problem is that the bba-group we created doesn’t have any physical interfaces to use. Lets chip in and donate Fa0/0 to this cause. Some device has to be used to move the bits.
server(config)#interface f0/0 server(config-if)#pppoe enable group GROUPA server(config-if)#no shutdown %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up server#Thats it now for the server. We will default the client’s Fa0/0 interface (just like we did on the server), so we all know what is going on with the physical interfaces that are involved.
R2(config)#hostname client client(config)#default int fa 0/0 Building configuration... Interface FastEthernet0/0 set to default configurationWe will enable some debugs on the client, so that we can see the play by play action.
client(config)#do debug ppp authentication PPP authentication debugging is on client(config)#do debug ppp negotiation PPP protocol negotiation debugging is on client(config)#do debug pppoe events PPPoE protocol events debugging is on client(config)#Now we can setup Fa0/0 for PPPoE and allocate it to a dialer pool. When a logical dialer interface, (which we will create in a moment), needs to use a physical resource, it can call on the pool number, and then logically be bound to that interface for the duration of the connection. This would also be the case with ISDN and ATM if they were being used. For our example we are using Ethernet.
client(config)#interface f0/0 client(config-if)#pppoe enable client(config-if)#pppoe-client dial-pool-number 1 dial-on-demand client(config-if)#no shutdown %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to upBefore we create a logical dialer interface, we can create a dialer-list. This dialer list can be used to classify which traffic is “interesting”. Interesting traffic, is the traffic deemed worthy enough by the client to trigger calling the PPPoE server to initiate a call/connection. Once a call has been initiated, it will stay up as long as there is interesting traffic. If interesting traffic stops flowing, an idle timer begins a countdown. Every new interesting packet, resets the countdown timer. If/when the idle timer reaches 0, the connection is closed. If any new interesting traffic is seen, and the call/connection is down, the client will initiate a new call/connection to the server. So lets go to work and create the dialer-list first.
client(config)#dialer-list 1 protocol ip permitNow we can create the logical dialer interface (dialer-1), and tell the interface which pool to draw from for a physical resource (pool 1), how many packets to queue while the call is being established (hold-queue), what the interesting traffic list is (dialer-group 1), and select the value, in seconds, the idle-timer should use, including which direction to check for the interesting traffic.
client(config)#interface dialer1 client(config-if)# dialer pool 1 client(config-if)# dialer hold-queue 10 client(config-if)# dialer-group 1 client(config-if)# dialer idle-timeout 30 eitherNext we can assign the encapsulation of PPP, and tell the client to get an IP address for the dialer interface by using PPP negotiations with the server.
client(config-if)# encapsulation ppp client(config-if)# ip address negotiatedPPPoE adds a whopping 8 bytes of header, so we may want to reduce the MTU on the dialer interface by that amount to avoid unnecessary fragmentation. We can also set the password that this client will use to authenticate with the server.
client(config-if)# mtu 1492 client(config-if)# ppp chap password ciscoSo, what is left? How about a reason for the client to try to use the Dialer interface. If the client router has no motivation to move traffic through the interface, the interesting traffic will not be present, and as a result, no call/connection will be made. A default route, using the dialer interface will do the trick.
client(config)#ip route 0.0.0.0 0.0.0.0 dialer 1Lets do a pre-flight check to see what IP addresses are currently in use.
client#show ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES TFTP up up
Virtual-Access1 unassigned YES unset up up
Dialer1 unassigned YES manual up up
client#show pppoe session
1 client session
Uniq ID PPPoE RemMAC Port VT VA State
SID LocMAC VA-st
N/A 0 0000.0000.0000 Fa0/0 Di1 N/A SHUTDOWN
0000.0000.0000PPPoE has a discovery stage and a PPP session setup stage. With discovery it will identify the MAC address of the server adn establish a PPPoE SESSION_ID. We will be able so see this in the debugs. Ok, so lets send some IP traffic. This will match the dialer-list we created and assigned to the dialer interface, which should trigger the PPPoE connection and authentication to the server. We will let it come up, wait 30 seconds, and then watch it close the connection due to no interesting traffic being seen. All with the debug running.client#ping 10.12.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.12.0.1, timeout is 2 seconds: ! Note: PADI/O is PPPoE Active Discovery Initiation/Offer ! Note: "I" means inbound, and "O" means outbound Sending PADI: Interface = FastEthernet0/0 PPPoE 0: I PADO R:c202.0129.0000 L:c203.0129.0000 Fa0/0. PPPOE: we've got our pado and the pado timer went off OUT PADR from PPPoE Session ! Note: PADS is the PPPoE Active Discovery Session-confirmation packet. ! Note: Mac addresses are very similar between the two routers as this was done on dynamips. PPPoE 1: I PADS R:c202.0129.0000 L:c203.0129.0000 Fa0/0 IN PADS from PPPoE Session %DIALER-6-BIND: Interface Vi2 bound to profile Di1 PPPoE: Virtual Access interface obtained. PPPoE : encap string prepared [0]PPPoE 1: data path set to Virtual Acess ! Note: PPP Negotiation has several phases including DOWN, ESTABLISHING, AUTHENTICATING, UP and TERMINATING. Vi2 PPP: Phase is DOWN, Setup Vi2 PPP: Using dialer call direction Vi2 PPP: Treating connection as a callout Vi2 PPP: Session handle[47000004] Session id[0] Vi2 PPP: Phase is ESTABLISHING, Active Open Vi2 PPP: Authorization required Vi2 PPP: No remote authentication for call-out ! Note: LCP = Link Control Protocol, NCP = Network Control Protocol used for negotiating L3 protocols. Vi2 LCP: O CONFREQ [Closed] id 1 len 14 Vi2 LCP: MRU 1492 (0x010405D4) Vi2 LCP: MagicNumber 0x0332E5E3 (0x05060332E5E3) %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up ! Note: Below, the server is negotiating for the option of CHAP authentication. Vi2 LCP: I CONFREQ [REQsent] id 1 len 19 Vi2 LCP: MRU 1492 (0x010405D4) Vi2 LCP: AuthProto CHAP (0x0305C22305) Vi2 LCP: MagicNumber 0x0232E6FE (0x05060232E6FE) ! Note: Below, the client is saying OK to CHAP, otherwise it would show CONFNAK. Vi2 LCP: O CONFACK [REQsent] id 1 len 19 Vi2 LCP: MRU 1492 (0x010405D4) Vi2 LCP: AuthProto CHAP (0x0305C22305) Vi2 LCP: MagicNumber 0x0232E6FE (0x05060232E6FE) Vi2 LCP: I CONFACK [ACKsent] id 1 len 14 Vi2 LCP: MRU 1492 (0x010405D4) Vi2 LCP: MagicNumber 0x0332E5E3 (0x05060332E5E3) Vi2 LCP: State is Open ! Note: Now we move on to the authentication using the negotiated CHAP. ! Note: Below, note that the authenticating is done only by the peer, the server in this case. Otherwise it would say "both". Vi2 PPP: No authorization without authentication Vi2 PPP: Phase is AUTHENTICATING, by the peer Vi2 CHAP: I CHALLENGE id 1 len 27 from "server" Vi2 CHAP: Using hostname from unknown source Vi2 CHAP: Using password from interface CHAP Vi2 CHAP: O RESPONSE id 1 len 27 from "client" Vi2 CHAP: I SUCCESS id 1 len 4 ! Note: CHAP was successful! Next we will let the server know we don't have an address and ask for one. Vi2 PPP: Phase is FORWARDING, Attempting Forward Vi2 PPP: Queue IPCP code[1] id[1] Vi2 PPP SSS: Receive SSS-Mgr Connect-Local Vi2 PPP: Phase is ESTABLISHING, Finish LCP Vi2 PPP: Phase is UP Vi2 IPCP: O CONFREQ [Closed] id 1 len 10 Vi2 IPCP: Address 0.0.0.0 (0x030600000000) Vi2 CDPCP: O CONFREQ [Closed] id 1 len 4 Vi2 PPP: Process pending Vi2 IPCP: Redirect packet to Vi2 Vi2 IPCP: I CONFREQ [REQsent] id 1 len 10 Vi2 IPCP: Address 10.12.0.1 (0x03060A0C0001) Vi2 IPCP: O CONFACK [REQsent] id 1 len 10 Vi2 IPCP: Address 10.12.0.1 (0x03060A0C0001) Vi2 IPCP: I CONFNAK [ACKsent] id 1 len 10 Vi2 IPCP: Address 10.12.0.50 (0x03060A0C0032) Vi2 IPCP: O CONFREQ [ACKsent] id 2 len 10 Vi2 IPCP: Address 10.12.0.50 (0x03060A0C0032) ! Note: It looks like the servers is "Just Saying NO" to CDP with the PROTREJ below. Vi2 LCP: I PROTREJ [Open] id 2 len 10 protocol CDPCP (0x820701010004) Vi2 CDPCP: State is Closed Vi2 CDPCP: State is Listen Vi2 IPCP: I CONFACK [ACKsent] id 2 len 10 Vi2 IPCP: Address 10.12.0.50 (0x03060A0C0032) Vi2 IPCP: State is Open Di1 IPCP: Install negotiated IP interface address 10.12.0.50 Di1 IPCP: Install route to 10.12.0.1 Vi2 IPCP: Add link info for cef entry 10.12.0.1 %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up client# ! 30 seconds later, with no interesting traffic the idle time reaches 0 and the following happens: client# Vi2 PPP: Sending Acct Event[Down] id[3] PPPoE : Shutting down client session ! Note: PADT is the PPPoE Active Discovery Terminate packet. [0]PPPoE 1: O PADT R:c202.0129.0000 L:c203.0129.0000 Fa0/0 Vi2 IPCP: Remove link info for cef entry 10.12.0.1 %DIALER-6-UNBIND: Interface Vi2 unbound from profile Di1 Vi2 PPP: Block vaccess from being freed [0x10] Di1 IPCP: Remove route to 10.12.0.1 %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down client# Vi2 CDPCP: State is Closed Vi2 IPCP: State is Closed Vi2 PPP: Unlocked by [0x10] Still Locked by [0x2] Vi2 PPP: Phase is TERMINATINGVi2 LCP: State is Closed Vi2 PPP: Phase is DOWN Vi2 PPP SSS: Send DISCONNECT to mgr_hdl[DE000001] Vi2 PPP: Unlocked by [0x2] Still Locked by [0x0] Vi2 PPP: Free previously blocked vaccess client# %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down client#Now with the debug off, lets bring it up again, and use a few commands to show the status and verify the connection is actually working.
client#un all
All possible debugging has been turned off
client#ping 10.12.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.12.0.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 8/28/68 ms
client#
%DIALER-6-BIND: Interface Vi2 bound to profile Di1
client#
%LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
client#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
client#show ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES TFTP up up
Serial0/0 unassigned YES NVRAM up up
Serial0/0.1 10.23.0.2 YES NVRAM up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
Serial0/1 unassigned YES NVRAM up down
Virtual-Access1 unassigned YES unset up up
Virtual-Access2 unassigned YES unset up up
Dialer1 10.12.0.50 YES IPCP up up
client#show pppoe session all
Total PPPoE sessions 1
session id: 2
local MAC address: c203.0129.0000, remote MAC address: c202.0129.0000
virtual access interface: Vi2, outgoing interface: Fa0/0
36 packets sent, 35 received
1404 bytes sent, 1122 received
client#show pppoe session packets
Total PPPoE sessions 1
SID Pkts-In Pkts-Out Bytes-In Bytes-Out
2 37 38 1150 1432
client#show pppoe session
1 client session
Uniq ID PPPoE RemMAC Port VT VA State
SID LocMAC VA-st
N/A 2 c202.0129.0000 Fa0/0 Di1 Vi2 UP
c203.0129.0000 UPI enjoyed the demo, and hope this will assist you on your path to CCIE.Best wishes,
0 comments:
Post a Comment