frame-relay: back to back connections between routers

Today we have a simple scenario but with one small pitfall. We well establish a connection between two routers via frame-relay that are connected back to back.

Here is the topology:

Goal:
– establish back to back connection and IP reachability

So lets begin. The first step here is to bring up the interfaces and the line-protocol, well sounds easy lets try it.

R1(config)#int s0/0
R1(config-if)#no shut
R1(config-if)#encapsulation frame-relay
R1(config-if)#ip address 172.16.21.1 255.255.255.0

R2(config)#int s0/0
R2(config-if)#no shut
R2(config-if)#encapsulation frame-relay
R2(config-if)#ip address 172.16.21.2 255.255.255.0


But against our expectations the line protocol is down (it shortly comes up but goes down after a while).


R1#sh ip int brief | inc Serial0/0
Serial0/0 172.16.21.1 YES manual up down

R2#sh ip int brief | inc Serial0/0
Serial0/0 172.16.21.2 YES manual up down


Strange….okay lets see what we can do. As it is a back 2 back connection we need one of the routers to be the “master” for giving the clock rate. Lets use R2 as the clock-rate source.


R2(config)#int s0/0
R2(config-if)#clock rate 2000000

R2#sh ip int brief | inc Serial0/0
Serial0/0 172.16.21.2 YES manual up down


Still down. Hmm okay…next thing we have on our ammo belt is the keepalive command. Usually the Router expects to send and receive keepalives via LMI but as there is no LMI there are no keepalives which has the effect that the interfaces stay down. Lets disable the keepalive mechanism on the Routers.


R1(config)#int s0/0
R1(config-if)#no keepalive
R1(config-if)#
*Mar 1 00:53:27.639: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up

R2(config)#int s0/0
R2(config-if)#no keepalive
R2(config-if)#
*Mar 1 00:53:38.179: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up


Looks a lot better now.

A different way to let the intefaces come up is this one. There are DTE and DCE interface-types out there and usually when connecting routers to ISP equipment, the ISP equipment is DCE. We will make R1 the DTE and R2 the DCE.


R1(config-if)#frame-relay intf-type dte

R2(config-if)#frame-relay intf-type dce
Must enable frame-relay switching to configure DCE/NNI


NOTE:
To be DCE interface the router here says that we need to enable the global command “frame-relay switching”.


R2(config-if)#frame-relay switching
R2(config)#int s0/0
R2(config-if)#frame-relay intf-type dce

*Mar 1 00:46:02.883: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up


We will continue using the standard “no keepalive” variant.
Next thing we need to do is to enable L2 and L3 connectivity. Lets start with L2. Hmm wait a second…usually we have DLCIs set from the provider which we can use in each segment e.g. from R1 to the Frame-Relay-Switch, the DLCI 102 can be used and from R2 to the FRS the DLCI 201 can be used. But we dont have one and also we have only one segment, the segment between R1 and R2. We can simply use the same DLCI on both machines. Lets use The DLCI 102 on both sides.


R1(config-if)#frame-relay interface-dlci 102

R2(config-if)#frame-relay interface-dlci 102


If the DLCIs are working we maybe should already have inverse-arp states in our table. Frame-Relay inverse-arp learns IP addresses from DLCIs that got learned via LMI. As we dont have LMI in use in our scenario, inverse ARP only learns addresses for the DLCI configured on the interface (102).


R1#sh frame map
Serial0/0 (up): ip 172.16.21.2 dlci 102(0x66,0x1860), dynamic,
broadcast,

R2#sh frame map
Serial0/0 (up): ip 172.16.21.1 dlci 102(0x66,0x1860), dynamic,
broadcast,


Ok we have the entries, lets check if we have unicast, multicast and broadcast communication running.

Unicast:
Simply use ping for that.


R2#ping 172.16.21.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.21.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/28/56 ms


WORKS!

Broadcast:
I use RIP Version 1 for that because RIPv1 does not support multicast it only supports broadcast.


R1(config)#router rip
R1(config-router)#network 172.16.21.0

R2(config)#router rip
R2(config-router)#network 172.16.21.0


R1 is sending out 255.255.255.255


R1#
*Mar 1 01:02:30.979: RIP: received v1 update from 172.16.21.2 on Serial0/0
*Mar 1 01:02:30.979: 172.16.21.0 in 1 hops
R1#
*Mar 1 01:02:53.359: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (172.16.21.1)
*Mar 1 01:02:53.359: RIP: build update entries
*Mar 1 01:02:53.363: subnet 172.16.21.0 metric 1


And R2 is receiving it.


R2#
*Mar 1 01:03:21.975: RIP: received v1 update from 172.16.21.1 on Serial0/0
*Mar 1 01:03:21.979: 172.16.21.0 in 1 hops


WORKS!

Multicast:
We just need to migrate to RIPv2 here and then the multicast address 224.0.0.9 is used for the communication between the RIP neighbors.


R1(config-router)#version 2

R2(config-router)#version 2


R1 sends updates via Multicast:


R1(config-router)#
*Mar 1 01:04:20.011: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (172.16.21.1)
*Mar 1 01:04:20.011: RIP: build update entries
*Mar 1 01:04:20.011: 172.16.21.0/24 via 0.0.0.0, metric 1, tag 0


R2 gets them.


R2(config-router)#
*Mar 1 01:04:20.043: RIP: received v2 update from 172.16.21.1 on Serial0/0
*Mar 1 01:04:20.043: 172.16.21.0/24 via 0.0.0.0 in 1 hops


WORKS!

Feel free to comment!
Regards!