convention for frame relay diagrams


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 200 broadcast cisco

Sometimes has a diagram with the 200 drawn next to the 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.


Reply to
John Smith
Loading thread data ...

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 200 broadcast

200 100 R1------------------ FR SW-------------------- R2

This means to get to the remote IP 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

On R2 you would have

frame-relay map ip 100 broadcast

In a BRI ISDN interface a dialer map is slightly different

dialer map ip broadcast 5551111111

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


Reply to


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


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.



Reply to


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

Regards, Paul.

Reply to
John Smith


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.

Reply to
John Smith

Beezneez wrote: [..]

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 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.
Reply to
Mike Dorn

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) R2 | | 201 | | 203 | | | | ___ FR SW___ | | 102 | | 302 | | R1 R3

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 201 frame-relay map ip 203

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

R1 frame-relay map ip 102 frame-relay map ip 102

R3 frame-relay map ip 302 frame-relay map ip 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 102 frame-relay map ip 103

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


Reply to


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

Reply to
John Smith


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. _____ R1____ | | | 102 103 104 |__ | __ | ______ FR SW______ | | | 201 301 401 | | | R2 R3 R4

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 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 encapsulation frame-relay frame-relay map ip 102 broadcast frame-relay map ip 103 broadcast frame-relay map ip 104 broadcast

or with a sub-interface

interface s0 encapsulation frame-relay

interface s0.1 multipoint ip address frame-relay map ip 102 broadcast frame-relay map ip 103 broadcast frame-relay map ip 104 broadcast

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

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

S0.1 S0.2 _____ R1____ | | | 102 103 104 |__ | _ | ______ FR SW______ | | | 201 301 401 | | | R2 R3 R4

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 frame-relay map ip 102 broadcast frame-relay map ip 103 broadcast interface s0.2 point-to-point ip address 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 " 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 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 _____ R1____ | | | 102 103 104 |__ | __ | ______ FR SW______ | | | 201 301 401 | | | R2 R3 R4

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 frame-relay interface-dlci 201

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

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

R1 interface s0.1 multipoint ip address frame-relay map ip 102 broadcast frame-relay map ip 103 broadcast frame-relay map ip 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 S0.2 _____ R1____ | | | 102 103 104 |__ | __ | ______ FR SW______ | | | 201 301 401 | | | R2 R3 R4 R1 interface s0.1 multipoint ip address frame-relay map ip 102 broadcast frame-relay map ip 103 broadcast interface s0.2 multipoint ip address frame-relay map ip 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 frame-relay interface-dlci 401


interface s0.1 multipoint ip address frame-relay map ip 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 menti>Beez,

Reply to

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.

Reply to
Mike Dorn

Let's take the questions apart one at a time

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)

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)

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)

Reply to
Eric Louie

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!

Reply to
Hansang Bae

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.


Reply to

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.

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.


Reply to

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.


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.


Reply to

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.


Reply to


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.

Reply to
John Smith Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.