Frame Relay Switching
Posted by Alex Juncu
Frame Relay is still very much a popular subject in exams, labs and in the real networks.
Any lab with topologies that run different protocols over FR must start with the layer 2 configuration of the Frame Relay switched network. FR Topologies like full mesh or hub and spoke require a Frame Relay Switch. A FR Switch is a normal router but specifically configured to do Frame Relay switching.
First of all, we need to tell the router to start switching Frame Relay traffic. From global configuration mode we need to issue the frame-relay switching command.
Then, on the interfaces to Frame Relay clients, we need to start sending keepalives (LMIs) by configuring the interface as DCE with the frame-relay intf-type dce command.
The last thing that the FR Switch needs to do is to route DLCI on the virtual cicuits. This is done to tell an interface where to put a received frame with a DLCI. The frame will be put on another interface with another DLCI. The configuration is done per interface with the frame-relay route command. The command requires that you specify the incoming DLCI, on which the switching decision will be maide, the outgoing interface, and the DLCI with which the frame will be sent (”freame-relay route IN_DLCI OUT_INT OUT_DLCI”).
If Inverse ARP is not disabled on the FR Switch, no DLCI-IP mappings will be required.
Topology:

Configuration:
R1(config)#int s0/0
R1(config-if)#no shut
R1(config-if)#encapsulation frame-relay
R1(config-if)#clock rate 128000
R1(config-if)#ip address 10.1.2.1 255.255.255.0
R2(config)#int s0/0
R2(config-if)#no shut
R2(config-if)#encapsulation frame-relay
R2(config-if)#clock rate 128000
R2(config-if)#ip address 10.1.2.2 255.255.255.0
FR-Sw(config)#frame-relay switching
FR-Sw(config)#int s0/1
FR-Sw(config-if)#no shut
FR-Sw(config-if)#clock rate 128000
FR-Sw(config-if)#encapsulation frame-relay
FR-Sw(config-if)#frame-relay intf-type dce
FR-Sw(config-if)#frame-relay route 102 interface s0/0 201
FR-Sw(config-if)#int s0/0
FR-Sw(config-if)#no shut
FR-Sw(config-if)#clock rate 128000
FR-Sw(config-if)#encapsulation frame-relay
FR-Sw(config-if)#frame-relay intf-type dce
FR-Sw(config-if)#frame-relay route 201 interface s0/1 102
Running Configurations:
R1:
interface Serial0/0
ip address 10.1.2.1 255.255.255.0
encapsulation frame-relay
clockrate 128000
no fair-queue
end
R2:
interface Serial0/0
ip address 10.1.2.2 255.255.255.0
encapsulation frame-relay
clockrate 128000
no fair-queue
end
FR-Sw:
interface Serial0/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay intf-type dce
frame-relay route 201 interface Serial0/1 102
end
interface Serial0/1
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 102 interface Serial0/0 201
end
Back-to-back Frame Relay
Posted by Alex Juncu
This is the simplest use of a Frame Relay encapsulation and it’s between two routers, without a Frame Relay Switch. PPP or HDLC would make more sense to use in these types of links, but it is useful in labs.
In a back-to-back scenario is important to remember what the FR Switch should be doing: being the DCE and sending the keepalives to maintain the layer 2 link to the client router. Because of the fact that no FR Switch is present, the lack of keepalives being sent must be ignored using the “no keepalive” command. Also, Inverse ARP won’t work, so manual IP-DLCI mapping will be needed.
The FR Switch should be the one doing swapping of DLCIs on the network so the frames arrive at their destination with the correctly mapped DLCIs. In this case, we will need to have the same DLCI set in the manual mapping so the routers match entries in the mappings.
The topology:

