blog
    BBA-Group and Dialer Prof ...
    18 March 10

    BBA-Group and Dialer Profiles with PPPoE

    Posted byINE
    facebooktwitterlinkedin
    news-featured

    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.

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo