Frame Relay - DLCIs

I'm having a hard time understanding how FR differentiates frames/packets (not sure which one is correct) from different companies. I understand that company A's serial interface will tag a frame/packet with a DLCI that the admin chooses. Also, i get how that is mapped to the remote's ip address in a table. What I don't understand is how, since multiple companies are using private addresses mapped to a very limited amount of DLCI's, the SP's cloud can tell the difference between Company A's 10.10.10.2 DLCI 100 from Company B's 10.10.10.2 DLCI 100.

Any insight would be appreciated. Don't be afraid to tell me I have the whole concept wrong:)

Find more posts tagged with

Comments

fredrikjj

It doesn't have to tell IP prefixes apart because it's not an IP forwarding technology. Instead, it must build circuits using DLCIs from A to B. Exactly how a legacy Frame Relay core works is not exactly common knowledge these days, but it probably involved a lot of manual tinkering with DLCIs to manually build paths between sites.

mooed_music

so basically once it hits the FR switch it's well beyond CCNA? and at this level I just need to worry about getting to the FR switch?

fredrikjj

Short answer: Yes.

Longer answer: Frame Relay is still there to teach you certain concepts like Non-broadcast Multiaccess and how routing protocols and other things interact with such technologies. These concepts are still relevant in modern solutions like DMVPN, and L2 pseudo wire technologies like VPLS. The details of FR itself are more or less completely useless at this point. It might seem like a waste of time to you, and understandably so, but I'm happy that I at least got some exposure to Frame Relay before I went deeper into networking.

davenull

Frame Relay becomes much easier to understand once you see the configuration of a Frame Relay Switch. There's no magic involved, really:

SW#show running-config
Building configuration...
<output omitted>
!
hostname SW
!
<output omitted>
!
frame-relay switching
!
interface Serial4/1
no ip address
encapsulation frame-relay
clockrate 64000
frame-relay intf-type dce
frame-relay route 304 interface Serial4/3 403
!
interface Serial4/3
no ip address
encapsulation frame-relay
clockrate 64000
frame-relay intf-type dce
frame-relay route 403 interface Serial4/1 304

the key is the 'frame-relay route' command. What it says is "if I receive DLCI 403 on this interface, I'll switch it to interface Serial4/1 and I'll retag it as DLCI 304". It's that simple.

And yes, like others mentioned, IP addresses are irrelevant because Frame Relay is a layer 2 protocol.

mooed_music

davenull wrote: »

the key is the 'frame-relay route' command. What it says is "if I receive DLCI 403 on this interface, I'll switch it to interface Serial4/1 and I'll retag it as DLCI 304". It's that simple.

Ah. I understand now. Since you pay per PVC the SP already knows that what destinations are possible. I was forgetting that the interface the data was coming in to was not a variable and the company would be able to use that along with the DLCI to automatically know where to send the data. I was thinking about it as if it were like routing where each router only cared about the next hop.

Thanks for the help guys.

TWX

I know this is an older thread, but figured since it was heading in the direction I was wanting to go in that I may as well resurrect it...

I'm reviewing Data Link Connection Identifier and Frame Relay, and if I understand it correctly, DLCI as an L2 concept does not identify nodes, it identifies links, ie, between the customer equipment and first hop to the ISP. Since at Layer 2 it's literally a point-to-point connection there is no need to identify the host at the opposite end of the link because transmitting out that interface and receiving in from that interface (or subinterfaces) will only result in direct communication with one other piece of equipment. Where Ethernet allows for multiple nodes on a given collision domain and it was necessary to identify a particular destination node, and could be done by listening to the incoming traffic to define an ARP table to list IPs and their associated MAC addresses, and in the switched-world could learn destination MAC addresses through flood and associated reply, Frame Relay does not need most of those mechanisms.

Now to move on to learn more on Inverse ARP... Oh fun...

Maybe I'll set up one of my routers as a Frame Relay Switch and play with that. Might be easier.

Mooseboost

TWX wrote: »

Maybe I'll set up one of my routers as a Frame Relay Switch and play with that. Might be easier.

Setting it up all the way through for me was the best way to learn it.

volfkhat

TWX wrote: »

I'm reviewing Data Link Connection Identifier and Frame Relay, and if I understand it correctly, DLCI as an L2 concept does not identify nodes, it identifies links, ie, between the customer equipment and first hop to the ISP. Since at Layer 2 it's literally a point-to-point connection there is no need to identify the host at the opposite end of the link....
Where Ethernet allows for multiple nodes on a given collision domain... Frame Relay does not need most of those mechanisms.

When you explain it that way... i actually "get" it :]
Great insight!

Deathmage

If I may suggest, get Boson ExSim's, they really explain FR pretty darn well. Of course you need to understand all the command but right or wrong it explains the subject matter pretty well. Like this below, a FR question in Boson:

davenull wrote: »

Frame Relay becomes much easier to understand once you see the configuration of a Frame Relay Switch. There's no magic involved, really:

SW#show running-config
Building configuration...
<output omitted>
!
hostname SW
!
<output omitted>
!
frame-relay switching
!
interface Serial4/1
no ip address
encapsulation frame-relay
clockrate 64000
frame-relay intf-type dce
frame-relay route 304 interface Serial4/3 403
!
interface Serial4/3
no ip address
encapsulation frame-relay
clockrate 64000
frame-relay intf-type dce
frame-relay route 403 interface Serial4/1 304

the key is the 'frame-relay route' command. What it says is "if I receive DLCI 403 on this interface, I'll switch it to interface Serial4/1 and I'll retag it as DLCI 304". It's that simple.

And yes, like others mentioned, IP addresses are irrelevant because Frame Relay is a layer 2 protocol.

Too me Frame Relay, after making a Frame Relay Switch, is just a more glorified Serial WIC with a DTE/DCE with clock speeds and bandwidth. The only real difference to me is how the data is routed, once you get past the DLCI's is pretty simple.

Will agree with Davenull, once you make a FR switch it's easier to demystify the whole FR concept.

The hardest part is remembering the DLCI placement and making sure you have the DTE/DCE cable connected right, in a home-lab of course. in a real world everything should be DTE and DCE would be on the ISP side, does help to make it in a lab. But I can't imagine the face on a ISP tech support guy when you ask them is the clock rate is set on the FR switch and it's not....

Mooseboost wrote: »

Setting it up all the way through for me was the best way to learn it.

Completely agree. get a 1U Cable management though or else having those massive serial cables all over the place looks fugly, unless you can deal with messy.

FR hard.jpg