Can you please help me understand use of Frame-Relay Interface-dlci command. It’s getting mysterious for me day by day as I am studying FR. The reason being is I earlier thought that I should only use this command on FR point to point subinterface. As Point to Point subinterface don’t allow us to put Frame relay map statements. Also in such case Inverse arp should be turned off. But while I was going through Cisco’s FR documentation on website I saw that in almost all examples they used interface dlci command on interface not on sub interface and also without turning off inverse arp. So the question now is if inverse arp is turned on then as per my understanding we need not to put this command as it will discover dlci settings through lmi signals automatically.

Kindly explain Interface Dlci command to me…

When I saw this post, I got to thinking a little bit.  Mostly about the fact that the interface-dlci appears to be a much more misunderstood command than I ever gave it credit for!  (poor thing…)

The quick answer is that the “frame-relay inteface-dlci” command simply says “This DLCI goes here” to the router.

On a physical interface, this command is largely irrelevant (more in a minute) because ALL DLCIs are assigned to the physical interface by default.  If you are ever interested, concerned or otherwise bored, just check out “show frame-relay pvc” and you will see where they are assigned.

So in the case of sub-interfaces, there is no automagical assignment of DLCI numbers.  Even if your subinterface number and DLCI number are the same.  That’s just a sign of being anal-retentive (or as we consultants call it, “good at documentation”) or a little OCD.  But you can technically have DLCI 100 on subinterface Serial 0/0.223.  Kinda strange, but perfectly workable!

So whenever you have a subinterface, you need to do SOMETHING to tell the router “this DLCI goes here”.

So now let’s look at the next portion:  Mapping.  Layer3 to Layer2 mapping in particular.   We can learn about L3-L2 mapping via Inverse ARP.  This is on by default, but frowned upon in the CCIE Realm!  “Show frame-relay map” will let you know if you have learned any addresses dynamically or not.

So if we DID allow Inverse ARP, whether our subinterfaces were point-to-point or multipoint ones, we COULD just use the “frame-relay interface-dlci” command and nothing else.  (Yes, I know inverse ARP requests are not sent by default on subinterfaces, but responses still are.  Watch your debugs!)  :)

So the Interface-DLCI command assigned the PVC to a subinterface.  Inverse ARP then took care of the mapping.  What if we aren’t allowed to use Inverse ARP?  Like for the CCIE lab?  Ok, what are our options?  Well, the “frame-relay map” command is the most obvious and well known.  That works very well.  The “frame-relay map” command both assigned L3-L2 mapping AND says “this DLCI goes here” all in one command!

Unless of course you are on a point-to-point subinterface.  As you pointed out, you can’t use the map command there!  But that’s ok, it’s not needed anyway!  Point-to-point links have a different way of thinking.  They view the world as “If it’s not my address it must be yours” and sends things out.

So that covers our two primary issues with PVC operations in Frame Relay.  #1 is assigning the DLCI to an interface (no magic).  #2 is the L3-L2 mapping to make IP actually work!

The last part I want to add (re: my “more in a minute” above) was that the “frame-relay inteface-dlci” command also serves another purpose which sometimes gets confusing in terms of where we just got through with things!

So where we left things with “frame-relay interface-dlci” commands:

1.  Definitely used on point-to-point subinterfaces
2.  Can be used on multipoint subinterfaces if Inverse ARP works
3.  Not used on physical interfaces because all DLCIs belong there by default.

Now, just to mess with that logic a bit.  When studying frame-relay, and particularly by the time you get into QoS configurations you will become familiar with frame-relay map-classes.  Map classes can be assigned to an interface or subinterface without any problem.  When this occurs, the information in the map-class gets appled to EVERY DLCI on that interface or subinterface.

So what happens if you have different QoS parameters for different PVCs that just happen to be on the same interface/subinterface?  Hmmmm…  Well, in comes the “frame-relay inteface-dlci” command again!  See, it really IS a cool command!

The “frame-relay map” command does not have any parameter for adding a map-class.  After you hit enter on your “frame-relay interface-dlci” command though, you’ll get a new sub-command prompt.  Try using “?” here.  You’ll see that you have the opportunity to specify a separate map-class for each and every DLCI that you have.

So if you see “frame-relay interface-dlci” commands on a physical interface.  Or if you see them AND a “frame-relay map” command under a multipoint subinterface, this is the reason why.  If you use the “frame-relay inteface-dlci” command AND the “frame-relay map” command for the same PVC, you will need to make sure the “frame-relay map” command comes first.  Otherwise the router will express its displeasure!

So there are some very simple, but also some very powerful things the little “frame-relay interface-dlci” command does.  Hopefully that will help you take some of the mystery out of things!

You can leave a response, or trackback from your own site.

15 Responses to “That Pesky Frame-Relay Interface-DLCI Command!”

  1. Ferret999 says:

    Great post. I did not know about the sub-command prompt under frame-relay interface-dlci

  2. Dragons & Faeries says:

    Thanks! That was a very informative and enjoyable read!

  3. desert lizard says:

    That was a great refresher of the “Frame-relay Interface-DLCI” command. And it was a very enjoyable read, Keep it up…

  4. Nicolas says:

    Thanks for these clarifications!

  5. Harry says:

    That’s a great Q&A, I appricate that

  6. Darby Weaver says:

    Good explanation!!!

    Actually quite excellent.


  7. Darby Weaver says:

    Also nice you ensured a clear understanding that both the frame-relay interface-dlci command and the frame-map command can be used together and the conditions. I’ve seen this mis-explained before elsewhere and many fail to cover it.

    Again, my compliments.

    Darby Weaver

  8. Hi webmaster – This is by far the best looking site I’ve seen. It was completely easy to navigate and it was easy to look for the information I needed. Fantastic layout and great content! Every site should have that. Awesome job

  9. Jason says:

    Great article. Learned something new!

  10. Prima Even says:


    Fascinating articles by the expert, as always. But somehow I need to clarify something. Your statement regarding inverse ARP
    “Yes, I know inverse ARP requests are not sent by default on subinterfaces, but responses still are. Watch your debugs!”

    I tried to lab it up connecting 2 multipoint subinterface through frame relay switch and found that inverse ARPs are still sent by multipoint subinterface. Could you please verify which one is correct?


    • Naveen says:


      He is talking abt Point to Point sub-ints..on which In-Arp msgs are not sent out…only responses are…

  11. Steve-O says:

    Thanks partner. I couldn’t find anything about this anywhere. The ICND2 book seems to be wrong as well. It says, “Mapping via Inverse ARP or static frame-relay map statements is needed only when more than two VCs terminate on the interface or subinterface, because those are the only instances in which confusion about which DLCI to use might occur.”

    But I noticed that it works fine with ‘frame-relay interface-dlci’ if you have a full mesh between 4 nodes (hence 3 VCs per node). That got me wondering, “What is the point of ‘frame-relay map’ except when I-ARP is disabled of course?”

    Anyway, I guess QoS is where this command is necessary… thanks a lot for this info.

  12. Juan carlos says:

    Best explanation ever.
    You are the MAN!

  13. CCIE.BUTCHER says:

    Even after doing frame-relay from the workbook, i had doubts regarding this mysterious command but u cleared them all.


Leave a Reply to Amelia Mullis

Click here to cancel reply.


CCIE Bloggers