Configuration:
R1(config)#int s0/1
R1(config-if)#no shut
R1(config-if)#clock rate 128000
R1(config-if)#ip address 10.1.2.1 255.255.255.0
R1(config-if)#encapsulation frame-relay
R1(config-if)#frame-relay map ip 10.1.2.2 42
R1(config-if)#no keepalive
R2(config)#int s0/1
R2(config-if)#no shut
R2(config-if)#clock rate 128000
R2(config-if)#ip address 10.1.2.2 255.255.255.0
R2(config-if)#encapsulation frame-relay
R2(config-if)#frame-relay map ip 10.1.2.1 42
R2(config-if)#no keepalive
Running configurations:
R1:
interface Serial0/1
ip address 10.1.2.1 255.255.255.0
encapsulation frame-relay
no keepalive
clockrate 128000
frame-relay map ip 10.1.2.2 42
end
R2:
interface Serial0/1
ip address 10.1.2.2 255.255.255.0
encapsulation frame-relay
no keepalive
frame-relay map ip 10.1.2.1 42
end
IPv6 Case Study: RIPng and usage of link local address
Posted by Alex Juncu
Simple topology: two routers, connected via a (serial) link, each with a loopback interface configured on it.
Loopback 0 on R1 has the IP 2001:A::1/64 and Loopback 0 on R2 has the IP 2001:B::1/64. We want to make R1 aware of the 2001:B::0/64 network and R2 aware of the 2001:A::0/64 network. RIPng would be the the easiest way of doing that.
First we need to enable IPv6 unicast routing, and then start the RIP process on the interfaces.
R1(config)#ipv6 unicast-routing
R1(config)#ipv6 router rip SIMPLE_RIP
R1(config)#interface lo0
R1(config-if)#ipv6 address 2001:A::1/64
R1(config-if)#ipv6 rip SIMPLE_RIP enableR2(config)#ipv6 unicast-routing
R2(config)#ipv6 router rip SIMPLE_RIP
R2(config)#interface lo0
R2(config-if)#ipv6 address 2001:B::1/64
R2(config-if)#ipv6 rip SIMPLE_RIP enable
We also need to activate the RIP process on the transit link and make the interface IPv6 enabled.
R1(config)#interface s0/1/1
R1(config-if)#ipv6 rip SIMPLE_RIP enable
R1(config-if)#ipv6 enable
R2(config)#interface s0/1/1
R2(config-if)#ipv6 enable
R2(config-if)#ipv6 rip SIMPLE_RIP enable
As it can be noticed, we haven’t configured a global IPv6 address on the interface, yet, RIP will do it’s job.
R2#sh ipv6 route
IPv6 Routing Table – 5 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route
I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
D – EIGRP, EX – EIGRP external
R 2001:A::/64 [120/2]
via FE80::219:E8FF:FEF2:8F3A, Serial0/1/1
C 2001:B::/64 [0/0]
via ::, Loopback0
L 2001:B::1/128 [0/0]
via ::, Loopback0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
The reason why it works, it’s a link local address, which is automatically configured once you turn on IPv6 on the interface. If the command “(config-if)#ipv6 enable” would have been missing, there would have been no exchange of routes.
Let us now analyze a possible misconfiguration. Let’s configure a global address on the link. What first comes to mind is IPv4 rule that stated that the serial interface of each router has to be configured in the same broadcast domain. We will configure the serial interface on R1 with 2001:C::1/64 and serial interface on R2 with 2001:D::1/64 (clearly in different subnets).
R1#show ipv6 interface serial 0/1/1
Serial0/1/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::219:E8FF:FEF2:8F3A
No Virtual link-local address(es):
Global unicast address(es):
2001:C::1, subnet is 2001:C::/64R2#show ipv6 interface serial 0/1/1
Serial0/1/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::21A:2FFF:FE2A:2118
No Virtual link-local address(es):
Global unicast address(es):
2001:D::1, subnet is 2001:D::/64
Even if we don’t have the two routers in the same subnet from the global address perspective, they are in the same broadcast domain from the link local address point of view. The traffic will still be routed via the link local address, because it’s actually “closer”.
R 2001:A::/64 [120/2]
via FE80::219:E8FF:FEF2:8F3A, Serial0/1/1
So, if your routes are flowing when you are thinking that they shouldn’t, you might want to remember the link local address.
Thanks go out to BogdanD for help with case study.