Tag Archives: Frame Relay

Point to Point and Point to Multipoint

I’ve been really enjoying working with frame relay, but one thing I couldn’t keep straight was point to point and point to multi-point sub interfaces, and the role of the DLCI. For some reason this was a confusing mass that I just could not untangle, so here is what I finally managed to come up with to keep it straight

Point to Point Frame Relay Connections

pp2mp1Lets take a simple three router set up. We can easily configure three serial links to connect all three routers.

The problem with it of course, is that it does not scale, requiring one serial interface for each router connection. A full mesh on a reasonable sized network could incredibly complex and even a large hub and spoke will require a great deal of hardware. Each link in the network has to have a serial interface and each serial link has to be on it’s own subnet. (See the /30 IP addresses)

The other thing to remember is that frame relay is a layer two protocol, so IP addressing is not used in the frame relay switch. For the frame relay to work we must remember to use Data Link Connection Identifiers (DLCIs). For each logical connection or circuit, there is one DLCI specified. Because there is only one DLCI, there are no frame relay map statements and no inverse arp required.

Point to Point sub interface, Frame Relay Connection

pp2mp2

The point to point sub interface configuration is the same as the configuration above, but we logically segment our serial interface, reducing the hardware requirements. However, like the example above there is some subnetting to be done.

This also uses frame-relay interface-dlci command for each sub interface connection.

Remember that the DLCI is supplied by the service provider, and are locally significant only. They are simply flags that indicate the ends of our virtual circuits.

Point to Multi-Point Frame Relay Connections

pp2mp3

With point to multipoint, we have a hub router using a single serial connection to the frame relay switch, but; we have multiple DLCIs specified through either frame map statements for static configuration, or inverse arp for dynamic configuration.

Subnetting can be done or not, depending on the network configuration. In the example here, all three connections are on one subnet.

Frame-relay map <IP address> <DLCI #>

So how do we know what method of connection to use?

Personally, I prefer the point to multipoint as there is less fuss with and fewer IP addresses used. For a small configuration, (maybe up to three serial links) I could see using sub interfaces, but for larger configurations, I think the p2mp wins just on the fewer IP addresses required.

From the Cisco Library:

Multipoint

  • Subinterfaces act as default NBMA network
  • Can save subnets because uses single subnet
  • Good for full-mesh topology

Point-To-Point

  • Subinterfaces act as leased line
  • Each point-to-point connection requires its own subnet
  • Good for star or partial-mesh topologies
  • In Point to Point More IP Addresses are consumed than the Multipoint Subinterfaces.

 

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

Frame Relay and Sub Interfaces

In this post we are going to look at sub interfaces and frame relay. The topology for this lab is going to be based on the previous frame relay lab, but with an added loopback interface. I am also running RIP on all three routers.

fr03

So what is the deal with the sub interfaces. Well, this is a solution for a problem that we have yet to encounter in our studies, but will do shortly. There is a protocol called Split Horizons, that basically says; if a route advertisement comes in on a port, it cannot be advertised out of that same port.

Now if you think about that for a minute, what that means is that any routes info received through our serial ports cannot be re-advertised out of same serial port and this is a problem.

Why is this a problem?

In this topology, the single serial port connection is the only connection between the routers so what split horizons effectively does in this case is neuter our routing protocols.

So how do we fix this?

Well, there are three ways to solve this problem:

  • Turn off Split Horizons
  • Move to a full mesh topology
  • Logically segment the serial port

Turning off Split Horizon is not really an option., Sure it solves this problem, but it will likely create a whole slew of other routing issues.

Moving to a full mesh would work in this case as we only have three routers, but what if we have 4, 5, 6 and so on? This really isn’t a scaleable or cost effective solution.

That leaves us with segmenting the serial port, and here is how we do it: (This is similar to the way we set up our router on a stick)

interface Serial0/0
 description : Frame Relay Connection
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
 frame-relay lmi-type cisco
!
interface Serial0/0.12 point-to-point
 ip address 172.12.123.1 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 122 
!
interface Serial0/0.13 point-to-point
 ip address 172.12.123.5 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 123 
!

You can see the logical split in the serial interface. Notice that we had to specify that the interface is point-to-point, and the frame relay map statements are gone. Instead we have the interface DLCI statement that maps the point to point interface to the DLCI directly.

Once the interface is opened, we get the following:

r2610xm#sh ip int brief
Interface        IP-Address   OK? Method Status           Protocol
FastEthernet0/0  unassigned   YES manual administratively down down 
Serial0/0        unassigned   YES manual    up up 
Serial0/0.12     172.12.123.1 YES manual    up up 
Serial0/0.13     172.12.123.5 YES manual    up up 
r2610xm#

Up and up so all is good there, and lets check the frame relay connections:

r2610xm#sh frame-relay map 
Serial0/0.12 (up): point-to-point dlci, dlci 122(0x7A,0x1CA0), broadcast
 status defined, active
