Thursday, May 28, 2009

When to use a Virtual Template???

I was working through my Frame Relay Labs, and did not have a good understanding of why/ or when we need to use Virtual Templates. I found this excerpt on Safari Books and I think it did a good job of explaining the technology/RFC.


RFC 1973 defines the standard for running the Point-to-Point Protocol (PPP) standard over a Frame Relay PVC. Normally you wouldn't want to do this, as the default Frame Relay encapsulation standards discussed in Recipe 10.1 are more than adequate for most situations. However, a PVC that is delivered via a Frame Relay circuit at one location may be converted to an ATM VC inside the carrier's cloud, and could ultimately arrive at another location as a DSL circuit delivered through an Ethernet interface. The only Layer 2 frame format that supports all of these standards is PPP. It is for these types of situations that RFC 1973 was developed.

One of the side benefits of using PPP encapsulation on a Frame Relay PVC like this is you can enforce an extra measure of security by requiring PPP CHAP authentication:

Router1(config)#username Router2 password cookbook
Router1(config)#interface Virtual-Template1
Router1(config-if)#ip unnumbered Loopback1
Router1(config-if)#encapsulation ppp
Router1(config-if)#ppp authentication chap


Naturally, the authentication method and password must match on the other router:

Router2(config)#username Router1 password cookbook
Router2(config)#interface Virtual-Template1
Router2(config-if)#ip unnumbered Loopback1
Router2(config-if)#encapsulation ppp
Router2(config-if)#ppp authentication chap


When you do this, the Virtual-Access interfaces remain in a down state until the routers pass PPP authentication. Since the IP address information is not exchanged until the PPP session is established, it is not possible to use Inverse ARP to deduce a good IP address and insert a rogue router into the network. We note, however, that this type of attack is only possible if you don't control the physical security of the router at the remote site.

Finally, we note in passing that we always create a Loopback interface to carry the IP addresses for Virtual-Template interfaces. In this particular example, because we must use separate IP addressing on every PVC, this is not actually necessary. We could have assigned the IP address directly to the Virtual-Template interface. However, we do it this way because Virtual-Template interfaces are also used for other purposes such as dial backup and PPP over ATM. In some cases, you may want to have more than one type of Virtual-Template configuration, but with the same IP addressing. So because of these situations, it is a good general practice to put the IP address on a Loopback interface, as we have done here.

Excerpt taken from Cisco IOS Cookbook, 2nd Edition

No comments:

Post a Comment