Setting up a lab for frame relay?

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View
I'm trying to understand frame relay but finding some of the examples
hard to replicate in my home lab. None of the examples in any of my
boooks (CCNA ICND2 by Wendell Odom / CCNA command quick reference or on
the CBT nuggets CD) explain how to set frame relay up in a lab.

I found a document on Cisco's site called Back-to-Back Frame Relay
Hybrid Switching which gives the router config command 'frame-relay
switching' to turn on  frame relay switching, but no other commands in
order to set up virtual DLCIs. I have succesfully created a frame relay
link between two of my routers (see below screen dump) but the only way
it works is with both point-to-point sub-interfaces using the same DLCI
number, which is contrary to how all the examples in my book work.

Maybe I'm missing something or maybe I'm trying to create too complex an
environment for a basic lab, but it is frustrating none the less. Any
ideas?

TIA, Jase.

GROUCHO#show run int s0/0.100
Building configuration...

Current configuration : 122 bytes
!
interface Serial0/0.100 point-to-point
 ip address 192.168.10.1 255.255.255.252
 frame-relay interface-dlci 101
end

GROUCHO#

CHICO#show run int s0.1
Building configuration...

Current configuration:
!
interface Serial0.1 point-to-point
 ip address 192.168.10.2 255.255.255.252
 no ip directed-broadcast
 frame-relay interface-dlci 101
end

CHICO#p 192.168.10.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/39/52 ms
CHICO#show fram
CHICO#show frame-relay map
Serial0 (up): ip 192.168.2.2 dlci 122(0x7A,0x1CA0), static,
              broadcast,
              CISCO, status defined, active
Serial0.2 (up): point-to-point dlci, dlci 112(0x70,0x1C00), broadcast
          status defined, active
Serial0.1 (up): point-to-point dlci, dlci 101(0x65,0x1850), broadcast
          status defined, active
CHICO#


Show version commands of both routers used:

CHICO#show version
Cisco Internetwork Operating System Software
IOS (tm) 2500 Software (C2500-D-L), Version 12.0(11), RELEASE SOFTWARE
(fc1)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Sat 20-May-00 06:39 by htseng
Image text-base: 0x030388AC, data-base: 0x00001000

ROM: System Bootstrap, Version 11.0(10c), SOFTWARE
BOOTFLASH: 3000 Bootstrap Software (IGS-BOOT-R), Version 11.0(10c),
RELEASE SOFTWARE (fc1)

CHICO uptime is 2 hours, 48 minutes
System restarted by power-on
System image file is "flash:c2500-d-l_120-11.bin"

cisco 2500 (68030) processor (revision L) with 6144K/2048K bytes of
memory.
Processor board ID 06110204, with hardware revision 00000000
Bridging software.
X.25 software, Version 3.0.0.
Basic Rate ISDN software, Version 1.1.
1 Token Ring/IEEE 802.5 interface(s)
2 Serial network interface(s)
1 ISDN Basic Rate interface(s)
32K bytes of non-volatile configuration memory.
8192K bytes of processor board System flash (Read ONLY)

Configuration register is 0x2102


GROUCHO#show version
Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-I-M), Version 12.2(27), RELEASE SOFTWARE
(fc3)
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Tue 02-Nov-04 23:44 by kellmill
Image text-base: 0x8000808C, data-base: 0x80A1F47C

ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)

GROUCHO uptime is 2 hours, 47 minutes
System returned to ROM by power-on
System image file is "flash:c2600-i-mz.122-27.bin"

cisco 2611 (MPC860) processor (revision 0x203) with 61440K/4096K bytes
of memory.
Processor board ID JAD04420E7O (4253923018)
M860 processor: part number 0, mask 49
Bridging software.
X.25 software, Version 3.0.0.
2 Ethernet/IEEE 802.3 interface(s)
1 Serial network interface(s)
32K bytes of non-volatile configuration memory.
8192K bytes of processor board System flash (Read/Write)

Configuration register is 0x2102

Re: Setting up a lab for frame relay?
wrote:
Quoted text here. Click to load it

One of your routers is emulating a frame relay switch i.e. a frame
realy cloud.  The other is acting as a router configured with frame
relay.  As such it is correct to have the same dlci on both devices.  \\
\\

A better way is to configure a router with serveral serial ports as a
frame relay switch.  Then connect two or three routers to the frame
relay switch and configure them for frame relay.

Here is a configuration for the router to be configured as a frame
relay switch:

