Frame DLCI Mappings

james_

Hey All,

Just trying to tie up some loose ends on Frame. Have been reading from Sybex and CISCO Press ICND. I am confused as to when to use the local DLCI in the mapping statement, and when to use the remote DLCI.

Sybex states: "You cannot use a remote DLCI to communicate to the Frame-Relay switch"

CISCO Press ICND gives an example (p418 Diagram, p422 mapping statements) that use the remote DLCI in the mapping statement with a <show frame map> command that does in fact map remote DLCI to remote IP.

Hence the confusion. The one thing I notice is that the examples in the CISCO Press use a global addressing convention (a single DLCI terminating per access link), and I am thinking this has something to do with it?

Any help is appreciated!

James.

Sulblk27

I just happen to be in Frame Relay right now: In the CCNA Richard Deal book I was able to skim the following: "DLCIs are locally significant. The carrier's switches take care of mapping DLCI numbers for a VC between DTEs and DCEs." "Note that DLCIs are locally significant: they need to be unique only on a segment-by-segment basis and do not need to be unique across the entire Frame Relay network."

Hope this helps...

james_

Hi Sulblk27 and thanks for your reply. I understand DLCIs are locally significant and that FR switches by default handle the mappings. The problem I am having is when we use the <no frame inverse-arp> command on an interface, we are left to handle the mappings statically.

Sybex gives an example: <frame map ip 172.16.100.1 200 b>

Where the DLCI 200 is a local DLCI on that router

CISCO Press ICND gives: <frame map ip 199.1.1.2 52 b>

Where the DLCI 52 is a remote routers DLCI

It is quite probable that a question on the CCNA will deal with static mappings of DLCIs, my problem is that I do not understand which DLCI to use in which circumstance.

Thanks!

Spur

Stick with local DLCIs.. You should not be concerned about remote DLCIs. The FR switch does the mapping from your DLCI to the remote DLCI.

Sulblk27

Since I'm still learning---I found this, again in Deal's book: Manual Resolution
"If you are using manual resolution to resolve layer-3 remote addresses to local DLCI numbers, use the following configuration:
Router (config)# interface serial [slot_#/] port_#
Router(config-if)# frame-relay map protocol_name destination_address local_dlci_# [broadcast] [ietf] | cisco]
(I beleive the cisco part is concerning the examples he has in the chapter)
If you are running two protocols between yourself and the remote DTE such as IP and IPX, then you will need a separate frame-relay map command for each protocol and destination mapping. Following the name of the protocol is the remote DTE's layer 3 address (destination_address), such as its IP address. Following the layer 3 address is the local DLCI number your router should use in order to reach the remote DTE. "

He also shows configurations for manual resolutions for a PVC configuration

james_

Router(config-if)# frame-relay map protocol_name destination_address local_dlci_# [broadcast] [ietf] | cisco]
(I beleive the cisco part is concerning the examples he has in the chapter)

The CISCO part is referring to the encapsulation between endpoint DTE devices (routers) If one router is a CISCO, and the other endpoint is a non-CISCO, You have to use the IETF encapsulation, default on CISCO routers is CISCO. Encapsulation must match between routers for them to talk.

Sulblk27

Thank you James_
Did spur's answer help with what you needed?

james_

Did spur's answer help with what you needed?

Well, with all respect and thank-you Spur for the reply, it didn't really help. I have spent most of my life just "remembering" things as opposed to "understanding" them, a trait I am strongly changing with the CCNA.

I am pretty sure Mr.Odom (Author of CISCO CCNA Press, CCIE) wouldn't make such a fundamental mistake of misleading students trying to understand DLCI mappings, yet as plain as day, he is mapping remote DLCIs to remote IP addresses, and as mentioned, I really would like to understand why. It's only with understanding do we really better ourselves.

I am convinced it has something to do with the fact that there is only one DLCI assigned to each router, as opposed to having a different DLCI per VC, but I cannot find any literature backing this up..