Serial0/0.13 (up): point-to-point dlci, dlci 123(0x7B,0x1CB0), broadcast
 status defined, active
r2610xm#

Both interfaces have defined and active DLCIs.

… and it is that easy!

 

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

Frame Relay Continued

Before we leave Frame Relay, there are a few more aspects to consider.

FECN and BECN

These two flags indicate WAN congestion.

  • FECN – Forward Explicit Congestion Notification
  • BECN – Backward Explicit Congestion Notification

When we ran our debugs in the Frame Relay lab, we could see these listed in our debug and various command outputs. We want these values to be zero, anything else indicates congestion.

So how does this work?

Lets assume you have two routers communicating via a frame relay switch.

Router A sends a packet to router B, but the packet encounters congestion as it travels across the frame relay cloud. The frame relay switch will set the FECN flag indicating forward congestion.

When a frame is back from B to A, the BECN bit is set to let router A know of the congestion.

Monitoring the FECN/BECN can be used a limited form of Flow Control or Quality of Service. This helps with packet loss.

 

The DE Bit

The DE bit (discard eligible) can also be seen in the outputs of our debugs, and again it is a flag that is concerned with congestion, but: During congestion, frames with the DE bit set will be dropped before frames without the DE bit set.

This is again, a quality of service issue.

 

PVC Status Messages

We want out PVC to be active but there are other status:

  • active – what we want to see
  • inactive – other end of the link is closed
  • deleted – our end of the link has an issue

 

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

Frame Relay Lab – Part 2

In this second Frame Relay lab post, I’ll just list the router configurations, along with a few notes.

I have four routers; the end point routers 1-3 and the frame relay switch. In all four cases I started with a blank configuration. I have not included router 4, the 2509 as this is an extra router I will add later.

fr01

Router 1, the Hub

r2610xm#sh run
Building configuration...
Current configuration : 1132 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname r2610xm
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$BinW$VdEFnRtPL/cyf9y/L1nVJ.
!
interface FastEthernet0/0
 no ip address
! 
interface Serial0/0
 description : Frame Relay Connection
 ip address 172.12.123.1 255.255.255.0
 encapsulation frame-relay
 no fair-queue
 frame-relay map ip 172.12.123.3 123 broadcast
 frame-relay map ip 172.12.123.2 122 broadcast
 no frame-relay inverse-arp
 frame-relay lmi-type cisco
!
ip http server
no ip http secure-server
!
line con 0
 logging synchronous
line aux 0
line vty 0 4
 exec-timeout 0 0
 logging synchronous
 no login
!
!
end

Router 2

r2610#sh run
Building configuration...
Current configuration:
!
version 11.3
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname r2610
!
enable secret 5 $1$BinW$VdEFnRtPL/cyf9y/L1nVJ.
!
interface Ethernet0/0
 no ip address
 shutdown
!
interface Serial0/0
 no ip address
 no ip mroute-cache
 shutdown
!
interface Serial0/1
 description : Framer Relay Connection
 ip address 172.12.123.2 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 172.12.123.1 221 broadcast
 frame-relay map ip 172.12.123.3 221 broadcast
 no frame-relay inverse-arp
 frame-relay lmi-type cisco
!
ip classless
!
line con 0
 logging synchronous
line aux 0
line vty 0 4
 exec-timeout 0 0
 logging synchronous
 no login
!
no scheduler allocate
end
r2610#

Router 3

!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname r1721
!
logging queue-limit 100
enable secret 5 $1$WjTX$Le8IjkbTDnymOuyaLCQKc/
!
ip subnet-zero
! 
interface FastEthernet0
 description : no connect
 no ip address
 shutdown
!
interface Serial0
 description : Frame Relay Connection
 ip address 172.12.123.3 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 172.12.123.1 321 broadcast
 frame-relay map ip 172.12.123.2 321 broadcast
 no frame-relay inverse-arp
 frame-relay lmi-type cisco
!
interface Serial1
 no ip address
 shutdown
!
ip classless
no ip http server
!
line con 0
 exec-timeout 30 0
 logging synchronous
line aux 0
line vty 0 4
 logging synchronous
 no login
!
end

The Frame Relay Switch

FRS#sh run
Building configuration...
Current configuration : 2067 bytes
!
version 12.2
service config
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname FRS
!
enable secret 5 $1$xH/l$LjUaCsvrE4dIxcZyLiHEI/
!
username tony password 0 xxxxxxxxxxxx
ip subnet-zero
!
!
no ip domain-lookup
!
frame-relay switching
!
interface FastEthernet0/0
 description Connection to home network
 ip address 192.168.2.12 255.255.255.0
 speed auto
 half-duplex
!
interface Serial0/0
 description : No Connect
 no ip address
 shutdown
!
interface Serial0/1
 description : No Connect
 no ip address
 shutdown
!
interface Serial1/0
 description : No Connect
 no ip address
 shutdown