http://www.thebryantadvantage.com/Frame%20Relay%20Switch.htm

Here is an article that explains the dlci question you are asking.  It
is a point of confusion.  This guy expalins it best.

http://tcpmag.com/international/article.asp?EditorialsID=3D268

Search for Frame Relay

Then look for How come my circuit doesn't come up?

It is a great article.

Good luck

Re: Setting up a lab for frame relay?

I hear you - I do!

Wendell Odom clearly knows what he's saying, but often leaves much to be
desired.

Luckily, I purchased The Bryant Advantage before I'd purchased any
offical Cisco media, so my understanding of Frame Relay had already been
given a great boost.

If you want to purchase some of his study material, like "The Ultimate
CCNA package", then go to http://thebryantadvantage.com/

I'd set up a FR lab at home, with three FR routers running PVCs through
my Frame Relay Switch (all thanks to a link on Chris Bryant's website,
and no thanks to Wendell Odom (bless him)).

Good luck,
Regards,
Jason Tomasi



Jason wrote:
Quoted text here. Click to load it

Re: Setting up a lab for frame relay?

Quoted text here. Click to load it

I have the feeling the books were rushed out as there are quite a few
spelling mistakes & in one part an incorrect diagram appears, totally
unrelated to the text, maybe the next editions will be better? I'll have to
go on the the Cisco Press site & download the addendum.

Re: Setting up a lab for frame relay?
Jason wrote:

Quoted text here. Click to load it

Frame relay is usually represented as a cloud, with only the border routers
drawn. What's actually inside the cloud is nothing more that a frame relay
switch (or more than one, but this does not change the concepts), that is,
another router which acts as a switching point between the border routers,
and through which all the virtual circuit pass.

Quoted text here. Click to load it

The base rule about DLCIs is that they are locally significant. This means
that DLCI, say, 100 on router R1 has nothing to do with DLCI 100 on router
R2, if R1 and R2 are border routers (ie, neither is a FR switch). Another
way to look at it is that each DLCI is significant only between the router
and its attached switch, and does not extend from end to end (as you will
see).

How comes then that Odom says that DLCIs can also be used with "global"
significance? Well, if you understand how a FR switch works then you'll see
that what he describes is actually possible, without contradicting the
local significance rule.

Take the following (a bit simplified) FR hub-and-spoke topology as an
example:


   S2          S3
     \\        /      
      \\      /      
       \\    /      
        \\  /      
         \\/
        HUB1-----------S4

This is what you see in CCNA books, with the links plunged into "the cloud".
But of course, all the routers (HUB1, S2, S3, S4) are connected to a FR
switch. So, the actual topology is as follows:

  S2           S3
    \\         /
     \\       /
      \\     /
       \\   /  
        \\ /
        FRSW----------S4
         |
         |
         |
         |
        HUB1

