convention for frame relay diagrams

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

Threaded View


Hi,



I've done the CCNA and am working on the CCNP bcran exam and I've got one
major issue that steadfastly refuses to go away!  When looking at diagrams
of a frame relay network there appears to be no consistency in where the
DLCI is drawn on the diagram. Sometimes the DLCI written above a link seems
to mean the local dlci, whereas at other times it's the other ends DLCI.



For example



frame-relay map ip 10.10.12.2 200 broadcast cisco



Sometimes has a diagram with the 200 drawn next to the 10.10.12.2 router, at
other times the 200 is on the other side.



This is an issue that I've have for months and I'm getting nowhere.  Am I
just stupid or is there no set convention?



Yours confused.

Paul








Re: convention for frame relay diagrams


It should be the local dlci. The DLCI is only significant between the
router and frame relay switch. The frame relay switch should do the
rest in getting your packet to the correct destination. In theory you
could have the same DLCI number for both the local and remote
connection.

In your example and the diagram below. The frame map on R1 would be

frame-relay map ip 10.10.12.2 200 broadcast

              200                              100    
     R1------------------ FR SW-------------------- R2
10.10.12.1                                     10.10.12.2

This means to get to the remote IP 10.10.12.2 use the local DLCI 200.
Think of the 200 as a departure gate in an airport where you are
catching a flight to get to somewhere with address 10.10.12.2.

On R2 you would have

frame-relay map ip 10.10.12.1 100 broadcast


In a BRI ISDN interface a dialer map is slightly different

dialer map ip 10.10.12.2  broadcast 5551111111

In this case the dial string  5551111111 is the telephone number of
the remote end and not the local telephone number.

Beez


On Sat, 12 Mar 2005 12:33:21 -0000, "John Smith"

Quoted text here. Click to load it



Re: convention for frame relay diagrams


Breezneez,

Many thanks for taking the time to explain + draw the diagrams, it's really
helped clear things up for me.

Regards,
Paul.



Quoted text here. Click to load it




Re: convention for frame relay diagrams



Quoted text here. Click to load it
Paul

You will be well aware that a DLCI is local to an interface.

i.e.

Site A - DLCI 16 --FR Cloud -- DLCI 16 Site B
Site A - DLCI 17 --FR Cloud -- DLCI 16 Site C

Site A uses 16 to reach Site B
Site B uses 16 to reach Site A
Site A uses 17 to reach Site C
Site C uses 16 to reach Site A

The above is a standard addressing scheme and you would see the DLCI's on
the outgoing link on the diagram.


There is another concept used to simplify understanding the destination of
PVC's called global addressing.  This is just a conceptual addressing and
does not make frame-relay addressing work any different. It just means the
DLCI's are picked intelligently and not just sequentially.

For this we allocate each site an id.

i.e.
Site A = 101
Site B = 102
Site C = 103

We then use the DLCI number of the site we intend to connect to.

Site A - DLCI 102 --FR Cloud -- DLCI 101 Site B
Site A - DLCI 103 --FR Cloud -- DLCI 101 Site C

Site A uses 102 to reach Site B
Site B uses 101 to reach Site A
Site A uses 103 to reach Site C
Site C uses 101 to reach Site A

You could still label the DLCI on the outgoing link but now as you know that
all DLCI 101 go to Site A, all DLCI 102 to site B etc. you can just label
the site instead.

Regards

Toby





Re: convention for frame relay diagrams


Toby,

Thanks very much to yourself also.  I understand the concepts that you've
put across, much appreicated!  It's been confusing me for a good while now.

Regards,
Paul.



Quoted text here. Click to load it




Re: convention for frame relay diagrams



Quoted text here. Click to load it


In the real world you may have no control of what DLCI you have to
use. You just have to use the one given to you by the frame switch at
your service provider.

In a typical hub and spoke setup in a lab environment where you have
greater control it is common to set up the DLCIs as follows (sorry for
crude diagram)



                         10.0.0.2
                             R2
                           |      |
                   201  |      |  203
                           |      |
                           |      |
                  ___ FR SW___
                  |                       |    
          102  |                       |  302
                  |                       |
                R1                   R3
            10.0.0.1           10.0.0.3


