Local Significance of DLCI

I think I can actually answer this! CBTNuggets video explained this fairly well for me, and I'll use Jeremy's analogy, which is to think of the topology as 4 airports; one in NY, one in FL, etc. You are the data, and the airplane flight-paths are the connections.

The DLCI is only locally significant; data(you) getting on an airplane in FL at gate 300 is only relevant in FL. NY doesn't care what gate you used in FL. NY only cares what gate you would use to get back to FL, which wouldn't be 300 (well it could). Similarly Texas' gate 300 to NY is completely different than FL's gate 300, and NY cares about neither. NY might have gate 301 TO florida and gate 302 to texas, and would put passengers(data) to the appropriate gate to get to those destinations.

blackninja

You could have 300 for all the spoke routers but you don't have the DCLIs for the hub to the spokes

You would need another 3 DLCI from NY to map to the others i.e. 102, 103 & 104.

I try to name my DLCIs in a form easy to understand i.e. 102 - goes from router 1 to router 2 etc..

For the spokes I would use 201, 301,& 401 - stops your head from exploding

Hopes this helps, if only a little.

megatran808

bermovick wrote: »

I think I can actually answer this! CBTNuggets video explained this fairly well for me, and I'll use Jeremy's analogy, which is to think of the topology as 4 airports; one in NY, one in FL, etc. You are the data, and the airplane flight-paths are the connections.

The DLCI is only locally significant; data(you) getting on an airplane in FL at gate 300 is only relevant in FL. NY doesn't care what gate you used in FL. NY only cares what gate you would use to get back to FL, which wouldn't be 300 (well it could). Similarly Texas' gate 300 to NY is completely different than FL's gate 300, and NY cares about neither. NY might have gate 301 TO florida and gate 302 to texas, and would put passengers(data) to the appropriate gate to get to those destinations.

Gotta love Jeremy's explanation on CBT nuggets. Couldn't have explained it better!

bermovick wrote: »

NY only cares what gate you would use to get back to FL, which wouldn't be 300 (well it could). Similarly Texas' gate 300 to NY is completely different than FL's gate 300, and NY cares about neither. NY might have gate 301 TO florida and gate 302 to texas, and would put passengers(data) to the appropriate gate to get to those destinations.

But won't the WAN switch look at the DLCI of 300 in the incoming LAPF heard and realize that all spokes have a DLCI of 300...?

The way I am thinking about it is...NY has a packet to sent to FL. So it puts 300 in the LAPF header, then sends it out across its access-link to its WAN switch. Here's where I get confused... when the WAN switch seens DLCI 300 in the header...doesn't the WAN switch realize that there are 3 locations with 300 as a DLCI? How does it choose the right PVC to send it out...?

This is why I think this way:

I am reading in the Odom ICND2 Book, and it says "The sender treats the DLCI as a destination address, using the destinations global DLCI in the header" P.472

Jeremy said a lot of people getting confused by this, and I think that's what's happening. Those 300's aren't for the NY->wherever direction, they're for the wherever->NY direction. 300 is NY's destination dlci for all 3 senders.

[edit] messed up quote rather than reply & horribly mangled it

bermovick wrote: »

Jeremy said a lot of people getting confused by this, and I think that's what's happening. Those 300's aren't for the NY->wherever direction, they're for the wherever->NY direction. 300 is NY's destination dlci for all 3 senders.

[edit] messed up quote rather than reply & horribly mangled it

Everything seems to make sense when DLCIs at the various locations are all different...which is how the examples in the textbook are...but I am trying to understand how the same process works when certain DLCIs are the same. I just can't understand the logic of the WAN Switch upon receiving a frame from NY and destined for FL.

If FL had a DLCI of 500, then NY would send the frame to the WAN switch with a DLCI address of 500. That makes sense. Just doesn't click when all destinations have the same DLCI. To me, it goes against the idea of local significance. Man I am confused!

It will have 3 DLCI's for the 3 remote sites. None of those 3 can match (each other), for the reasons you'd stated. It could also have a 300 to FL if you really want to blow your mind, but like you said it couldn't have another 300 to TX because then the frame-relay switch wouldn't know what to do.

bermovick wrote: »

It will have 3 DLCI's for the 3 remote sites. None of those 3 can match (each other), for the reasons you'd stated. It could also have a 300 to FL if you really want to blow your mind, but like you said it couldn't have another 300 to TX because then the frame-relay switch wouldn't know what to do.

Oh! So the WAN Switch must be configured with certain mappings?

Yes, assuming my notes are correct. When you set up the interface or sub-interface you list the DLCI # as well as the remote host's IP address.

Forgive the crudeness of my drawing; I didn't have time to make it to scale (bad back to the future reference):

http://midkemia.dyndns.org/images/FR.gif
(give me a moment to upload it. Also let me know if it doesn't work. I can't test my webserver well from inside the LAN)

