ISDN won't pass data

[sjs950]

Hello,

We installed a new ISDN that won't pass any data. The call sets up fine but we get no data across the circuit. We have tried different PIC codes and no PIC code with the same results.

We currently have 2 PRI's on a Cisco AS5300 that work fine. The BRI's on the remote sites dial in and pass data just fine. We do use a PIC code on the BRI to dial into the PRI.

Qwest say there circuit is fine because the calls sets up correctly. But no data and there engineers can't seem to figure it out.

Has anyone ever seen this before or know of a solution.

 

[ISDNman]

IS the new line a BRI or PRI?

Qwest is wrong, just because the D channel is working does not prove any given B channel is error free.

You need an ISDN test set. BRI test sets are prety cheap to come byu on ebay and such. Then try dialing from one B channel to another and do a BERT.

If the Bert is OK then there may be a trunking problem, or there could be a configuraiton problem in your equipment. Next step is to try calling a loopback number and do a bert out to the loopback number and back.

BTW, on you BRI, stop using a manual PIC, you will get raped by most carriers by using casual access. Pick a carrier and get the PIC chnaged. Hint, you have to go with a large carreir to do circuit switched voice. Genrally speaking you are talking about AT&T (1010288) MCI (the MCI 1010222 NOT the Worldcom PIC) or Sprint (1010333).

If you choose AT&T it will be a hassle, you must contact a draconian switched data division to set up and account.

MCI and Sprint don't much care if you are doing data, just call and give them the DNs to set up the account.

Of course using a PIC is a good troubelshooting technique, just expensive to use permamently.

Best of luck. Keep us posted.

 

[jgideon]

You don't say if Qwest is your LEC or your IXC. Qwest (LD) doesn't do ISDN data--they used to farm it out to Sprint. Some carriers require you to pre-subscribe your originating ANI's before they will give you data class connectivity on an ISDN call. One way to test this is to do a LEC-to-LEC ISDN call (i.e. no LD in the middle).

 

[ISDNman]

*Excellent point* jgideon

 

[rtfmdude]

sjs950,

If the call connects and stays up(for over ~20 seconds) then I think you probably have a config issue. The reason I say this is because if ppp(assuming you're using ppp) successfully negotiates across the link, then guess what, we just passed traffic! [not trying to be harsh, but sometimes we don't realize that ]

Anyway, if you could post your dialer/serial configuration that would be great.

make sure:
-ip addresses are configured on both sides(don't even have to be in the same subnet, ppp installs a host route by default)
-interesting traffic is correctly defined and applied to the dialer interfaces(or serial, depends on the config)
-dialer maps are correctly configured - the hostname in the dialer map MUST match exactly with the other side(if you're using them, they are not required)

you may want to try to debug this like so:

create an access-list for safe debugging:

conf t
access list 157 permit icmp any any
^Z
debug ip pack det 157
debug dialer pack
term mon (if necessary)
ping the next hop

if you see 'encapsulation failed' then we probably have interesting traffic or dialer maps screwed up.

Hope this helps!

 

[sjs950]

Sorry for the delay.

I have 4 current PRI's that work fine. I'm not sure who the IXC is, I suspect ATT is the IXC on all 4 of them. The current config works to all 4 PRIs.

The new ISDN has Qwest as the IXC. From jgideons comment thats probably the problem.

I have used a dialer and not used dialer. I have tried 64K calls and 56K calls. The 56K calls seem to work a little better, but the results changes each time.

The first call I tried today was 56K. It worked no problems. I ran a 5000 ping test with no failures. 5 minutes later the same test failed. No config changes on either side.

Sometimes the call CHAPs fine, most of the time it fails during negotiations.

It seems to work the same from PRI to BRI and from BRI to PRI.

Remote router config

interface BRI0/0
description BRI ISDN Ckt#
ip address AAA.BBB.CCC.DDD mask
encapsulation ppp
dialer idle-timeout 60
dialer wait-for-carrier-time 20
dialer string XXXXXXXXXXX class test
dialer load-threshold 240 either
dialer-group 1
isdn switch-type basic-ni
isdn spid1 XXXXXXXXXX0101 XXXXXXX
isdn spid2 XXXXXXXXXX0101 XXXXXXX
ppp authentication chap
ppp chap hostname router
ppp chap password YYYYYYYY
ppp multilink

access-list 101 deny eigrp any any
access-list 101 deny udp any any
access-list 101 permit ip any any
dialer-list 1 protocol ip list 101

Access server config
interface Serial2:23
description Int S2:23 ISDN PRI CKT# dial XXXXXXXXXXX
no ip address
encapsulation ppp
dialer rotary-group 0
dialer-group 1
isdn switch-type primary-dms100
isdn incoming-voice data 56
no fair-queue
no cdp enable
ppp authentication chap
ppp multilink

 

[rtfmdude]

sjs950,

Ah, it really does sound like a carrier issue then - if you're trying to pic to a different ixc and using 56k and stuff. The only thing I would suggest is to try to qualify both of the endpoints - check 'show controller' output and try some loopback calls (to/from the same PRI/BRI) to rule out the lec.

jgideon, if the ixc can't do data calls, shouldn't they reject the call based off of the bearer capability in the setup? (I don't really know, just asking)

 

[jgideon]

assuming that the trunk type configuration between the LEC and IXC are correct, yes I would expect them to reject the call, but there are a lot of trunks out there that aren't set 'quite right' and work for most cases but not all.

 

[ISDNman]

The new ISDN has Qwest as the IXC. From jgideons comment thats probably the problem."

Yes, more than likely. However you say it does not work with a PIC code either.

Many IXCs do not reject data calls. Some eventaully reject after a minute or more. And the cause codes used if they do reject are highly variable.


Get the PIC code being used on the Qwest line from them. Then try some calls on one of the other (non Qwest PRIs) using this pic code.

To clarify; if the qwest pic code is 1010xxx then try placing calls with 1010xxx +1 area code +number

Very few IXCs can handle switched data calls. I have never heard that Qwest can, but that is not proof, of course. Even if they can they may not have thieir routing table set up correctly.

If the known good lines fail with calls with the Qwest PIC then at least you know for sure that is a problem (though there may be another problem). IN that case report the problem on one of the known good lines.

BTW you may want to confirm the PIC on the Qwest line - dial a voice call to 700 555-4141 (I am 80% sure that is the number, I am not in the office this morning.

Here's another approach that may help sort thngs out. If the cisco supports it place all B channels into loopback mode. Then call in from one of the BRI with a BRI test set and do a BERT. If you don't have a BRI test set get Qwest to call in from a BRI at their office.

Best of luck.

 

[artesian2000]

When you ordered these "new" PRI's did you request the be provisioned for both voice and data?

 

[sjs950]

New "PRI" was to be provisioned for data. Provider says thats what they are. I tried the 2 PIC code Qwest gave me, 1010035 and 1010253, with no luck.

We are going to another provider for 2 more circuits.

Thanks for your help.

 

[ISDNman]

Who the heck are those PIC codes (too lazy to look them up, I admit)? Try 1010222 and 1010333. These last two definitely support data.

 

[sjs950]

With PICs 1010222 and 1010333 the calls fail to even set up. I tried it with both 64k and 56K.

Guys I'm dropping this as an issue. The new ISDN from the old provider will b in early next year. I have learned a huge amount about ISDN. Thanks.