R2 is hub and has reachability to both R1 and R3 via 2 pvcs with DLCIs
201 and 203. R1 and R3 are spokes and have only reacability to R2. To
reach each other they have to go via R2. By looking at the first and
last digit of the DLCI you can see source and destination router
(taking into account that R1 and R3 are spokes).

On R2 you would have the following maps

frame-relay map ip 10.0.0.1 201  
frame-relay map ip 10.0.0.3 203

On R1 and R3 everything has to go via the 1 DLCI

R1
frame-relay map ip 10.0.0.2 102
frame-relay map ip 10.0.0.3 102

R3
frame-relay map ip 10.0.0.2 302
frame-relay map ip 10.0.0.1 302

To have a fully meshed network you would create another 2 PVCs for R1
to talk to R3 ie DLCI 103 and R3 to talk to R1 ie 301. R1 and R3 would
now look like

R1
frame-relay map ip 10.0.0.2 102
frame-relay map ip 10.0.0.3 103

R3
frame-relay map ip 10.0.0.2 302
frame-relay map ip 10.0.0.1 301

Beez


Re: convention for frame relay diagrams


Beez,

Thanks, I'm really please I posted now as this is really clearing up some of
my confusions.  One think I'm still slightly unsure of is point-to-point vs
multipoint. Can you help out at all?  In the sybex book it says something
along the lines, "multipoint is used when all ip's are in the same subnet,
point-to-point when they each have their own subnet" (cisco press book is
more cryptic!). I'm not clear though on what is actually happening on a
multipoint config. the packets still have to go via the hub router, right? I
can't work out what the fundamental difference between the two is.  Also do
all routers in the network  have to run the same? ie all multipoint or all
point-to-point?  Does the split horizion issue affect both multipoint and
point-to-point?

Regards
Paul

Quoted text here. Click to load it







Re: convention for frame relay diagrams


Hi

It's not easy to understand and takes years to fully master. I
wouldn't consider myself an expert on it yet and it's difficult to
explain in one posting but I enjoy writing about it and can learn from
it. As I said I am not an expert and I may have got something wrong
here

A multipoint interface is an interface that can be used to connect
multiple end points in the same IP subnet in a network.

If you look at the following diagram. 4 routers R1 is hub and R2 R3
and R4 spokes.


                          10.0.0.1/8
                    _____ R1____
                    |          |           |
                  102     103     104
                    |__      |      __ |
                ______ FR SW______
                |              |                |              
              201         301            401
                |              |                |
               R2          R3             R4
         10.0.0.2/8  10.0.0.3/8  10.0.0.4/8

R1 has reachability to all spokes via 3 pvcs with DLCIs 102,103 & 104
(Remember DLCIs are identifiers for layer 2 pvcs).
All routers are in the same subnet 10.0.0.0/8. There is more than 1
way of configuring this but to demonstrate we can create multipoint
interfaces on all routers.You can create multipoint interfaces in 2
ways. By definition the physical interface is a multipoint interface
or you can use a multipoint sub-interface.

So on R1 we could have configured it directly on the Serial 0
interface

interface s0
    ip address 10.0.0.1 255.0.0.0
    encapsulation frame-relay
    frame-relay map ip 10.0.0.2 102 broadcast
    frame-relay map ip 10.0.0.3 103 broadcast
    frame-relay map ip 10.0.0.4 104 broadcast

or with a sub-interface

interface s0
    encapsulation frame-relay

interface s0.1 multipoint
    ip address 10.0.0.1 255.0.0.0
    frame-relay map ip 10.0.0.2 102 broadcast
    frame-relay map ip 10.0.0.3 103 broadcast
    frame-relay map ip 10.0.0.4 104 broadcast

On R2, R3 and R4 the configuration will be similar.
R2
interface s0
    ip address 10.0.0.2 255.0.0.0
    encapsulation frame-relay
    frame-relay map ip 10.0.0.1 201 broadcast
    frame-relay map ip 10.0.0.3 201  
    frame-relay map ip 10.0.0.4 201  

If we now change the diagram and make R4 in a different subnet
50.0.0.0/8

                       S0.1 10.0.0.1/8
             S0.2 50.0.0.1/8
                    _____ R1____
                    |          |           |
                  102     103     104
                    |__      |       _ |
                ______ FR SW______
                |              |                |              
              201         301            401
                |              |                |
               R2          R3             R4
         10.0.0.2/8  10.0.0.3/8  50.0.0.4/8

