Local Significance of DLCI

typeshtypesh Member Posts: 168
Hey everyone:

I am running in to a problem understanding the local significance of a DLCI.

The only way I can really explain is with a scenario...

Suppose we have 4 sites: NY, FL, CA, and TX. NY has a PVC to FL, another PVC to CA, and one more PVC to TX. So I guess this is a hub-and-spoke topology.

DLCI at FL is 300, DLCI at CA is 300, DLCI at TX is 300.

When NY Router has a packet for a subnet off of TX, it will check its frame-relay map (show frame-relay map). It will find the DLCI as 300, so it puts 300 in the LAPF header.

Here is my question:

When the NY's WAN Switch gets this frame with a DLCI of 300, how does it know to forward to TX, and not CA or FL?

I was reading that the sending router treats the DLCI field as the destination address. However in this scenario, all 3 destinations are DLCI 300.

Can anyone please help me understand?
«1

Comments

  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    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.
    Latest Completed: CISSP

    Current goal: Dunno
  • blackninjablackninja Member Posts: 385
    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.
    Currently studying:
    CCIE R&S - using INE workbooks & videos

    Currently reading:
    Everything. Twice ;)
  • megatran808megatran808 Member Posts: 53 ■■■□□□□□□□
    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!
    "Love your Job, but never fall in love with your company....because you never know when your company stops loving you!"
  • typeshtypesh Member Posts: 168
    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
  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    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
    Latest Completed: CISSP

    Current goal: Dunno
  • typeshtypesh Member Posts: 168
    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!
  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    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.
    Latest Completed: CISSP

    Current goal: Dunno
  • typeshtypesh Member Posts: 168
    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?
  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    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)
    Latest Completed: CISSP

    Current goal: Dunno
  • typeshtypesh Member Posts: 168
    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
  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    Yeah, my box was running slow. It's up now.
    Latest Completed: CISSP

    Current goal: Dunno
  • typeshtypesh Member Posts: 168
    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 49.8K
  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    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-albums-stuff-picture133-fr2.gif
    Latest Completed: CISSP

    Current goal: Dunno
  • typeshtypesh Member Posts: 168
    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...
  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    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!
    Latest Completed: CISSP

    Current goal: Dunno
  • fly351fly351 Member Posts: 360
    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.
    CCNP :study:
  • typeshtypesh Member Posts: 168
    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...
  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    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.
    Latest Completed: CISSP

    Current goal: Dunno
  • typeshtypesh Member Posts: 168
    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!
  • fly351fly351 Member Posts: 360
    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?
    CCNP :study:
  • typeshtypesh Member Posts: 168
    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?
  • fly351fly351 Member Posts: 360
    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


    fly351-albums-examples-picture134-drawing2.png



    Check out this doc Cisco Frame Relay Configurations > Configuring Static and Dynamic DLCI to Network Layer Address Mapping
    CCNP :study:
  • outrunredoutrunred Banned Posts: 30 ■■□□□□□□□□
    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
  • typeshtypesh Member Posts: 168
    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


    fly351-albums-examples-picture134-drawing2.png



    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.
  • typeshtypesh Member Posts: 168
    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.
  • fly351fly351 Member Posts: 360
    Just curious.. do you have packet tracer..?

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

    fly351-albums-examples-picture135-frame.jpg


    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
    CCNP :study:
  • typeshtypesh Member Posts: 168
    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...
  • typeshtypesh Member Posts: 168
    typesh wrote: »
    I wish I had a FR Switch...


    As it turns out... I do! The thought occurred to me... why can't I use my 2501 as a Frame Relay switch...? so I did some searching, and it turns out it works perfectly, although having a "cloud" with only 2 Serial interfaces makes it quite limited. So I was able to run a few labs here. I think I have sorted some of the issues out... This might be a long post, but I think it will clear up some of the things we've been looking at.


    A major part of my misunderstanding was the configuration of what actually happens inside the Frame Relay Switch of itself!

    Ok here it goes...

    This is the topology that I used as my lab (based on the Lab from Lammle's book):

    R1 (Serial 0)
    DLCI 102
    (Ser0) FRAME RELAY SWITCH (Ser1)
    DLCI 201
    (Serial 1) R2.

    Note that R1, FR_SWITCH, and R2, are all 2501 Routers.
    R1's IP is 172.16.10.1/24
    R2's IP is 172.16.10.2/24

    First I'll briefly show how R1 and R2 were configured along with a show ip route and show frame-relay map on each Router.

    R1's Config
    interface Serial0
    no ip address
    encapsulation frame-relay
    frame-relay lmi-type cisco
    !
    interface Serial0.102 point-to-point
    ip address 172.16.10.1 255.255.255.0
    frame-relay interface-dlci 102
    !

    R1#show ip route

    Gateway of last resort is not set

    172.16.0.0/24 is subnetted, 1 subnets
    C 172.16.10.0 is directly connected, Serial0.102

    R1#show frame-relay map
    Serial0.102 (up): point-to-point dlci, dlci 102(0x66,0x1860), broadcast
    status defined, active



    R2's Config

    interface Serial1
    no ip address
    encapsulation frame-relay
    !
    interface Serial1.201 point-to-point
    ip address 172.16.10.2 255.255.255.0
    frame-relay interface-dlci 201


    R2#show ip route

    Gateway of last resort is not set

    172.16.0.0/24 is subnetted, 1 subnets
    C 172.16.10.0 is directly connected, Serial1.201

    R2#show frame-relay map
    Serial1.201 (up): point-to-point dlci, dlci 201(0xC9,0x3090), broadcast
    status defined, active
    R2#


    Now have a look at how the FR_SWITCH was configured. This was the key to helping me understand how the DLCI works.

    FR_SWITCH's Config

    FR_SWITCH#show run
    Building configuration...

    Current configuration : 715 bytes
    !
    version 12.3
    service timestamps debug datetime msec
    service timestamps log datetime msec
    no service password-encryption
    !
    hostname FR_SWITCH
    !
    boot-start-marker
    boot-end-marker
    !
    !
    no aaa new-model
    ip subnet-zero
    no ip domain lookup
    !
    frame-relay switching
    !
    !
    !
    interface Ethernet0
    no ip address
    shutdown
    !
    interface Serial0
    no ip address
    encapsulation frame-relay
    clockrate 64000
    frame-relay intf-type dce
    frame-relay route 102 interface Serial1 201
    !
    interface Serial1
    no ip address
    encapsulation frame-relay
    clockrate 64000
    frame-relay intf-type dce
    frame-relay route 201 interface Serial0 102
    !
    ip http server
    ip classless
    !
    !
    !
    !
    line con 0
    logging synchronous
    line aux 0
    line vty 0 4
    !
    !
    end


    Also have a look at IOS help when configuring the route over where to forward frames:

    FR_SWITCH(config-if)#frame-relay route ?
    <16-1007> input dlci to be switched
    FR_SWITCH(config-if)#frame-relay route 102 ?
    interface outgoing interface for pvc switching

    FR_SWITCH(config-if)#frame-relay route 102 interface ?
    MFR Multilink Frame Relay bundle interface
    Serial Serial
    Tunnel Tunnel interface

    FR_SWITCH(config-if)#frame-relay route 102 interface Serial 1 ?
    <16-1007> output dlci to use when switching

    FR_SWITCH(config-if)#frame-relay route 102 interface Serial 1 201 ?
    <cr>

    FR_SWITCH(config-if)#frame-relay route 102 interface Serial 1 201



    Actually configuring the Frame Relay Switch of itself put this in perspective for me. This is the way I understand it.

    On R1 we have a packet to sent R2. R2's IP address is 172.16.10.2.
    So have a look at R1's Routing Table. We see the frame should be sent out Serial0.102. Knowing that it must go out Serial0.102, have a look at the output of show frame-relay map on R1 and we see DLCI of 102. So just as fly351 showed in his Packet Tracer output, the frame will leave with the DLCI set to the LOCAL DLCI- 102 in this case.

    Here's where it comes together for me. The Frame Relay switch receives a packet with DLCI header 102. Since we have configured the FR_SWITCH with:
    FR_SWITCH(config-if)#frame-relay route 102 interface Serial 1 201
    the switch knows to take a packet with DLCI 102 in the header, and switch it out Serial 1 and use output DLCI of 201. This is how it will end up getting to R2.

    This is how Local DLCIs work as I have come to understand it. If I am incorrect in anything here... please let me know as I am going based on my lab work and research.


    Okay, so now on to the issue of Odom's book showing the DLCI of the DESTINATION Router. First have a look at this link:
    https://learningnetwork.cisco.com/message/41802

    It appears that Odom is using Global DLCI in his example. I figured that I could turn off Inverse Arp on R1 and R2, and change the logic of the Frame Relay Switch. I would also create a frame relay map on R1 like this:

    R1(config-subif)#frame-relay map ip 172.16.10.2 201 broadcast
    Only frame-relay interface-dlci command should beused on point-to-point interfaces not frame-relay map

    Based on the examples in the Odom book, this is how he appears to have done it. Using the Destination DLCI. However the router doesn't let me do this on the Point To Point Link. Also, I believe there is some additional/different configuration needed on the Frame Relay Switch if we are going to be using Global DLCIs....

    Okay...need a break!
  • tha_dubtha_dub Member Posts: 262
    Okay my head is starting to hurt here.... Someone let me know if this is correct:

    My understanding of a DLCI is that it is only really used by the service providers frame relay network. IE. Router gets packet for IP at remote site. Because it is mapped to a DLCI router send packet into frame relay network to provider using the correct DLCI number. Frame relay provider has that DLCI mapping (which they gave you in the first place) and that is how the provider gets the packet from source to destination. Once the packet gets to the destination the receiving router only see's the destination IP address and routes accordingly. In the case of a hub and spoke design it works the same way where the receiving router gets a packet destined for another site the router would just route it out the same interface with the new dlci address to the other spoke destination....
  • notgoing2failnotgoing2fail Member Posts: 1,138
    tha_dub wrote: »
    Okay my head is starting to hurt here.... Someone let me know if this is correct:

    My understanding of a DLCI is that it is only really used by the service providers frame relay network. IE. Router gets packet for IP at remote site. Because it is mapped to a DLCI router send packet into frame relay network to provider using the correct DLCI number. Frame relay provider has that DLCI mapping (which they gave you in the first place) and that is how the provider gets the packet from source to destination. Once the packet gets to the destination the receiving router only see's the destination IP address and routes accordingly. In the case of a hub and spoke design it works the same way where the receiving router gets a packet destined for another site the router would just route it out the same interface with the new dlci address to the other spoke destination....


    Take a look at my lab and tell me if helps you at all. Instead of just understanding that the ISP does the switching, I made a router do that so you can get a glimpse of how it works.


    BrandonTek Blog Archive Frame Relay Switch Lab#01


    frame_relay_011.png

Sign In or Register to comment.