Saturday, March 3, 2012

Cisco Frame Relay Switching Lab: Partially Meshed PVCs


Advertisement

Advertisement
This post is somewhat a continuation of my previous post that provided an introduction to frame relay switching and acts as an alternate post to my lab that shows switching for fully meshed PVCs. This post will aim to show the logic around configuring partially meshed permanent virtual circuits (PVCs) for 3 customer sites using a single provider Frame Relay switch. This frame relay lab is configured in Dynamips/GNS3 with 4 Cisco c3725 routers utilizing WIC-2T cards.


Configuration of the Frame-Relay Switch

The configuration for this scenario is fairly straightforward on the frame relay switch. The main detail is to remember that DLCIs are only significant on the link between a frame relay endpoint and the first hop in the frame relay cloud. To illustrate this, CE2 and CE3 both reference their PVCs to CE1 with a DLCI value of 100. Here are the important pieces of the configuration for the frame relay switch (in the provider's cloud):

!    Frame Relay Switch Configuration
!    Note that lines not directly related to frame relay switching
!    or interface configuration have been removed.
frame-relay switching
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 102 interface Serial0/1 100
 frame-relay route 103 interface Serial0/2 100
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 100 interface Serial0/0 102
!
interface Serial0/2
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 100 interface Serial0/0 103

Remember that the frame-relay route command specifies how the DLCI is rewritten for frames received on that interface. This command specifies what the DLCI should be rewritten for the next frame relay hop and also specifies the outgoing interface (or Tunnel pseudo-interface or frame relay multilink bundle).

Customer Edge Device Configuration

The customer's networking team has a couple of decisions to make around how to configure CE1. The main decision is whether to use point-to-point or multipoint subinterfaces. If the team wants to maintain full connectivity between sites and use point-to-point subinterfaces, they will need a unique layer 3 network for each pair of subinterfaces involved in sending data over a PVC. Since this is a connection between 2 IP systems, it is possible to use IPv4 networks with the 255.255.255.252 (/30) subnet mask. If the team wants all of the connections over the frame relay cloud to use a single layer 3 network, then a multipoint subinterface is required for the CE1 router. For CE2 and CE3, there is only need for point-to-point subinterfaces because each router connects with only 1 router using PVCs across the connected serial interface. I will show both configurations.

Point-to-Point Subinterfaces

For the first example, I will show the scenario where the customer's team decided to use point-to-point subinterfaces. I will use the 10.0.0.0/30 network for the subinterfaces mapped to the PVC between CE1 and CE2 and I will use the 10.0.0.4/30 network for the subinterfaces mapped to the PVC between CE1 and CE3. In addition to creating and configuring the subinterfaces, I will need to add a static route on CE2 and CE3 to ensure full connectivity.

Here is the relevant configuration for CE1:
interface Serial0/0
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
 ip address 10.0.0.1 255.255.255.252
frame-relay interface-dlci 102
!
interface Serial0/0.2 point-to-point
 ip address 10.0.0.5 255.255.255.252
frame-relay interface-dlci 103
!


CE2 is also fairly straightforward. The main item to note is the static route to ensure connectivity to 10.0.0.4/30:

interface Serial0/0
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
 ip address 10.0.0.2 255.255.255.252
 frame-relay interface-dlci 100
!
ip route 10.0.0.4 255.255.255.252 10.0.0.1


CE3 follows similar lines to CE2:

interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
!
interface Serial0/0.1 point-to-point
 ip address 10.0.0.6 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 100
!
ip route 10.0.0.0 255.255.255.252 10.0.0.5

Verification of connectivity between CE1 and it's connected routers is straightforward using the techniques presented in my previous post. The main items to check in this configuration are end-to-end connectivity between CE2 and CE3 and verify the routing tables on CE2 and CE3:

CE2#ping 10.0.0.6

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

CE2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/30 is subnetted, 2 subnets
C       10.0.0.0 is directly connected, Serial0/0.1
S       10.0.0.4 [1/0] via 10.0.0.1

From CE3:

CE3#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/25/76 ms
CE3#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/30 is subnetted, 2 subnets
S       10.0.0.0 [1/0] via 10.0.0.5
C       10.0.0.4 is directly connected, Serial0/0.1


Multipoint Subinterfaces

With multipoint subinterfaces, we can keep all of the interfaces connected to the frame-relay topology assigned to the same layer IP network. For this example, I will use 10.0.0.0/24 (specifically .1 for CE1, .2 for CE2, and .3 for CE3). In this case we need to map next-hop IP addresses to DLCIs on CE1 so that we can achieve full connectivity. Unlike the point-to-point subinterface example above, static routes are not needed. BElow are the relevant configuration sections for CE1, CE2 and CE3.

On CE1:
interface Serial0/0
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.1 multipoint
 ip address 10.0.0.1 255.255.255.0
 frame-relay map ip 10.0.0.3 103
 frame-relay map ip 10.0.0.2 102
 frame-relay interface-dlci 102
 frame-relay interface-dlci 103
!


On CE2:
interface Serial0/0
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
  ip address 10.0.0.2 255.255.255.0
  frame-relay interface-dlci 100


On CE3:
interface Serial0/0
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
  ip address 10.0.0.3 255.255.255.0
  frame-relay interface-dlci 100
!


Verification should be performed to ensure that CE2 and CE3 can successfully communicate:

CE2#ping 10.0.0.3

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

CE3#ping 10.0.0.2

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


It is also possible to verify the next hop IP addresses mapped to DLCIs using the show frame-relay map command and also determine if they are statically defined or discovered dynamically using inverse ARP:

CE1#show frame-relay map
Serial0/0.1 (up): ip 10.0.0.2 dlci 102(0x66,0x1860), static,
              CISCO, status defined, active
Serial0/0.1 (up): ip 10.0.0.3 dlci 103(0x67,0x1870), static,
              CISCO, status defined, active



See Also:
The Road to the CCIE
Introduction to Frame Relay Switching

No comments:

Post a Comment