With multipoint we now have a problem. The obvious problem is how are
we going to define 2 separate subnets on the same interface. The other
problem is split horizon. Split horizon is used with routing protocols
to prevent loops. Split horizon says do not advertise a route out the
same interface you received it from or think of it as don't tell the
same joke to the person you first heard it from :o). So if there are
networks behind R4 and R4 tells R1 about them R1 is not able to tell
R2 and R3 since it is trying to tell them out the same interface that
it first heard about them from R4.

To get around this we can create another sub-interface. In this case
since there are only 2 end points we can create a point-to-point
sub-interface

R1 would now be

interface s0
    encapsulation frame-relay

interface s0.1 multipoint
    ip address 10.0.0.1 255.0.0.0
    frame-relay map ip 10.0.0.2 102 broadcast
    frame-relay map ip 10.0.0.3 103 broadcast
    
interface s0.2 point-to-point
    ip address 50.0.0.1 255.0.0.0
    frame-relay interface-dlci 104

With point-to-point you just have to tell it what DLCI to use with the
command "frame-relay interface-dlci <dlci>" and do not need to define
any frame-relay maps since this is a point-to-point interface and
their is only 1 neigbour that it is going to reach.

R4 will now be configured as

interface s0
    encapsulation frame-relay

interface s0.1 point-to-point
    ip address 50.0.0.4 255.0.0.0
    frame-relay interface-dlci 401

R4 is just sending everything to R1 via DLCI 401. On R1 we now have 2
logical interfaces so we do not have the problem of split horizon
since R1 is receiving the routing updates from R4 via s0.2 and sending
them out to R2 and R3 via s0.1.

As I said in the beginning their are many ways to configure it. If you
look at the first diagram


                          10.0.0.1/8
                    _____ R1____
                    |          |           |
                  102     103     104
                    |__      |      __ |
                ______ FR SW______
                |              |                |              
              201         301            401
                |              |                |
               R2          R3             R4
         10.0.0.2/8  10.0.0.3/8  10.0.0.4/8

Another way is just to configure point-to-point sub-interfaces on R2,
R3 and R4 and keep a multipoint on R1. This would work OK

R2
interface s0.1 point-to-point
    ip address 10.0.0.2 255.0.0.0
    frame-relay interface-dlci 201

R3
interface s0.1 point-to-point
    ip address 10.0.0.3 255.0.0.0
    frame-relay interface-dlci 301

R3
interface s0.1 point-to-point
    ip address 10.0.0.4 255.0.0.0
    frame-relay interface-dlci 401

R1
interface s0.1 multipoint
    ip address 10.0.0.1 255.0.0.0
    frame-relay map ip 10.0.0.2 102 broadcast
    frame-relay map ip 10.0.0.3 103 broadcast
    frame-relay map ip 10.0.0.4 104 broadcast

In the second diagram with the 2 separate subnets you could use 2
multipoint interfaces on R1. This wouldn't be a problem either


                       S0.1 10.0.0.1/8
             S0.2 50.0.0.1/8
                    _____ R1____
                    |          |           |
                  102     103     104
                    |__      |      __ |
                ______ FR SW______
                |              |                |              
              201         301            401
                |              |                |
               R2          R3             R4
         10.0.0.2/8  10.0.0.3/8  50.0.0.4/8
R1
interface s0.1 multipoint
    ip address 10.0.0.1 255.0.0.0
    frame-relay map ip 10.0.0.2 102 broadcast
    frame-relay map ip 10.0.0.3 103 broadcast
    
interface s0.2 multipoint
    ip address 50.0.0.1 255.0.0.0
    frame-relay map ip 50.0.0.4 104 broadcast

and on R4 we can use a point-to-point or multipoint sub-interface with
just one frame-relay map defined

R4
interface s0.1 point-to-point
    ip address 50.0.0.4 255.0.0.0
    frame-relay interface-dlci 401

or

interface s0.1 multipoint
    ip address 50.0.0.4 255.0.0.0
    frame-relay map ip 50.0.0.1 401 broadcast

