Mar
18

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 :) .

BBA-Group Server R1 and PPPoE Client R2.

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 server

Let’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 configuration

Next 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 up

Because 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 cisco

Next, 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 up

Ok, 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 callin

It 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.254

So 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 configuration

We 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 up

Before 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 permit

Now 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 either

Next 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 negotiated

PPPoE 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 cisco

So, 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 1

Lets 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.0000

PPPoE 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 TERMINATING Vi2 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 UP

I enjoyed the demo, and hope this will assist you on your path to CCIE.

Best wishes.

To open a connection to the peer, the device transmits this message along with the configuration options and values the sender wishes the peer to support. All options and values are negotiated simultaneously. If the peer responds with a CONFREJ or CONFNAK message, then the router sends another CONFREQ with another set of options or values.

You can leave a response, or trackback from your own site.

16 Responses to “BBA-Group and Dialer Profiles with PPPoE”

 
  1. Smail says:

    Really good explained and the topo is really complex :)

  2. Ian Finlayson says:

    Thanks for that! Nice coverage!! Could you PLEASE do a Blog or an article about MTU and how it can affect packets flowing in an end-to-end fashion!!

    Marvin touched on it a little when he did the PPPoE ATCoD, he rang a ping of a certain size and it passed through no probs, then when he went over a certain size the packets failed! But when he adjusted the MTU, any size seemed to pass fine!??

    Could someone please do a short Blog (or a long one :) ) on MTU and the effects is can have on end-to-end communications!

    Cheers,
    Ian.

  3. 2beone says:

    this is real cool. keep on going, especially with the atcod!!

  4. kirk says:

    Awesome. Thank you very much.
    By the way, I equally appreciated your “Ip tcp Intercept Class on Demand”, as well.

  5. Ian Anderson says:

    Thanks for this excellent blog. A couple of questions if I may…

    1.) Why do you not set the mtu size on the server as I guess this is also running PPPoE

    2.) How do you navigate to relevant documention on CCO as I believe it doesn’t sit with the rest of the 12.4T config guides.

    Thanks Ian

  6. Amit says:

    Excellent post !! You guys truly rock !!

  7. Amit says:

    Hi,

    My question is why do we need the dialer-list and hence dialer-group commands? I have found that when the Client is configured for PPPoE, it immediately starts sending PADI packets and so the PPP session will be set up after two PPPoE stages.

    Can you please explain?

    Thanks.
    Amit.

  8. Hi Amit-

    A PPPoE configuration without dialer-x commands could have been used. There are many different options. I felt it would serve the readers to see the dialer-x commands in the event was a person or two wasn’t familiar with the technology.

    Thanks for your comments, and happy studies!

  9. Garth says:

    Hi,

    Thanks for the article it was great! I have a query regarding the benefits of using ip unnumbered referencing a loopbakc instead of entering the IP address just on the Virtual Interface?

    This is something that confuses me a lot because I see it being done a lot but dont understand why. I’ve used PPPoE with the IP on the Virtual-Template and it does work just fine so i’m wondering the benefits and restrictions doing it the two ways and how it would affect me on the CCIE Examination?

    Cheers,

    Garth

  10. Kamran says:

    Hi, I am able to establish the PPPOE connection, but non of us can access the internet. My question is how do we configure the LAN interface of the router? Do we need to do natting? If you can provide that configuration as well.

    Also if we want to have multiple PPPOE conection how do we achive that.

    Regards

    Kamran

  11. NET_OG says:

    I have a recommendation, for INE. When creating online blogs or posts, why not include a link to the documentation that was used to prepare the article? So many places to look it would be nice to try and find it and if un-successful, reference the article’s source/reference material.

    http://www.cisco.com/en/US/docs/ios/bbdsl/configuration/guide/bba_pppoe_baa_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1089269

    I always seem to forget where PPPoE is, first I look in VPDN, then WAN, then Dial Technologies and then finally I use the master index and get reminded that it is the only section that R&S Blueprint uses from BroadBand Access section.

    This article is on my Evernote so I usually end up reviewing it as well. Once you post this, it will be in the article!

    NET_OG

  12. ATenorio says:

    Hi,

    Some interesting points to note:
    !
    If the client has dial-on-demand as a starting point, without the default route the negotiation does not proceed! Without dial-on-demand there is no need of such default route.
    !
    Also, people should be aware of type of address negotiation by the dialer´s client interface:
    ip address negotiated –> ip local pool on the server
    ip address dhcp –> ip dhcp pool on the server
    Quite obvious this one, but …
    !

  13. Jay says:

    Would the Dialer load-threshold cmd be applicable here also?

    Thankyou for the Great Article.

  14. BBT says:

    nice stuff was practicing the lab but I realised that to do the ping you at least need and IP address configured on the client. When I first tried to ping it was saying unrecognised host or address or protocol. I do not know whether it is due to the ios version I was using or not but on putting a loopback address on the client side I was able to ping and get IP from the server side!!! Any reason for this behavior ?

 

Leave a Reply

Categories

CCIE Bloggers