bermovick wrote: »

Yes, assuming my notes are correct. When you set up the interface or sub-interface you list the DLCI # as well as the remote host's IP address.

Forgive the crudeness of my drawing; I didn't have time to make it to scale (bad back to the future reference):

http://midkemia.dyndns.org/images/FR.gif
(give me a moment to upload it. Also let me know if it doesn't work. I can't test my webserver well from inside the LAN)

Hey thanks for the reply

I can't get the image though...

Not Found

The requested URL /images/FR.gif was not found on this server.
Apache/2.2.15 (Debian) Server at midkemia.dyndns.org Port 80

Yeah, my box was running slow. It's up now.

bermovick wrote: »

Yeah, my box was running slow. It's up now.

Thanks!

I added a few things to it to help explain my confusion...

Assuming that NY uses DLCIs of 310, 301 and 302...

...then what is the point of NY putting 300 in the DLCI header when it forwards a frame to its WAN Switch..?

...the wan switch will see DLCI 300, and realize it has 3 routes to DLCI 300...not 1.

FR.JPG

NY doesn't have a 300 DLCI; it has a 301, 302 and 310 and will put the appropriate # that matches that destination.

TX, FL and ... lol whatever the 3rd one was all have a 300 DLCI. If they get data for NY they put it on flight 300 because 300's destination is NY for each of them. It's not bi-directional though; NY can't put data back out on the 300 it came in on; it has to have a separate way to send data back; it's own DLCI tables (301, 302, 310)

Update: the 'thought bubble' was the closest thing MS-Paint had to a 'cloud' hehe.

[EDIT]: Not sure how you inserted the thumbnail into your post. Here's an updated one with labels and such. Hopefully it will help to show that NY has no clue about the 300's.

bermovick wrote: »

TX, FL and ... lol whatever the 3rd one was all have a 300 DLCI. If they get data for NY they put it on flight 300 because 300's destination is NY for each of them. It's not bi-directional though; NY can't put data back out on the 300 it came in on; it has to have a separate way to send data back; it's own DLCI tables (301, 302, 310)

What you're saying makes complete sense. If FL has data for NY, the DLCI header will be 300. And if TX has data for NY, the DLCI will also be 300 because that is the DLCI of their respective interfaces. You are saying that the DLCI will match the sending routers local DLCI, which works when I look at the example.

But I read something totally opposite in my ICND2 book...

It says

"The sender treats the DLCI as a destination address, using the destinations global DLCI in the header."

To me this means that if FL wants to send data to NY, it will use NYs DLCI of 310, sine this is the destination DLCI and it will not use 300.

What am I missing...

But Florida doesn't know about NY's 301; it only knows it's routing table (telling it what interface that gets sent out) and the frame-relay map (telling it what the destination DLCI is). That's why it's only locally significant, since it's only used/known by the sending router (and I suppose the frame-relay switch, but now we're getting into an area I don't know)

[edit]: I may have worded this poorly & stuff (bringing up routing tables). I'm not certain, as I'm leaving the boundaries of what I know around this point!

typesh: if it helps, think of a DLCI as a MAC address -- locally significant between the router and the FR switch.

"The sender treats the DLCI as a destination address, using the destinations global DLCI in the header."

That is probably referring to the destination (EXIT) interface.

bermovick wrote: »

But Florida doesn't know about NY's 301; it only knows it's routing table (telling it what interface that gets sent out) and the frame-relay map (telling it what the destination DLCI is).

Doesn't this seem a little bit opposing though...? Like you said, FL doesn't know about NY's 301, but the frame-relay map tells it the destination DLCI.... Check out my textbook example below...

fly351 wrote: »

[/I]That is probably referring to the destination (EXIT) interface.

I was thinking that too...

But here is a picture of the example in my text.

Consider the example when Mayberry sends to Mount Pilot. Notice that the DLCI When Frame Is Sent column is actually 52. Which is the DLCI of Mount Pilot, and not of Mayberry. This is where the airport example you mentioned kinda falls apart for me...since the frame leaves with DLCI address of 52...not 51.

Notice when Mayberry sends to Raleigh the DLCI When Frame Is Sent is actually 53 this time. So it appears the the DLCI address is that of the next router.

This example in the text makes sense only because all Routers use a different DLCI. Now suppose that Mount Pilot had a DLCI of 400, and Raleigh also had a DLCI of 400. Based on the table's logic and following the example from the text, when Mayberry wanted to send to Mount Pilot, the DLCI When Frame Is Sent would read 400. Also when Mayberry wanted to sent to Raleigh, the DLCI When Frame Is Sent would also be 400.

Going crazy...

FrameRelay.JPG

I've flipped forward to the book where it discusses frame relay and am looking at the picture you've put above, and the surrounding text and this totally contradicts what CBTNuggets covered with it's section on frame relay.

