frame-relay interface-dlci issues

d.serra · ‎06-18-2011

Hey Guys,

I'm taking a practice lab for my CCIE and I'm stumped with a basic. Can anyone tell me why I would get 'Encapsulation failures' during a ping when I have defined specifically a DLCI on the frame-relay interface with the 'frame-relay interface-dlci 201' command. I thought the whole purpose of that command was to tell the router to map ALL traffic to that DLCI. Any ideas?

interface Serial1/0

ip address 172.16.123.2 255.255.255.0

encapsulation frame-relay

serial restart-delay 0

frame-relay interface-dlci 201

no frame-relay inverse-arp

And here is the debug frame-relay output when trying to ping the other side of the link. I would have copied the exact output but I'm using xterm and just finding out that it can't do copy and paste. What a PITA!

Serial1/0:Encaps failed--no map entry link 7(IP)

Thotsaphon Lueangwattanaphong · ‎06-18-2011

Hi,

First off, you have to know how many circuits are used between sites of your lab. You disabled frame-relay inverse-arp on the interface. It means that you won't send any frame-relay inverse-arp request message out of the interface but reply works well. Keep in mind, frame-relay interface-dlci is used for point-to-point sub-interface. You are using a physical interface. What you can do is using frame-relay inverse-arp or manually mapping DLCI for other sites.

HTH,

Toshi

Peter Paluch · ‎06-18-2011

Toshi,

Very nice answer! Let me just point out one inaccuracy:

Keep in mind, frame-relay interface-dlci is used for point-to-point sub-interface.

This is not true. You may freely use this command on physical interfaces and both point-to-point and multipoint subinterfaces (on an subinterface, be it PtP or MP, the usage of this command is a must).

On physical interfaces, this command is used mostly when you want to apply certain QoS policies to a particular DLCI. It is not common to just enumerate the DLCIs on physical interfaces using this command because all DLCIs that have not been assigned to particular subinterfaces are so or so assigned to the physical interface. Then again, it does not do any harm to specify them even on physical interfaces, although I personally dislike such a practice as it is about cluttering the configuration with needless commands.

On subinterfaces, these commands are absolutely necessary for the router to know which DLCIs go under which subinterfaces. This goes both for PtP and MP subinterfaces.

Best regards,

Peter

Richard Burts · ‎06-18-2011

And while we are offering clarifications, let me offer this - the original post says:"I thought the whole purpose of that command was to tell the router to map ALL traffic to that DLCI. " which is not true. The whole purpose of that command is to identify the DLCI associated with an interface/subinterface. That command does not do anything for mapping of addresses and DLCIs. Toshi makes a good point that Frame Relay inverse arp will dynamically learn the mappings and the fundamental problem in the original post is that this is disabled. The other alternative would be to use the frame-relay map command to manually map addresses and DLCIs.

HTH

Rick

HTH

Rick

Peter Paluch · ‎06-19-2011

Rick,

Wonderfully rounded and summed up. Thanks!

Best regards,

Peter

d.serra · ‎06-19-2011

Thanks guys. I was doing an IPExpert lab in GNS3 and the requirement was to not user sub-interfaces and to ensure inverse-arp was disabled. It does work with inverse-arp enabled. So I guess I'm going to just try the config again using a point-to-point subinterface just to ensure that I am not crazy as I could have sworn I have seen this work in the past without using frame-relay maps. I guess I have no choice but to use frame-relay map statements when using a physical interface with inverse-arp disabled.

Thanks!

Peter Paluch · ‎06-20-2011

Hello,

With Frame Relay, the logic is very simple: if you have a multipoint (sub)interface, there must be a mapping table created to associate the destination IP addresses with local DLCIs. This table can be either created manually, or populated dynamically thanks to InverseARP. There are no other alternatives.

You indicated you saw this working without creating any IP/DLCI maps statically. What probably happened is that you have configured the Frame Relay interfaces and their IP addresses before you deactivated the InverseARP. As a result, the IP/DLCI mapping table was created behind your back, so to say, and even if you deactivated the InverseARP later, the table remained populated. That is why you saw it working. Many CCIE lab preparations recommend using the clear frame-relay inarp command to erase any dynamically learned IP/DLCI mappings to make sure that your static mappings work as intended.

Best regards,

Peter

tbogie_gvds · ‎05-26-2012

> there must be a mapping table created to associate the destination IP addresses with local DLCIs

Folks,

Why it that the DLCI contained in the frame-relay interface-dlci command is local? From my persective the DLCI is on the other end of the link and therefore remote, not local.

Many Thanks,

Timothy

Giuseppe Larosa · ‎05-26-2012

Hello Timothy,

DLCIs are local information because they can change along the path in the Frame Relay network.

Example:

R1 ---- FRSW1 ------ FRSW2 ---- FRSW3 ----- R2

<---DLCI --><--DLCI ---> <---DLCI--> <--DLCI-->

A end-to-end PVC can be built between R1 and R2. The scope of DLCI is local between R1 and FRSW1.

The DLCI value can change at each Frame Relay switch hop.

As a result of this the sentence that you have put in evidence

Clearly in a back to back lab setup the local DLCI = remote DLCI because there are no FR switches in the middle but it is a special case

Hope to help

Giuseppe

tbogie_gvds · ‎05-26-2012

Giuseppe,

Thanks for your reply. And what you have said along with another NetPro post that I read a little earlier has truly made my day. Thanks so much!

Regards,

Timothy