cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
630
Views
0
Helpful
4
Replies

DDR with CHAP in EIGRP environment not routing.

mcelyea
Level 1
Level 1

This may be a newbie type of question, but I am at a loss trying to figure this problem out. Thanks in advance for any assistance!

I have a remote site that has an T1 link back to headquarters. It also has a T1 link out to a MAN router in the same city which is the preferred redundant route. This remote site also has a tertiary link in an ISDN BRI link back to headquarters.

When I test the ISDN BRI link, I have to put the two T1 links into passive-interface mode, which in EIGRP causes the headquarters router and the remote MAN router to loose their neighbor relationships to the remote site in question. The ISDN BRI link comes up, and from debugging PPP Authentication, I can see that the CHAP process completes successfully.

Here is where I am at a loss. I cannot ping the other side from either router (being dialed into the remote side via AUX port). I did not look the last time I ran the test, but it could be possible that the remote router is not forming a neighbor relationship there for no packets would be routed between the remote and headquarters routers.

There are no ACL's on either side, and the call stays up when I show dialer. The ISDN link uses an external CSU/DSU so I cannot readily check the ISDN STATUS for the state of the B channels.

Can anyone offer any suggestions as to what to check next other than the neighbor relationship? If that neighbor relationship is not completing what could be preventing it? Is there something obvious that I am missing??

Thanks for any suggestions.

4 Replies 4

zahmed
Cisco Employee
Cisco Employee

Could you paste the config and "debug ppp nego" and "debug ppp chap" from the remote end only? You should be able to ping the directly connected interface across the isdn link regardless EIGRP adjacencies.

~Zulfi

You DO have EIGRP enabled on the dialer interface IP? Also watch out that all names/usernames/CHAPnames use the same case on both ends. Same names with different UC/LC mixes can cause strange results. If that does not fix it, also show a copy of "show ip eigrp neighbor" and "show ip eigrp interface " filling in the name of your dialer interface where I have .

Good luck and good hunting!

Vincent C Jones

www.networkingunlimited.com

I will get the okay from my customer to post any of the output from their equipment. I am currently working on getting another window to test this. May take a week or so. But thanks for the additional information.

It looks like the issue is a data compression incompatibility. We are

running "compression stac" on both ends. We recently upgraded IOS on the remote side. Since the upgrade, the compression algorithms on either side are now incompatible (12.1 IOS in remote to 11.0 IOS in core)

Mismatched software versions: The same version of code should be run

on both sides of the link, and it should be Cisco IOS Software Release

version 11.3T or later. In particular, Cisco IOS Software Release versions

11.2 and 12.0 are non-interoperable for compression.

http://cco-rtp-1.cisco.com/warp/public/116/wan_compression_faq.html#9