As you can see there are many ways of doing it but just think if you
are connecting to more than one end node in the same IP subnet
use a physical or multipoint sub-interface and if its directly
connected to one end-node use a point-to-point sub-interface.

I have not mentioned much about routing protocols like OSPF in a frame
relay environment here but you have take these into consideration also
depending on the type of interface you are using. This is the next
difficult thing about frame relay. If you found this interesting and
anybody would like me to write something about OSPF and frame relay
please let me know.

Beez
On Sun, 13 Mar 2005 16:13:26 -0000, "John Smith"

Quoted text here. Click to load it



Re: convention for frame relay diagrams


Given the issue of split horizon, and the fact that the carrier's network is
actually supplying multiple point-to-point links (PVCs) rather than a true
"shared medium", can anybody think of a good reason for using multipoint
configuration instead of point-to-point?  The only thing that remotely comes to
mind is that you can save on the number of subnet numbers needed for WAN
addressing by sticking it all in one subnet, which when slicing up a "10" seems
kinda lame.



Re: convention for frame relay diagrams



Quoted text here. Click to load it


I agree that in the real world, in my experience, most people just use
point-to-point links.

I guess their is no real good reason for using a multipoint interface.
It's neater, quicker to setup and easier to manage if you have many
spoke connections and save on some subnet numbers as you mentioned but
other rhan that its easier just to stick with point-to-point.

Beez



Re: convention for frame relay diagrams



Quoted text here. Click to load it
Sometimes split horizon rules can be usefull on a network where all traffic
supposed to only pass between remote sites and head office. A multipoint set
up here can simplify the set up and as you have already said only requires
one subnet to achieve this.

I have read somewhere (on the web I think) that subinterfaces were invented
because frame-relay configured on an interface only operated as a multipoint
setup only. Sub-interfaces allowed the point-point approach each with their
own subnet and evaded the split horizon problem. The multipoint
sub-interface was included so you could mix and match and have some remote
sites able to communicate with other remote sites along with other sites
which were not allowed to talk to each other if on the same multipoint
segment (sub-interface) but could still talk to sites on the other
point-point sub-interfaces or other multipoint sub-interfaces.  All this
means is flexibility in design. Cisco gets A+ for this.

i.e.

Site1 -------Site 2 point-point

          |--------Site 3
Site1  |--------Site 4    Multipoint
          |--------Site 5

Site 1 |--------Site 6
          |--------Site 7   Multipoint

(dependent on routing protocols/router config)
Site 1 and Site 2 can talk to all other sites via site 1.
Site 3,4,5 can only talk to sites 1,2,6 & 7 (site 2,6 & 7 via site 1)
Site 6 & 7 can talk to all other sites except eachother via site 1

I am not saying the above is a typical arrangement, just a simple
explanation of what can be achieved. In fact Policy based routing is more
common than this approach.

Toby




Re: convention for frame relay diagrams



Quoted text here. Click to load it

Forgot to mention that the OSPF routing protocol can get round the split
horizon rule with certain configurations by treating the frame-relay network
in a multi-point setup is special ways to prevent routing loops, it depends
totally on the setup of the frame relay setup, i.e fully meshed, partially
meshed, hub/spoke and the router's configs. Apart from that I would have to
get my books out as I only have real experience with OSPF and frame-relay
with point-point links.

Toby




Re: convention for frame relay diagrams


Beezneez,

Many many thanks for the replies. At the moment I'm overwhelmed by the
responses and it's going to take me a couple of days to get my head around
this stuff.  Thanks very much to everyone that has chipped in for their
comments and help, I'm incredibly grateful.

Regards
Paul.

Quoted text here. Click to load it




Re: convention for frame relay diagrams


Let's take the questions apart one at a time

Quoted text here. Click to load it

