Monday, March 5, 2012

Cisco Frame Relay Switching Lab: Fully 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 partially meshed PVCs. This post will aim to show the logic around configuring fully meshed permanent virtual circuits (PVCs) for 4 customer sites using a single provider Frame Relay switch. This Cisco frame relay lab is configured in Dynamips/GNS3 with 5 Cisco c3725 routers utilizing WIC-2T cards.



The Provider Frame Relay Switch Configuration


If you have been following along with the two-site and three-site example, then this should be fairly straightforward as we are only increasing the number of PVCs. As the number of PVCs increase, the focus shifts to ensuring that DLCIs are being translated accurately as frames pass through the provider network (in this case FRS). If a company truly wants a full mesh, then it will require n(n-1)/2 PVCs where n is the number of sites, and this quickly becomes very expensive for many sites. Most companies settle on a partial mesh topology or a combination of frame relay with other WAN technologies.  

! Note: Some output omitted
!
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 201
 frame-relay route 103 interface Serial0/2 301
 frame-relay route 104 interface Serial0/3 401
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 201 interface Serial0/0 102
 frame-relay route 203 interface Serial0/2 302
 frame-relay route 204 interface Serial0/3 402
!
interface Serial0/2
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 301 interface Serial0/0 103
 frame-relay route 302 interface Serial0/1 203
 frame-relay route 304 interface Serial0/3 403
!
interface Serial0/3
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 401 interface Serial0/0 104
 frame-relay route 402 interface Serial0/1 204
 frame-relay route 403 interface Serial0/2 304
!

The Customer Perspective


The customer has an ever-growing number of choices of how to configure IP connectivity as the number of sites increase. As I presented in the three site example, the customer needs to choose between point-to-pojnt and multipoint subinterfaces based on how they are planning and using IP addresses within the network. Point-to-point subinterfaces require a unique IP network to be created for the devices at each end of a PVC while multipoint subinterfaces allow the same IP network to be used for all of the connected devices. The table below shows how quickly the number of required IP networks increases as the number of sites increases:

Number of Sites (Full Mesh) IP Networks (PtP Subinterfaces) = n(n-1)/2 IP Networks (MP Subinterfaces)
2 1 1
3 3 1
4 6 1
5 10 1
6 15 1
7 21 1
8 28 1
9 36 1
10 45 1
11 55 1

Most companies and network engineers still think in terms of classful networks and use class C (/24) networks for simplicity. Given that a Class C (/24) network can only be subnetted to 64 point to point networks (/30 network mask), multiple class C networks would need to be planned for a mesh of 12 or more sites. As the number of sites increase, the value of multipoint subinterfaces becomes far more apparent. Unless routes are being summarized, it is more desirable from a routing protocol standpoint to have multipoint subinterfaces defined because it limits the memory and processing capability that is required by routing updates (or limits the effort required to maintain static routes).  For this reason, I will only continue with a discussion of multipoint subinterfaces. See my 3 site example for a discussion of point-to-point subinterfaces.

Configuration from the customer perspective is fairly straightforward. For this example, all of the customer edge devices participating in the frame relay network will have IP addresses in the 192.168.1.0/28 range.

CE1 Serial 0/0.1 192.168.1.1
CE2 Serial 0/0.1 192.168.1.2
CE3 Serial 0/0.1 192.168.1.3
CE4 Serial 0/0.1 192.168.1.4

Since we are using multipoint subinterfaces, frame-relay map commands need to be used to map IP addresses to DLCIs (since the LMI messages exchanged between the edge devices and the frame-relay switch have no knowledge of anything at or above layer 3). The relevant configuration sections for each customer edge router are shown below:

CE1

!
interface Serial0/0
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.1 multipoint
 ip address 192.168.1.1 255.255.255.240
 frame-relay map ip 192.168.1.2 102
 frame-relay map ip 192.168.1.3 103
 frame-relay map ip 192.168.1.4 104
 frame-relay interface-dlci 102
 frame-relay interface-dlci 103
 frame-relay interface-dlci 104
!

CE2

!
interface Serial0/0
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.1 multipoint
 ip address 192.168.1.2 255.255.255.240
 frame-relay map ip 192.168.1.1 201
 frame-relay map ip 192.168.1.3 203
 frame-relay map ip 192.168.1.4 204
 frame-relay interface-dlci 201
 frame-relay interface-dlci 203
 frame-relay interface-dlci 204
!

CE3

!
interface Serial0/0
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.1 multipoint
 ip address 192.168.1.3 255.255.255.240
 frame-relay map ip 192.168.1.1 301
 frame-relay map ip 192.168.1.2 302
 frame-relay map ip 192.168.1.4 304
 frame-relay interface-dlci 301
 frame-relay interface-dlci 302
 frame-relay interface-dlci 304
!


CE4

!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
!
interface Serial0/0.1 multipoint
 ip address 192.168.1.4 255.255.255.240
 snmp trap link-status
 frame-relay map ip 192.168.1.1 401
 frame-relay map ip 192.168.1.2 402
 frame-relay map ip 192.168.1.3 403
 frame-relay interface-dlci 401
 frame-relay interface-dlci 402
 frame-relay interface-dlci 403
!

Verification of the above topology relies on using ICMP echo (ping). See the note below for configuring broadcast capability.

Broadcasts on Frame-Relay Links

The map commands in the configuration snippets above do not allow broadcast reliant protocols such as CDP to run. To allow these types of protocols to run properly and send broadcasts on the frame-relay PVCs, the frame-relay map command needs to be specified with the map command. Here are examples of modifying the above configurations to allow broadcasts between CE1 and CE2,

CE1(config-subif)#no frame-relay map ip 192.168.1.2 102
CE1(config-subif)#frame-relay map ip 192.168.1.2 102 broadcast

CE2(config-subif)#no frame-relay map ip 192.168.1.1 201
CE2(config-subif)#frame-relay map ip 192.168.1.1 201 broadcast

Now, broadcasts can be sent between CE1 and CE2, and other protocols that use broadcasts at layer 2 can run over the multipoint subinterface. Note that Cisco Discovery Protocol (CDP) is not supported over multipoint subinterfaces.

See Also,
Introduction to Frame Relay Switching
Cisco Frame Relay Switching Lab: Partially Meshed PVCs





No comments:

Post a Comment