DLCI Issue: Configuration or TELCO problem?

[jguivas01]

I've been trying to configure for several days a frame-relay network between several remote sites, using a 7206 on the main site and 2620s @ the remote sites.

After several days of troubleshooting by the TELCO, they say everything is up and running, but I've been hearing that since last week, and every time I try to go and configure, lines are not working.

Today I got word that all lines are now up, so at the site, I tried using "show frame-relay pvc" to obtain status, but all i get is "down" and "inactive", even tho i have specified DLCIs/IP addresses on both ends.

---

(Main Site)

interface serial1/0:1

encapsulation frame-relay

frame-relay lmi-type q933a

frame-relay traffic-shaping

!

interface serial1/0:1.20 multipoint

description Multipoint: GBO / HCO

frame-relay map ip 172.30.7.18 30 cisco

frame-relay interface-dlci 30

class 768k

(Remote1)

interface serial0/0

encapsulation frame-relay

frame-relay lmi-type q933a

frame-relay traffic-shaping

!

interface serial0/0.20

ip address 172.30.7.18 255.255.255.0

frame-relay interface-dlci 30 cisco

class 768k

---

Am i missing something?

Please help!

John

[Richard Burts]

Do not jump out the window yet. We are making progress. I believe the data in this posting is helpful. Among other things it tells us:

- LMI is working (which means that you are communicating successfully with the local Frame Relay switch). We know that particularly from this line:

LMI enq sent 15760, LMI stat recvd 15753, LMI upd recvd 0, DTE LMI up

- LMI is detecting 1 DLCI being announced. (I would feel better about saying that if you had posted the results of debug frame-relay lmi as several of us have suggested.) The DLCI being announced is not what they told you to use.

Therefore I think you have good grounds to say to the telco that connectivity problems have been resolved but that there are discrepencies between what they have told you and what is configured on their Frame Relay switch. I think you can comfortable say that the problem in with Telco at this point.

I do not understand what you mean when you say:

but now i see those 179, 180, 181...

What you posted only shows 180. What are you saying about 179 and 181?

HTH

Rick

[jguivas01]

I'm sorry! I tought i already posted the debug frame-relay lmi results here...

*Aug 27 07:36:57.419: Serial1/0:1(out): StEnq, myseq 70, yourseen 68, DTE up

*Aug 27 07:36:57.419: datagramstart = 0xE003CD4, datagramsize = 13

*Aug 27 07:36:57.419: FR encap = 0x00010308

*Aug 27 07:36:57.419: 00 75 51 01 01 53 02 46 44

Actually, i am resuming my questions to a single node, since none of them are working. If I get at least one to go up and connect, i'm certain that i can configure the rest.

This network consists on 7 different sites. I couldn't post the rest of the results because they exceded post character limit. The results of the other DLCIs being announced are the same. The only thing changing is the DLCI#; which in this case, those 179, 180, 181 DLCI#s, were not supplied by the TELCO to me.

I've posted the results on my router node and on my remote site. Ask for any additional info you need and i will post it.

Thanks ya'll..

John

[Richard Burts]

John

There was one post where you showed a similar three or four lines of debug output. (Although as I remember in that one it showed the DTE as down, so this debug shows progress). I was looking for two things in the output which I would not get with what you posted. 1) I was looking to see if there was a series of transmit request, get status, transmit request, get status (get status demonstrates that there is two way communication) or transmit request, transmit request (with no status response it would demonstrate only one way communication). 2) I was looking for the long response (most of the time you send a request to the switch and the switch sends a short response, but about every sixth response the switch sends a long response which includes every DLCI that the switch has configured on your interface.

However with what we have got I do not need those things as much. I think that at this point you have enough evidence to tell the provider that while the circuit is transmitting that there are problems that there are DLCIs present which they did not describe to you and the DLSI they told you is not present.

HTH

Rick

[jguivas01]

I appreciate all your help in this matter. With all this feedback, i got more than enough to go to the provider and make my point since i've been telling them that its their configuration what is wrong, but they always deny my alegations.

Again, thank you all.

John

[mark-obrien]

Sorry, but what you've shown here indicates that telco is correct (now anyway, but not at first) about everything except, perhaps, the DLCIs that are present, and this can be worked around. Joe Freeman suggested you turn on CDP. This, in addition to configuring IP addresses on each of your physical interfaces, will allow you to map DLCIs to those IP addresses using "show frame-relay map" and "show cdp neighbor detail". Once you have the DLCI-to-IP mappings, you can use this information to build whatever sub-interfaces you want.

Good luck.

Mark

[jguivas01]

The thing that drives me mad, is that the TELCO has been saying that everything is working, even tho i've been on site with a down/down status on my lines. So, at this point I just wanted to be sure if I can do the whole configuration, using the information provided by the TELCO, and it could maybe worked out, but TELCO refuses to colaborate with me in order to complete my proyect and they have been giving me unaccurate information, in order to configure my equipment properly. This because of the inactive DLCIs and mis-leading configurations.

I've been in this situation before, and TELCO usually provides troubleshooting until we get to resolve the issue, but in this case, i dont count with their support.

Thanks anyway!

John