OK scratch what I was going to say. I've done some google searches and I think I see the problem. CBTNuggets covers Local Significance Addressing, while this book is discussing Global Significance Addressing. I'm not going to read up on the differences in details right now since book-wise I've just started, but I'm going to bookmark this link so I can check it out later.

bermovick wrote: »

I've flipped forward to the book where it discusses frame relay and am looking at the picture you've put above, and the surrounding text and this totally contradicts what CBTNuggets covered with it's section on frame relay.

OK scratch what I was going to say. I've done some google searches and I think I see the problem. CBTNuggets covers Local Significance Addressing, while this book is discussing Global Significance Addressing. I'm not going to read up on the differences in details right now since book-wise I've just started, but I'm going to bookmark this link so I can check it out later.

Thanks bermovick!

I'm gonna do some digging on the Local vs. Global.

I'm also gonna re-read these chapters. I'll post if I get it sorted out. Let me know if you come up with anything as well!

typesh wrote: »

Doesn't this seem a little bit opposing though...? Like you said, FL doesn't know about NY's 301, but the frame-relay map tells it the destination DLCI.... Check out my textbook example below...

I was thinking that too...

But here is a picture of the example in my text.

Consider the example when Mayberry sends to Mount Pilot. Notice that the DLCI When Frame Is Sent column is actually 52. Which is the DLCI of Mount Pilot, and not of Mayberry. This is where the airport example you mentioned kinda falls apart for me...since the frame leaves with DLCI address of 52...not 51.

Notice when Mayberry sends to Raleigh the DLCI When Frame Is Sent is actually 53 this time. So it appears the the DLCI address is that of the next router.

This example in the text makes sense only because all Routers use a different DLCI. Now suppose that Mount Pilot had a DLCI of 400, and Raleigh also had a DLCI of 400. Based on the table's logic and following the example from the text, when Mayberry wanted to send to Mount Pilot, the DLCI When Frame Is Sent would read 400. Also when Mayberry wanted to sent to Raleigh, the DLCI When Frame Is Sent would also be 400.

Going crazy...

Just woke up so my brain is still in shutdown... but I think you guys need to look into the difference between Point-to-Point, Hub-and-Spoke, and Multi-point.

From what it sounds, I think you guys are jumping into the harder material without gaining the full concept. With that said, I will explain more later once I wake up lol.

edit: can both of you tell me which layer Frame operates at?

fly351 wrote: »

From what it sounds, I think you guys are jumping into the harder material without gaining the full concept. With that said, I will explain more later once I wake up lol.

Thanks!

fly351 wrote: »

edit: can both of you tell me which layer Frame operates at?

I understand FR to work at the data-link layer...

Edit:

I found the following at this link: https://supportforums.cisco.com/message/3106562

The difference between Global and Local DLCI in FR network is DLCIs are of local significance, unless an agreement has been made with the network service provider to deploy global DLCIs. Local significance means that DLCIs are of use only to the local Frame Relay network device.

The use of global DLCIs requires that they each be preassigned. (Typically, the assignments are negotiated between the customer and the network service provider.) In addition, each DLCI can be used only once throughout the network. (If two sites had the same DLCI, the network would not know which termination site was the intended destination.) The Frame Relay switch within the network service providers network will have tables that route the traffic between each origination and termination pair.

Notice it says that when using Gloabal DLCIs, each can only be used once throughout the network. This concept makes sense to me, especially since this is explained in the ICND2 book. I can't seem to apply similar reasoning to a scenario when Local DLCIs are used (i.e. each spoke uses the same DLCI as each other spoke). Just like the above quote mentions, if two sites had the same DLCI, the network would not know which termination site was the intended destination... this is what I was thinking too. The SPs WAN switch would get a frame with DLCI header 300...and then notice that all 4 spokes use DLCI 300. So how would it overcome this issue when using Local DLCIs?

Ok, tell me if this example is better... I used static DLCI maps so that way you can see how the router will forward (instead of using IARP).

102 goes to 201
103 goes to 301

201 goes to 102
203 goes to 302

302 goes to 203
301 goes to 103

Check out this doc Cisco Frame Relay Configurations > Configuring Static and Dynamic DLCI to Network Layer Address Mapping

outrunred

WOW!

Can't wait to get stuck into this at the weekend.....crazy stuff

but I feel I have a head start just reading your posts....

my very basic understanding of DLCI's were to regard them as almost an ethernet address but for WAN's....just like a MAC address... and now I've just doubled my knowledge in 5 mins. reading your posts.

great site this, love it

fly351 wrote: »

Ok, tell me if this example is better... I used static DLCI maps so that way you can see how the router will forward (instead of using IARP).

102 goes to 201
103 goes to 301

201 goes to 102
203 goes to 302

