Routing over frame-relay is pretty straightforward. Once you work out the differences between point to point and point to multipoint you’re pretty much set.
But what happens when you get to the lab and they require you to switch over frame-relay? Or have a point-to-point link through another router, but not running frame-relay switching? Or what about back to back frame-relay where no frame-relay switch is involved?
All of the above are actually not difficult, as long as you configure them each as least once.
Consider the following simply topology:
The task we’ve been given is for R1 to be a frame-relay switch. R2 and R3 need to communicate over a point to point link. The DLCI for R2 will be 203 and the DLCI for R3 will be 302. Let’s first configure R2 and R3 as a basic point-to-point:
R2#sh run | sec Serial0/0 interface Serial0/0 no ip address encapsulation frame-relay no frame-relay inverse-arp interface Serial0/0.203 point-to-point ip address 10.23.23.2 255.255.255.0 frame-relay interface-dlci 203
R3#sh run | sec Serial0/0 interface Serial0/0 no ip address encapsulation frame-relay no frame-relay inverse-arp interface Serial0/0.302 point-to-point ip address 10.23.23.3 255.255.255.0 frame-relay interface-dlci 302
At this point, let’s have a look at the PVCs from R2′s perspective:
R2#show frame pvc | include DLCI DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/0.203
Remember DELETED means that the frame-switch has no idea about the DLCI that R2 is talking about. So let’s now configure R1 as a frame-relay switch. It’s a 3 step process. Tell the device it’s going to be a frame-relay switch. Tell the router which interfaces are going to be DCEs. And finally tell the router which DLCIs are going to be switched from one interface to another.
frame-relay switching ! interface Serial0/0 no ip address encapsulation frame-relay clock rate 128000 frame-relay intf-type dce frame-relay route 203 interface Serial0/1 302 ! interface Serial0/1 no ip address encapsulation frame-relay clock rate 128000 frame-relay intf-type dce frame-relay route 302 interface Serial0/0 203
Let’s take a look at R2 again:
R2#show frame pvc | include DLCI DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.203 R2#ping 10.23.23.3 repeat 100 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 10.23.23.3, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 1/11/132 ms
To quickly see what routes are configured on the frame-switch, just do this:
R1#show frame-relay route Input Intf Input Dlci Output Intf Output Dlci Status Serial0/0 203 Serial0/1 302 active Serial0/1 302 Serial0/0 203 active
You can of course have multiple map statements referencing different DLCIs under each DCE interface like you would expect!
Now let’s change the topology:
This time they want to run OSPF between R2 and R3. They want the OSPF network type to be broadcast. These broadcasts need to go through R1, but R1 is NOT a frame-relay switch this time. To make sure we don’t somehow bounce things of R1′s IP address, we’ll configure a /31 between R2 and R3. Essentially we’ll be bridging through R1′s frame-relay interfaces.
Let’s create the bridge-group on R2 first. R3′s will almost match, just the DLCI and IP will change:
bridge irb ! interface Serial0/0 no ip address encapsulation frame-relay frame-relay map bridge 201 broadcast bridge-group 1 ! interface BVI1 ip address 10.23.23.2 255.255.255.254 ip ospf network broadcast ip ospf 1 area 0 ! bridge 1 protocol ieee bridge 1 route ip
The important part to notice about this is the frame-relay map bridge command. As noted above, the config on R3 is pretty identical. This is R1′s config:
bridge irb ! interface Serial0/0 no ip address encapsulation frame-relay frame-relay map bridge 102 broadcast frame-relay interface-dlci 102 bridge-group 1 ! interface Serial0/1 no ip address encapsulation frame-relay frame-relay map bridge 103 broadcast frame-relay interface-dlci 103 bridge-group 1 ! bridge 1 protocol ieee
Does it all work?
R2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.23.23.3 1 FULL/DR 00:00:32 10.23.23.3 BVI1 R2#ping 10.23.23.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.23.23.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 132/152/192 ms
Let’s move onto the last topic, back to back frame-relay. You have the following topology:
The tasks states that you need to run frame-relay, but there is no frame-relay switch involved. We don’t even get DLCI numbers on the diagram.
For back-to-back frame-relay to work we essentially turn off our keepalives. The keepalives will be looking for the LMI messages which simply don’t exist. We then hard code the DLCI number on both sides. These DLCI numbers need to MATCH however.
Let’s configure it up:
interface Serial0/0 ip address 10.23.23.3 255.255.255.0 encapsulation frame-relay no keepalive clock rate 2000000 frame-relay map ip 10.23.23.2 100 no frame-relay inverse-arp R1#ping 10.23.23.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.23.23.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/28/72 ms R1#show frame pvc | include DLCI DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = STATIC, INTERFACE = Serial0/0
You can see the PVC is static, and communication is working just fine.
- LMI runs between the router and the FR switch.
- Cisco LMI is supported by other vendors
- 3 types, but autosensed by default
- Router gets DLCI’s via LMI. ACTIVE is good, INACTIVE means local link to FR switch is good, but a problem further on, DELETED means the switch is trying to use a DLCI which the FR switch does not have
- May need to disable split-horizon for EIGRP/RIP
- Will need frame maps if inverse-arp is off
- Will need DLCI configured on the subinterface
- No frame-maps needed
- Requires frame map or frame-relay interface-dlci
- May need to disable split-horizon for EIGRP/RIP
Back to back frame-relay:
- Switch off LMI by issuing the no keepalive interface command
- DLCIs must match (i.e. if using 701 on one side, need 701 on other side)
- Can still run subinterfaces
Frame-relay multilink (FRF.16):
- Uses mfr interface. All layer3 config, including frame-maps will be configured on the mfr interface. Can use mfr subinterfaces as well
- Interface mfr 1
- ip address x.x.x.x x.x.x.x
- Tie physical interfaces into the mfr interface
- Interface Serial0/0
- encapsulation frame-relay mfr 1
- show frame-relay multilink
PPP over FR:
- Uses virtual-template. All layer3 config will be configured on the virtual-template interface.
- PPP is needed when you need to run multiple point-to-point links over a physical interface
- Can be used for authentication
- Interface virtual-template 1
- ip address x.x.x.x x.x.x.x
- ppp authentication (x)
- Interface Se0/0.1 point-to-point
- frame-relay interface-dlci 101 ppp virtual-template 1
- Interface Se0/1
- Frame-relay interface-dlci 102 ppp virtual-template 2
- Keepalives are from local router to FR switch only, so no end to end keepalive by default
- Can run E2E keepalive with map-class
- Create map-class specifying EEK, then apply map-class to interface
- map-class frame-relay EEK
- frame-relay end-to-end keepalive mode (x)
- Interface Se0/0
- frame-relay class EEK
- show frame pvc will show you if the EEK is up or not
- frame-relay maps (xxx) (xxx) ietf – The ietf option is the industry-standard option
- Can mix and match. So on a single interface you can use the physical interface, P2P subinterface and a P2MP subinterface at the same time
- To bridge over frame-relay, you need the frame-relay map bridge (dlci) broadcast command, as well as the regular bridging commands
- sh frame PVC | include ACT
- sh frame map