Frame Relay Switching Lab Using Multiple Switches (Tunnels)

Frame Relay is an important exam topic in the CCNA (mostly ICND2 exam), CCNP, and CCIE certifications for the routing and switching track. This post builds on the frame relay switching post that showed configuration of partially meshed and fully meshed permanent virtual circuits (PVCs). There are a lot of examples that show how to configure a single router as a frame-relay switch, but very few that show how to configure multiple provider devices to enable an end-to-end frame relay network. This lab, built in GNS3/Dynamips, demonstrates 2 customers being connected using a provider network with an IP backbone and frame-relay switching on the edge devices. Configurations shown are Cisco 3725 routers running  Cisco IOS 12.4(15)T7.

The topology below shows the entire network as it has been configured. PE1 and PE2 perform frame-relay switching for Customer 1 (Cust1) and Customer 2 (Cust2). The connections between PE1, P, and PE2 utilize HDLC (Cisco's default for serial interfaces) and IP. The internal provider (P) router has no knowledge of any of the frame relay configuration on the provider edge routers (PE1 and PE2). The provider network runs OSPF to maintain internal IP connectivity. A GRE-IP tunnel is configured between PE1 and PE2 to encapsulate the frame-relay packets as they cross the frame relay cloud.


The main interesting points of configuration exist on the provider network routers: PE1, P, and PE2. The simplest configuration is on the P router where the IP addresses and routing protocol (OSPF in this case) are configured:

interface Serial0/0
 ip address 172.16.1.2 255.255.255.252
!
interface Serial0/1
 ip address 172.16.2.2 255.255.255.252
!
router ospf 1
 log-adjacency-changes
 network 172.16.0.0 0.0.255.255 area 0
!

On router PE1, we perform some frame-relay configuration for the customer interfaces and specify that the frame-relay encapsulated frames should be tunneled. Customer 1 and 2 have a single point-to-point PVC defined between the customer edge routers connecting to PE1 and PE2:

!
frame-relay switching
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 100 interface Tunnel0 200
!
interface Serial0/2
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 150 interface Tunnel0 300
!

We also configure one side of the GRE-IP tunnel:

interface Tunnel0
 no ip address
 tunnel source 172.16.1.1
 tunnel destination 172.16.2.1
!

Note that since GRE-IP is the default tunnel mode, the tunnel mode gre ip command is not necessary. Finally, the internal provider connection and the routing protocol are configured. If multiple paths existed between PE1 and PE2, a tunnel source using a loopback interface would be appropriate, but this case does not require loopback interfaces. Additionally, with the different tunnel choices, GRE over IP or GRE over IPv6 are the main tunnel types that will work for encapsulating frame relay over IP.

PE1(config-if)#tunnel mode ?
  aurp    AURP TunnelTalk AppleTalk encapsulation
  cayman  Cayman TunnelTalk AppleTalk encapsulation
  dvmrp   DVMRP multicast tunnel
  eon     EON compatible CLNS tunnel
  gre     generic route encapsulation protocol
  ipip    IP over IP encapsulation
  ipsec   IPSec tunnel encapsulation
  iptalk  Apple IPTalk encapsulation
  ipv6    Generic packet tunneling in IPv6
  ipv6ip  IPv6 over IP encapsulation
  mpls    MPLS encapsulations
  nos     IP over IP encapsulation (KA9Q/NOS compatible)
  rbscp   RBSCP in IP tunnel


Here we can finish the discussion of PE1's configuration with its connection into the provider cloud and its routing protocol configuration:

!
interface Serial0/0
 ip address 172.16.1.1 255.255.255.252
!
router ospf 1
 log-adjacency-changes
 network 172.16.0.0 0.0.255.255 area 0
!


The configuration is very similar on PE2. From the customer's perspective we are using global DLCI addressing:

!
frame-relay switching
!
interface Tunnel0
 no ip address
 tunnel source 172.16.2.1
 tunnel destination 172.16.1.1
!
interface Serial0/0
 ip address 172.16.2.1 255.255.255.252
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 150 interface Tunnel0 300
!
interface Serial0/2
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 100 interface Tunnel0 200
!
router ospf 1
 log-adjacency-changes
 network 172.16.0.0 0.0.255.255 area 0
!

Verification of the setup from the customer side is easy, if traffic flows, then the PVC is working:

Cust1_CE1(config-subif)#do ping 192.168.0.2

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

We can also see that the PVC is active and assigned:

Cust1_CE1(config-subif)#do show frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.100

  input pkts 104           output pkts 106          in bytes 31197
  out bytes 31863          dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 91        out bcast bytes 30303
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 01:32:24, last time pvc status changed 01:31:54


On the provider routers, verification involves examining the status of the tunnel to make sure it is up/up (using the show interface tunnel 0 command) and the PVC (show frame-relay pvc). If there is a problem, the PVC will show as Inactive (where a PVC should show Active if it is working correctly).

See Also,
The Road to the CCIE