!
interface Serial1/1
 description : Frame Relay to r3
 no ip address
 encapsulation frame-relay
 logging event subif-link-status
 logging event dlci-status-change
 clockrate 115200
 no frame-relay inverse-arp
 frame-relay intf-type dce
 frame-relay route 321 interface Serial1/3 123
!
interface Serial1/2
 description : Frame Relay to r2
 no ip address
 encapsulation frame-relay
 logging event subif-link-status
 logging event dlci-status-change
 clockrate 115200
 no frame-relay inverse-arp
 frame-relay intf-type dce
 frame-relay route 221 interface Serial1/3 122
!
interface Serial1/3
 description : Frame Relay to the hub r1
 no ip address
 encapsulation frame-relay
 logging event subif-link-status
 logging event dlci-status-change
 clockrate 115200
 no frame-relay inverse-arp
 frame-relay intf-type dce
 frame-relay route 122 interface Serial1/2 221
 frame-relay route 123 interface Serial1/1 321
!
ip classless
ip http server
!
banner login ^CCC
************************************************
Cisco 2620 Configured as
 A Frame Relay Switch

************************************************
^C
!
line con 0
 exec-timeout 30 0
 logging synchronous
line aux 0
line vty 0 4
 exec-timeout 30 0
 logout-warning 120
 logging synchronous
 login local
 transport preferred telnet
 transport input telnet
 transport output telnet
!
end

FRS#
Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone

Frame Relay Lab – Part 1

The best way to get to grips with Frame Relay is to run a frame relay lab, so here we go.

This is our topology:

fr01

I am following Chris Bryant’s frame relay lab, but with an extra router just because I have the extra connections. As such have used his frame relay switch configuration. The dedicated frame relay switch is a Cisco 2620 with a NM4A/S and a WIC-2T giving me a total of 6 serial ports. I’ve included labels indicating how this is wired, and those will help in the debug too (So that I can see what it is I am trying to debug).

The config for the serial ports looks like this:

interface Serial0/0
 description : Frame Relay Connection
 ip address 172.12.123.1 255.255.255.0
 encapsulation frame-relay
 no frame-relay inverse-arp
 frame-relay lmi-type cisco

We have our LMI type hard coded and I am a fan of the description command – I think documentation is important, and its not much but the description command is better than nothing.

With our IP addresses set on each serial port, can we ping? Well no we can’t.

So why doesn’t ping work?

The problem is that we don’t have layer 2 fully specified and with layer 2 not working correctly, layer 3 will not work. What we need are layer 2 mappings, which brings us to …

Data Link Connection Identifiers (DLCI)

fr02

The DLCI is a layer 2 frame relay address however, the DLCIs are locally significant only. When you (or your organization) purchases a PVC, the frame relay service provider will supply you with your DLCI numbers. The DLCI numbers identify the ends of the PVC.

In this graphic, we can assume the frame relay provider (in this case, me) provided the DLCIs shown. As a purchaser of the PVC(s) (and for the purposes of the CCNA) we don’t need to know what goes on inside the frame relay cloud. We just have to know that the DLCI marks the end of the PVC, and there are two (local) DLCIs per PVC.

When mapping the DLCIs we Always map the local DLCI to the remote IP

So what does a frame mapping and DLCIs looks like?
From Router 1, at 172.12.123.1, the map to reach router 2 at 172.12.123.2, looks like this:

Frame-relay map ip 172.12.123.2 int serial 0/0 122 

The only issue with the configuration right now is that while we can ping just fine (unicast), we cannot send multicast or broadcast packets. What we need to do to enable broadcast capability. This is done via an option on the frame map statement.

frame-relay map ip 172.12.123.2 int serial 0/0 123 broadcast

The other quirk with Frame Relay mappings is that there needs to be a mapping for each PCV connection and route. In other words, when we look at the mapping for Router 2, it has a mapping for router 1 (the hub) and router 3, although both mappings map to DLCI 221 because both routes go via the hub.

 

 A Quick word in the inverse ARP command:

Inverse ARP is mechanism by with frame switching automatically figures out its topology – much like ARP is used on layer 2 Ethernet switches. The problem with this is that for the most part, it is best practice to hard code the mapping, or at least that is the situation for the CCNA.

 

Debugging

When debugging router configs, the first command I like to use is sh ip int brief.  This gives me a run down on all the interfaces I have, any IP numbers associated with them and their status. It is the status that I am usually looking for, What we want to see is up and up. Sometimes I see administratively down and down – that tells me I forgot to issue the no shut!

The show frame lmi command is a good one to know as this shows the sent and received LMI messages. Given that the LMI is sent every 10 seconds, we can easily watch the sent and received numbers increment and the timeout number remain static.

debug frame lmi is also a command that is worth knowing as this will push messages to the console for each LMI mnessage. This will show miss matches and other errors.

 

To conclude

This post is starting to get pretty long so I’m going to list the configs in my next post.

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditShare on StumbleUponEmail this to someone