302 goes to 203
301 goes to 103

Check out this doc Cisco Frame Relay Configurations > Configuring Static and Dynamic DLCI to Network Layer Address Mapping

Oh there's the image! It wasn't loading for some reason before. I am looking it over. I also found some more information on what we were discussing. I will post in a few mins.

Okay I had a read through the link fly351 posted, which is also illustrated in his diagram regarding the static mappings.

I also had a read through the Frame Relay Section of Todd Lammle's book. The issue is, I keep finding information in one source that seems to conflict with information in another source, and sometimes, information contained in the same source that quite honestly just seems to conflict with itself.

I'll illustrate what I mean with an example from Todd Lammle's book which has helped me understand Global DLCIs.

Page 802 of Lammle's CCNA book:

RouterA---DLCI 100----FRAME RELAY CLOUD----DLCI 200----RouterB

Here is what the text reads regarding the above topology:

"When RouterA wants to send a frame to RouterB, it looks up the IARP or manual mapping of the DLCI to the IP address it's trying to get to. Equipped with the DLCI, it then sends the frame out with the DLCI value it found in the DLCI field of the FR Header."

Okay, lets look at that for a second. Based on what I have learned in the ICND2 book by Odom, and the screenshots/table from the Odom book I put in Post #18 of this thread, the frame from RouterA will go out on the Access Link with a DLCI value of 200- not 100.

Here is where what appears to be conflicting information comes in (however this is probably just my misunderstanding):

Page 812 of Lammle using the same topology as before, but this time shows the IP Addresses and DLCI Maps:

RouterA 172.16.100.2---DLCI 100----FRAME RELAY CLOUD----DLCI 200----RouterB 172.16.100.1

As stated in the book, the correct configs for this to work are

RouterA# show run
interface s0/0
ip address 172.16.100.2 255.255 255.0
encap frame-relay
frame-relay map ip 172.16.100.1 100

RouterB#
interface s0/0
ip address 172.16.100.1 255.255 255.0
encap frame-relay
frame-relay map ip 172.16.100.2 200

The DLCI is that of itself!

Okay, so if based on Odom's book, the sender "treats the DLCI as the destination address," then why is the Router A map of 172.16.100.1 using 100 instead of 200. 200 is the destination DLCI of RouterB. Likewise, why is RouterB using a map of 200, when 100 is the DLCI of RouterA.

Now let's consider an example using Odom's book which shows the opposite of what is happening in Lammle's Book.

Page 492 and 496 of ICND2 by Odom:

Mayberry 192.1.1.1 DLCI 51 ----FRAME RELAY CLOUD----DLCI 52 Mount Pilot 199.1.1.2

Look at the frame-relay map commands on P. 496 that correspond to this example.

It reads:

Mayberry
interface s0/0/0
frame-relay map ip 199.1.1.2 52

Mount Pilot
interface s0/0/0
frame-relay map ip 199.1.1.1 51

The DLCI is that of the destination!

This example is contrary to the config in Lammle's book, the example fly351 posted, and the link on configuring Static maps. This is what is throwing me off. In one case the sending router uses the DLCI of the Destination, and in the other case the sending router uses the DLCI of itself as the destination. See my problem?

The same thing is shown in fly351's diagram. When Mayberry wants to reach Mount Pilot the map uses 102 instead of 201. This goes against the idea of what Odom says about treating the DLCI field as the destination. This idea is also present in the Lammle examples.

Just curious.. do you have packet tracer..?

I opened up the most simplest packet tracer file I had.

Convert 0x78 from hex to decimal and tell me what it says

r1
interface Serial0/0/0.120 point-to-point
ip address 172.30.0.5 255.255.255.252
frame-relay interface-dlci 120

r2
interface Serial0/0/0.210 point-to-point
ip address 172.30.0.6 255.255.255.252
frame-relay interface-dlci 210

Hey thanks!

No packet tracer.

But from your example, it looks like R1 uses a DLCI header of 120 [0x78]. Just as it should based on the config you posted underneath the image... Totally get that.

But, why is the Odom example different...? Why is his configuration using the other Router's DLCI?

You know what? I think a major part of what I was missing is how this is also configured at the WAN Switch! I am looking at the Lab in Todd Lammle's book (p. 840) which shows the WAN Switch being configured such that if it receives frames on PVC aaaa, then send them out interface Serial x/y/z using PVC bbbb.

This way the WAN switch can be configured so that whatever the incoming DLCI header is (in your example 120), then the WAN switch will output that frame on whatever the SP configures in order to end up at R2.

Keeping that logic in mind, we could also then configure the WAN Switch such that if R1 sent a frame using DLCI 201, then take the same action and forward it out some interface destined to R2? Or is that totally wrong?

Any thoughts on why Odom's example uses the DLCI of the destination router in his configs?

I wish I had a FR Switch...