Posts Tagged ‘PPP’
PPP Over Ethernet (PPPoE) is one of those topics that is very simple but unless you configure it a lot or practice enough, the nuances can escape you very easily. Currently, PPPoE is on the Service Provider lab blueprint but it has also been added to the v4 Routing and Switching lab blueprint. Here we look at a small scenario and do some debugging to gain some more insight into what exactly is going on. More details can be found in RFC 2516.
Objective
- PPPoE connection between R1 and R2.
- CHAP authentication is to be used.
- R2 should provide R1 an address via DHCP.
Configuration
We will start on R1. A dialer interface is needed and the FastEthernet interface needs to be associated with the same dialer pool. Under the dialer we can configure PPP options such as authentication and how the interface will learn its IP address. PPP commands will not be available until you specify the encapsulation as PPP on the dialer interface,
R1(config)#username R2 password pppoe-lab
R1(config)#int f0/0
R1(config-if)#pppoe-client dial-pool-number 1
R1(config)#int dialer 1
R1(config-if)#dialer-group 1
R1(config-if)#dialer pool 1
R1(config-if)#ppp auth?
% Unrecognized command
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authen chap
R1(config-if)#ip address dhcp
R2, the server in this example, will not use a dialer interface. Instead it uses a virtual-template and bb-group configuration. PPP options are configured under the virtual template, the virtual-template is assigned to the bba-group, and the bba-group is attached to the FastEthernet interface. BBA is an abbreviation for Broadband access.
R2(config)#username R1 password pppoe-lab
R2(config)#ip dhcp pool R1
R2(dhcp-config)#network 192.168.1.0 /24
R2(dhcp-config)#exit
R2(config)#interface virtual-template 1
R2(config-if)#ip address 192.168.1.2 255.255.255.0
R2(config-if)#encap ppp
R2(config-if)#ppp authentication chap
R2(config-if)#exit
R2(config)#bba-group pppoe global
R2(config-bba-group)#virtual-template 1
R2(config-bba-group)#int f0/0
R2(config-if)#pppoe enable group globa
Debugging on R1 gives the following.
R1#debug pppoe events
PPPoE protocol events debugging is on
Aug 3 14:30:35.551: Sending PADI: Interface = FastEthernet0/0
Aug 3 14:30:35.567: PPPoE 0: I PADO R:c201.0bfc.0000 L:c200.0bfc.0000 Fa0/0
Aug 3 14:30:37.599: PPPOE: we’ve got our pado and the pado timer went off
Aug 3 14:30:37.599: OUT PADR from PPPoE Session
Aug 3 14:30:37.615: PPPoE 3: I PADS R:c201.0bfc.0000 L:c200.0bfc.0000 Fa0/0
Aug 3 14:30:37.619: IN PADS from PPPoE Session
Aug 3 14:30:37.631: %DIALER-6-BIND: Interface Vi1 bound to profile Di1
Aug 3 14:30:37.635: PPPoE: Virtual Access interface obtained.
Aug 3 14:30:37.635: PPPoE : encap string prepared
Aug 3 14:30:37.639: [0]PPPoE 3: data path set to Virtual Acess
Aug 3 14:30:37.659: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Aug 3 14:30:41.051: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
Aug 3 14:30:49.175: %DHCP-6-ADDRESS_ASSIGN: Interface Dialer1 assigned DHCP address 192.168.1.3, mask 255.255.255.0, hostname R1
From the above output we can see the process follows the RFC pretty well. The client broadcasts a PPPoE Active Discovery Initiation (PADI) packet to learn of any servers on the network. R2 responds with a unicast PPPoE Active Discovery Offer (PADO). This packet contains a tag that the client uses to associate with the proper request. After receiving the PADO, the client sends a PPPoE Active Discovery Request (PADR) packet, which is unicast top the server. The server responds with a PPPoE Active Discovery Session-confirmation (PADS) packet and PPP negotiation begins.
Here are some verification commands on each device:
R1#sho pppoe session
1 client session
Uniq ID PPPoE RemMAC Port VT VA State
SID LocMAC VA-st
N/A 3 c201.0bfc.0000 Fa0/0 Di1 Vi1 UP
c200.0bfc.0000 UP
R2#sho pppoe session
1 session in LOCALLY_TERMINATED (PTA) State
1 session total
Uniq ID PPPoE RemMAC Port VT VA State
SID LocMAC VA-st
3 3 c200.0bfc.0000 Fa0/0 1 Vi2.1 PTA
c201.0bfc.0000 UP
Some final things to remember
- Configure dialer interface in client
- Dialer interface contains ppp and addressing options
- Ethernet interface must belong to same dialer pool
- Configure virtual-template and bba-group on server
- Virtual-template contains ppp options and IP address
- BBA-group is configured under the Ethernet interface
Frame Relay does not natively support features such as authentication, link quality monitoring, and reliable transmission. Based on this it is sometimes advantageous to encapsulate an additional PPP header between the normal layer 2 Frame Relay encapsulation and the layer 3 protocol. By running PPP over Frame Relay (PPPoFR) we can then implement authentication of Frame Relay PVCs, or even bind multiple PVCs together using PPP Multilink.
PPPoFR is configure in Cisco IOS through the usage of a Virtual-Template interface. A Virtual-Template is a PPP encapsulated interface that is designed to spawn a “template” of configuration down to multiple member interfaces. The traditional usage of this interface has been on dial-in access servers, such as the AS5200, to support multiple PPP dialin clients terminating their connection on a single interface running IP.
The first step in configuring PPPoFR is to create the Virtual-Template interface. This interface is where all logical options, such as IP address and PPP authentication will be configured. The syntax is as follows:
interface Virtual-Template1
ip address 54.1.7.6 255.255.255.0
ppp chap hostname ROUTER6
ppp chap password 0 CISCO
Note the lack of the “encapsulation ppp” command on the Virtual-Template. This command is not needed as a Virtual-Template is always running PPP. This can be seen by looking at the “show interface virtual-template1” output in the IOS. Additionally in this particular case the remote end of this connection will be challenging the router to authenticate via PPP CHAP. The “ppp chap” subcommands have instructed the router to reply with the username ROUTER6 and an MD5 hash value of the PPP magic number and the password CISCO.
Our next step is to configure the physical Frame Relay interface, and to bind the Virtual-Template to the Frame Relay PVC. This is accomplished as follows:
interface Serial0/0
encapsulation frame-relay
frame-relay interface-dlci 201 ppp Virtual-Template1
Note that the “no frame-relay inverse-arp” command is not used on this interface. Since our IP address is located on the Virtual-Template interface the Frame Relay process doesn’t actually see IP running over the link. Instead it simply sees a PPP header being encapsulated on the link, while the IPCP protocol of PPP takes care of all the IP negotiation for us. Note that the order that these steps are performed in is significant. If a Virtual-Template interface is applied to a Frame Relay PVC before it is actually created you may see difficulties with getting the link to become active.
Also when using a Virtual-Template interface it’s important to understand that a Virtual-Access “member” interface is cloned from the Virtual-Template interface when the PPP connection comes up. Therefore the Virtual-Template interface itself will always be in the down/down state. This can affect certain network designs such as using the backup interface command on a Virtual-Template. In our particular case we can see from the below output this effect:
R6#show ip interface brief | include 54.1.7.6
Virtual-Access1 54.1.7.6 YES TFTP up up
Virtual-Template1 54.1.7.6 YES manual down down
Aside from this there is no other configuration that directly relates to Frame Relay for PPP. Other options such as authentication, reliability, and multilink would be configured under the Virtual-Template interface.
Original Article @ http://blog.internetworkexpert.com/2008/01/07/understanding-ppp-over-frame-relay-pppofr/
Refer: http://www.cisco.com/en/US/docs/ios/12_0/dial/configuration/guide/dcvtemp.html
Virtual Templates http://www.cisco.com/en/US/tech/tk713/tk507/technologies_configuration_example09186a0080094333.shtml
CHAP Authentication http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a00800b4131.shtml
If you have two frame relay line between two location and you need these lines to work load balanced this note will guide you. We need two techniques to do it. First one is multilink PPP, which can be use to bundle leased lines. The second one is PPP over Frame Relay, which lets frame relay lines like leased lines.
In my example, I will show how I bundle two 2 Mbps frame relay line to act as one 4 Mbps line.
We have to do below configuration on both sides.
1)We will make an ordinary frame relay configuration on serial interfaces except “frame-relay interface-dlci 16 ppp Virtual-Template1” line. Here we are adding Virtual-Template1. frame-relay traffic-shaping command is a MUST.
2)Under “interface Virtual-Template1“ we describe that it is a part of multilink interface
3)Under “interface Multilink1” we will configure IP settings.
interface Serial0/0
description Physical Interface 1
bandwidth 2000
no ip address
encapsulation frame-relay
frame-relay fragmentation voice-adaptive deactivation 15
frame-relay traffic-shaping
frame-relay interface-dlci 16 ppp Virtual-Template1
frame-relay lmi-type ansi
interface Serial0/1
description Physical Interface 2
bandwidth 2000
no ip address
encapsulation frame-relay
frame-relay fragmentation voice-adaptive deactivation 15
frame-relay traffic-shaping
frame-relay interface-dlci 16 ppp Virtual-Template1
frame-relay lmi-type ansi
interface Virtual-Template1
no ip address
ppp multilink
ppp multilink group 1
interface Multilink1
description Bundled Interface
bandwidth 4000
ip address 10.87.1.1 255.255.255.248
ppp multilink
ppp multilink group 1