Here we see that the switch is just another router, with four serial
interfaces, using frame relay encapsulation (let's assume that HUB1, S2, S3
and S4 are connected to FRSW's port s1, s2, s3 and s4 respectively).

Being an hub-and-spoke topology, each spoke has a VC to the hub, and the hub
has three VCs, one to each spoke (if we want a full mesh the concepts are
exactly the same, it's just a matter of adding few config lines to each
router, as you'll see). It's the switch's job to set up all these VCs.

Now, let's revisit the concepts of local and "global" DLCIs using the
complete picture (ie, with the switch).

With local DLCIs, they say, /the hub is known by each spoke through a
different DLCI, and, generalizing (if a full mesh is in effect), router Rx
is known by router Ry and Rz through different DLCIs/. Thus:

  S2           S3
    \\201      /301
     \\       /
      \\     /
       \\   /  
        \\ /
        FRSW----------S4
         |         401
         |
         |
         |102,103,104
        HUB1

Near each router are the DLCIs that depart from it. That is, S2 uses DLCI
201 to talk with HUB1, whereas S3 uses DLCI 301 to talk with HUB1, and so
on. All FRSW has to do is to change DLCIs in frames that pass through it,
and route them out the correct port. For example, if S2 is talking with
HUB1, FRSW will receive a FR frame on port 2, with a DLCI of 201. Since
FRSW knows (from previous configuration) that there is a VC connecting its
port 2 and 1, with an incoming DLCI of 201 and on outgoing DLCI of 102, it
will just rewrite the DLCI in the frame (putting 102) and send it out port
1. If HUB1 talks to S2, the process will just be reversed (from port 1,
DLCI 102, to port 2, DLCI 201).

So, an example configuration for the routers would be:

S2#
int s0/0.201 point-to-point
  frame-relay interface-dlci 201

S3#
int s0/0.301 point-to-point
  frame-relay interface-dlci 301

S4#
int s0/0.401 point-to-point
  frame-relay interface-dlci 401

HUB1#
int s0/0.102 point-to-point
  frame-relay interface-dlci 102
int s0/0.103 point-to-point
  frame-relay interface-dlci 103
int s0/0.104 point-to-point
  frame-relay interface-dlci 104


And, on the switch:

FRSW#
frame-relay switching

int s2
  frame-relay route 201 interface s1 102

int s3
  frame-relay route 301 interface s1 103

int s4
  frame-relay route 401 interface s1 104

int s1
  frame-relay route 102 interface s2 201
  frame-relay route 103 interface s3 301
  frame-relay route 104 interface s4 401

Essentially, the switch is told how to rewrite DLCIs and route frames
depending on incoming interface and incoming DLCI.


Now, let's see how we might configure "global" DLCIs. For global DLCIs,
CCNA books usually have a picture similar to this:

  S2           S3
    \\202      /303
     \\       /
      \\     /
       \\   /  
        \\ /
        HUB1----------S4
       101            404
        
Now, each router has its own (globally unique) DLCI. Let's start by
redrawing the picture using the actual topology with the switch:
        
  S2           S3
    \\202      /303
     \\       /
      \\     /
       \\   /  
        \\ /
        FRSW----------S4
         |         404
         |
         |
         |101
        HUB1

With the above notions, and knowing how the switch FRSW works, it's now just
as easy to configure the routers:


S2#
int s0/0.101 point-to-point
  frame-relay interface-dlci 101

S3#
int s0/0.101 point-to-point
  frame-relay interface-dlci 101

S4#
int s0/0.101 point-to-point
  frame-relay interface-dlci 101

HUB1#
int s0/0.202 point-to-point
  frame-relay interface-dlci 202
int s0/0.303 point-to-point
  frame-relay interface-dlci 303
int s0/0.404 point-to-point
  frame-relay interface-dlci 404


And, on the switch:

FRSW#
frame-relay switching

int s2
  frame-relay route 101 interface s1 202

int s3
  frame-relay route 101 interface s1 303

int s4
  frame-relay route 101 interface s1 404

int s1
  frame-relay route 202 interface s2 101
  frame-relay route 303 interface s3 101
  frame-relay route 404 interface s4 101


Now, read the above configs carefully. Where's the difference? The
difference is that, with different (and more clever) DLCIs assignments,
each router has only a single DLCI and is identified with that one DLCI to
all the other routers. The only difference is in how DLCIs are chosen (and
the different configs that follow).
Whereas before each router was thinking in terms of "source" DLCIs, now each
router must think in terms of "destination" DLCIs. As you will realize if
you think about it for a moment, this is just a "mental" (or conceptual)
difference, since the actual logic used by the routers is exactly the same
(since the DLCIs assigned to each VC are still unique, each router has no
choice but to use that DLCI). The difference is that, before, a router was
sending packets on a particular VC using a "source" DLCI, whereas now each
router send packets on a particular VC using a "destination" DLCI. As I
said before, this is only a conceptual difference, since the routers are
not aware in any way of the meaning of the DLCI they are using; they just
use it. It's the way DLCI are assigned (by humans :-)) that makes
them "source" or "destination", "local" or "global".
But, from the network's perspective, the whole system works *exactly* the
same in both cases, and, in particular, DLCI are still "locally"
significant (ie, only between each router and the switch).

I perfectly know that I did not directly answer your original question, but
I hope that the above will help you set up a FR lab with more awareness of
what goes on behind the scenes. You were trying to use only two routers and
the lab was (sort of) working, but, as you hopefully know by now, to set up
a proper FR lab you'll need at least THREE routers (one being the switch).

Regards


Re: Setting up a lab for frame relay?

Quoted text here. Click to load it

Many thanks for the very detailed answer, I do now understand the
concept of global DLCIs and how the assignment (& consequent
configuration) can make a more understandable schema. I have managed to
also configure my 3 routers correctly to replicate frame relay but I am
far from 100% on the configuration & it took me quite a while to figure
everything out correctly. I suppose this is why the CCNA is such a
valuable qualification to have.

Jase

Site Timeline