Frame Relay – Securing PVC’s using CHAP authentication

This is one of those questions that really gets you thinking because by default, Frame Relay doesn’t support authentication. So let’s say you are tasked with configuring CHAP authentication between your PVC’s, how are you going to do it?

PPPoFR or Point-to-Point Protocol over Frame Relay will allow you establish end-to-end PPP sessions over your Frame Relay network. You should remember that by default PPP does support CHAP authentication natively, we learned this back in the CCNA days :)

PPPoFR requires you to configure what’s called a virtual-template interface. Once you grasp the concepts of virtual interfaces configuring PPPoFR really isn’t that difficult.

Here is an example topology and configuration tasks for CHAP authentication using PPPoFR.

Task 1.1

Secure the PVC between R2 and R5 using CHAP authentication and a password of ccie


R2

username R5 password ccie

interface virtual-template 1
ip address 10.186.2.2 255.255.255.0
ppp authentication chap

interface serial 0/0
encapsulation frame-relay
frame-relay interface-dlci 215 ppp virtual-template 1

do debug ppp authentication

R5

username R2 password ccie

interface virtual-template 1
ip address 10.186.2.5 255.255.255.0
ppp authentication chap

interface serial 0/0
encapsulation frame-relay
frame-relay interface-dlci 512 ppp virtual-template 1


As you can see on R2 I enabled debugging so we can see that everything is working, here is the output from the debug

*Mar 1 00:51:42.515: Vi2 PPP: Authorization required
*Mar 1 00:52:00.743: Vi2 CHAP: O CHALLENGE id 1 len 23 from "R2"
*Mar 1 00:52:00.747: Vi2 CHAP: I CHALLENGE id 1 len 23 from "R5"
*Mar 1 00:52:00.867: Vi2 CHAP: Using hostname from unknown source
*Mar 1 00:52:00.867: Vi2 CHAP: Using password from AAA
*Mar 1 00:52:00.871: Vi2 CHAP: O RESPONSE id 1 len 23 from "R2"
*Mar 1 00:52:01.011: Vi2 CHAP: I RESPONSE id 1 len 23 from "R5"
*Mar 1 00:52:01.015: Vi2 CHAP: I SUCCESS id 1 len 4
*Mar 1 00:52:01.031: Vi2 PPP: Sent CHAP LOGIN Request
*Mar 1 00:52:01.043: Vi2 PPP: Received LOGIN Response PASS
*Mar 1 00:52:01.055: Vi2 PPP: Sent LCP AUTHOR Request
*Mar 1 00:52:01.063: Vi2 PPP: Sent IPCP AUTHOR Request
*Mar 1 00:52:01.079: Vi2 LCP: Received AAA AUTHOR Response PASS
*Mar 1 00:52:01.083: Vi2 IPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:52:01.087: Vi2 CHAP: O SUCCESS id 1 len 4
*Mar 1 00:52:01.327: Vi2 PPP: Sent IPCP AUTHOR Request

So now we have accomplished the task of securing Frame Relay using CHAP authentication.

Frame Relay between Cisco and non-Cisco routers

When configuring Frame Relay there are lots of things that could be asked of you. Imagine a scenario where you are tasked with configuring FR to interact with non-Cisco routers, what do you do?

The first thing some people would think of is LMI, however this probably isn't correct. If you think about it LMI is only locally significant and the routers on either end have no need to match on LMI. Remember that your LMI needs to match the LMI on the Frame Relay switch, that's it.

In the following topology [R1-s0/0---s0/0-FrameSwitch-s0/1---s0/0-R2] the FR switch could be configured so that s0/0 to R1 uses an LMI type of cisco, while the s0/1 to R2 uses q933a. This is a perfectly valid configuration and has no impact on the communication between R1 & R2. If the LMI type doesn't matter, what do we need to change in order to get this to work?

On Cisco routers the default frame-relay encapsulation type is "cisco". If you are running a Cisco router on one end, and a non-Cisco router on the other end, an encapsulation type of "cisco" just wont work. To resolve this issue all you need to do is change the encapsulation type from cisco to ietf. You can configure ietf encapsulation on a per-interface or a per PVC basis as follows

Interface configuration



Interface (interface-dlci)



and finally ietf using frame-relay maps



Remember, when you get stuck the Cisco DocCD is your friend :)