Cucumber

James:

It depends on the diagram you are working with.

If you are given a "Global DLCI map" you have to think of DLCIs as global
numbers, for instance:

   DLCI=100                                              DLCI=200      
  RouterA---------------Frame------------------RouterB (1.1.1.2)
   (1.1.1.1)           Relay                        
                       Network----------------RouterC (1.1.1.3)
                                                           DLCI=300

Then at router A you would issue:
frame-relay map ip 1.1.1.2 200
frame-relay map ip 1.1.1.3 300
Then at router B you would issue:
frame-relay map ip 1.1.1.1 100
frame-relay map ip 1.1.1.3 300
Then at router C you would issue:
frame-relay map ip 1.1.1.1 100
frame-relay map ip 1.1.1.2 200

Remember this is only a logical way to put numbers on the diagram, when you
see this, you think "HECK I AM USING REMOTE DLCIs!". False, in reality
the DLCIs working on each Access Link are these:

              --To RouterB----200----         ---To RouterA---100
             ---To RouterC----300----        ---To RouterC---300
  RouterA----------------------------Frame---------------------------RouterB (1.1.1.2)
   (1.1.1.1)                        Relay                        
                                    Network--------------------------RouterC (1.1.1.3)
                                                   ---To RouterA---100
                                                   ---To RouterB---200

As you can see in the second diagram, all DLCIs are local and valid.
Because DLCI numbers can get repeated at each Access Link.
But the first diagram is just easier to read than the second one.

As a summary, using Global DLCIs is easier, both for diagraming and
for configuring. But it is only a way to make diagrams and is a WAY OF THINK of
DLCIs globally albeit DLCIs have always local significance!

Cucumber

Sorry, the diagrams look very messed up on low resolution monitors. [/img]

EdTheLad

I havent checked the book but dont assume that authors never make mistakes.
Anyway, just think about what the job the FR switch is doing, it is a switch which means when data comes in on one port the FR header is examined, the dlci is read and the switch database is examined(pre-configured not dynamic like an ethernet switch). The incoming port and dlci are mapped to an outgoing port and dlci. The data is then re-encapsulated into a frame using the new dlci that was found in the database mapping and sent out the egress port.
Now if you look what is happening on the router, you create a mapping
"frame-relay map ip 10.0.0.1 500 broadcast" this statement is saying any packets that arrive with a destination ip address 10.0.0.1 should be sent out on dlci 500.
So you have a pc connected to port eth0/1 on the router, you try and ping destination 10.0.0.1 on the far side of a FR cloud, the ping arrives on eth 0/1 in an ethernet frame, the ip packet is examined and the destination ip is 10.0.0.1, the routing table is examined, 10.0.0.1 is available out the FR port using dlci 500 as per our earlier configuration.The data is re-encapsulated into a FR frame and dlci is placed in the header.The frame is transmitted out the egress interface to the remote switch.
The remote switch receives the frame checks the FR header and looks for a mapping for the input port dlci pair, no mapping exists because somebody was to lazy to configure the FR switch so the FR switch discards the frame.
So as you can see the important thing is to match the dlci on the directly connected links,the switch can switch the dlci to whatever value it likes but the farend must match the dlci on the physical link exactly the same way as i have described on the near end.So the configuration is mirrored on either side of the FR switch and all the FR switch does is map the port/dlci pairs together.Not rocket science i dare to say.

james_

Thanks you guys, I was really getting thrown with the diagrams, it really "appeared" like the remote DLCIs were being used, Ed thanks for the theory, that's pretty much how I was understanding FR, just was getting completely thrown with the whole Global DLCI Map approach.

Cucumber, it's like you saw the pages I was looking at today and reinvented them here to solve my understanding problem

I'm definately taking this to the ICND with me:

Remember this is only a logical way to put numbers on the diagram, when you
see this, you think "HECK I AM USING REMOTE DLCIs!"

Thanks again guys!