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-Template1Note 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.6Virtual-Access1 54.1.7.6 YES TFTP up upVirtual-Template1 54.1.7.6 YES manual down downAside 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
interface Virtual-Template1
bandwidth 128
no ip address
ppp multilink
ppp multilink group 1
interface Multilink1
ip unnumbered Loopback0
bandwidth 128
ppp multilink
ppp multilink group 1
ppp multilink interleave
ppp multilink fragment delay 8
service-policy output LLQ
interface Serial1/0
no ip address
encapsulation frame-relay
frame-relay traffic
int Serial1/0.13 point-to-point
frame-relay interface-dlci 103 ppp Virtual-Template1
class FRTS
interface Virtual-Template1
bandwidth 128
no ip address
ppp multilink
ppp multilink group 1
interface Multilink1
ip unnumbered Loopback0
bandwidth 128
ppp multilink
ppp multilink group 1
ppp multilink interleave
ppp multilink fragment delay 8
service-policy output LLQ
interface Serial0/1
no ip address
encapsulation frame-relay
frame-relay traffic
int Serial0/1.13 point-to-point
frame-relay interface-dlci 301 ppp Virtual-Template1
class FRTS
1) Configurare il virtual template
2) Configurare il multilink PPP
3) Associare il virtual-template alla sub-interface frame-relay point-to-point
A qual punto il multilink ed il virtual-Access diventeranno UP/UP
R3#s ip int br
Interface IP-Address OK? Method Status Protocol
Serial0/1 unassigned YES NVRAM up up
Serial0/1.13 unassigned YES unset up up
Multilink1 5.5.3.3 YES TFTP up up
Virtual-Access1 unassigned YES TFTP up up
Virtual-Template1 unassigned YES NVRAM down down
Loopback0 5.5.3.3 YES NVRAM up up
R3#
R1#s ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 5.5.128.97 YES NVRAM up up
Serial1/0 unassigned YES NVRAM up up
Serial1/0.13 unassigned YES unset up up
Multilink1 5.5.1.1 YES TFTP up up
Virtual-Access1 unassigned YES TFTP up up
Virtual-Template1 unassigned YES NVRAM down down
Loopback0 5.5.1.1 YES NVRAM up up
R1#
R3(config)#int Serial0/1.13 point-to-point
R3(config-subif)#frame-relay interface-dlci 301 ppp Virtual-Template1
R3(config-fr-dlci)#
*Mar 1 01:12:26.931: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
*Mar 1 01:12:27.067: %FR-3-MLPOFR_ERROR: MLPoFR not configured properly on Link Virtual-Access2 Bundle Multilink1 :Frame Relay traffic shaping must be enabled
*Mar 1 01:12:27.099: %LINK-3-UPDOWN: Interface Multilink1, changed state to up
*Mar 1 01:12:28.063: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
*Mar 1 01:12:28.099: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to up
R1(config)#int Serial1/0.13 point-to-point
R1(config-subif)#frame-relay interface-dlci 103 ppp Virtual-Template1
R1(config-fr-dlci)#
*Mar 1 01:13:08.067: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
*Mar 1 01:13:55.567: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 01:15:25.315: %FR-3-MLPOFR_ERROR: MLPoFR not configured properly on Link Virtual-Access2 Bundle Multilink1 :Frame Relay traffic shaping must be enabled
*Mar 1 01:15:25.347: %LINK-3-UPDOWN: Interface Multilink1, changed state to up
*Mar 1 01:15:26.311: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
*Mar 1 01:15:26.439: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to up
Nessun commento:
Posta un commento