True, any remote-to-remote traffic passes through via the hub router.  Think
of them as being on a "shared medium".  It's a layer 2 (data-link - DLCI -
see the connection?) issue (start thinking in terms of the 7-layer protocol
model - we're working with the bottom 3 layers here)

Quoted text here. Click to load it

No.  This is one of the beauties of something called "sub-interfaces" on
Cisco serial interfaces.  Subinterfaces allow you to subdivide a physical
serial interface into logical sub-interfaces, and those subinterfaces can be
configured with their own DLCI's (as assigned by the frame switch).  On
routers with multiple serial interfaces, one can be running both a
multipoint subinterface and a point-to-point subinterface, while the other
serial interface runs a purely point-to-point interface.  Study your
configuration examples for those sorts of combination interfaces.  (the
routers on the same multipoint circuits have similar interface
configurations, point-to-multipoint)

Quoted text here. Click to load it

Split horizons affect multipoint circuits because a router cannot broadcast
a routing update out of the same interface (or subinterface) that it
received the update from.  This is a problem in multipoint circuits, because
it means that one of the remote routers will not receive a routing update
from another remote router via the hub router.  There is a solution, and
you'll probably be studying that solution soon (if you haven't discovered it
already)

Quoted text here. Click to load it




Re: convention for frame relay diagrams


Beezneez wrote:
[..]
Quoted text here. Click to load it

Actually, I found that both the carriers I dealt with in my last job (MCI aka
Worldcomm and Sprint) were more than willing to work with us on DLCI number
assignment.  We used a system similar to the one described, where the DLCI
number would always correspond to the remote site.  In fact, we went one step
further, and used the same number for a site's local ethernet subnet number, the
subinterface to it from the central site's router, and the DLCI.  This meant
that only one unique number had to be tracked for each remote.  For example,
S0/1:0.120 on the home office router might be connected to DLCI 120, which would
get you to the Houston branch office, which would have a local subnet of
10.1.120.0/24.  Remote sites were all configured to use DLCI 100 on S0.100 to
reach home.  Only problem with this is that it tends to disguise the fact that
the DLCI truely is a local number, which can get you in trouble if you forget.
You still have to configure BOTH local ends of the PVC, and be sure the carrier
knows which end you want with which number when adding.



Re: convention for frame relay diagrams




Quoted text here. Click to load it
Although this is possibly true of some service providers, The ones I have
had contact with will allow the customer to select the DLCI's as they are
local to the interface so have no detrimental effect to the service
provider.

Quoted text here. Click to load it
This is a simular approach to the global address scheme I described but uses
source/destination site numbers.  It is more useful though in a lab as it
doesn't scale to a large number of sites.  It could also be usefull in a
private frame-relay network where it could be usefull to tell at a glance
from the frame-relay switch which site an interface connects just by looking
at the DLCI's of the PVC's on the interface (some switches including Cisco's
MGX range don't allow descriptions on the interface). In the SP world though
you wouldn't need the source site number in the dlci as there would be
multiple customers all with at least a site 1 and 2 and maybe using
different addressing conventions aswell. As for the customer themselves
viewing PVC's from their own router's they would already know the source
site as the router would be located there so a better approach here would be
just to use the destination site number. N.B. as DLCI 1-15 and 1023 are
reserved I recomend the following convention.

Site number +100
Destination Site 1-99 = 101-199
Destination Site 100-199 = 200-299

This method would scale to large networks, theoretically 922 sites although
I feel the practical limit would be a lot lower than this. There also would
be a cost deficit as each PVC in the network costs money.  If you have just
100 sites fully meshed with PVC's you would need 4950 PVC's the formula to
work this out is.

n * (n-1)
---------
     2

where n = number of sites.

For this reason most companies use an hub and spoke method where only the
main site (site 1) connects to all other sites, or a partial mesh where they
use an hub/spoke and also pvc's between other sites dependent on sufficient
traffic loadsto justify them. A standard hub/spoke setup on a 100 site
network would require just 99 PVC's but if redundency is used then this
could be increased to 198 (2 routers at main site connected to all other
sites). Either way substantially less than the 4950 needed for a fully
meshed setup.

Toby




Re: convention for frame relay diagrams


John Smith wrote:
Quoted text here. Click to load it

I'm sure everyone will chime in to tell you that DLCIs are locally
significant.  And that's true.  But there is something called "global
DLCIs" or "global routing DLCIs"

Think of it this way.  DLCIs are exit numbers on a freeway.  If it's a
local DLCI it signifies the on ramp number.  If it's a global DLCI, it
signifies the exit ramp number.  Either way, you're going to your
destination!

--

hsb


"Somehow I imagined this experience would be more rewarding" Calvin
**************************ROT13 MY ADDRESS*************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************


Site Timeline