The connection lasts for maybe 2 seconds. I don't have (and can't get) show dialer and debug dialer for Router A (it's 1 1/2 hours away). I do have a debug isdn q931 output that I thought to capture on my laptop when I was there.

See contents of Capture.txt

Here are the results of 'debug dialer' on Router B (RouterB.txt) IP address 192.168.0.19 is a Linux machine running MRTG; 192.168.17.1 is Router A. Router B is not configured to make a phone call since Router A is configured to stay up 24/7.

I can provide any outputs necessary from Router B.

Here's debug dialer info from Router B.

Carl

Thanks for the additional information. It does not show me the problem, but it does suggest a couple of things. In particular I see in the Q931 output that the router receives a CONNECT, then it transmits a CONNECT_ACK, and immediately transmits a DISCONNECT.

One of the things that it might suggest is some issue in PPP negotiation or authentication. Can you run debug ppp negotiation and debug ppp authentication and post that output?

HTH

Rick

ppp nego and ppp auth from Router B. I think you hit on something. I don't understand why it would fail all of sudden.

Carl

Yes it certainly does look like the LCP negotiated ok, then it starts ppp authentication and there is a problem.

I am not sure why it would suddenly fail. I have seen situations where changes were made in a router, the router ran (sometimes for a long time) with the change in running config but not saved to startup, and then the router reboots and the change disappears. I do not know if that could be the case here.

I have also seen a (very) few cases where someone telnetted to a device and made changes, and then discovered that they had telnetted to an incorrect address and were not changing the device that they thought they were. I do not know if that might be a possibility.

Do you have a copy of the router config from when you were there? And do you have an older copy of the router config that could compare?

HTH

Rick

I don't have one from when I was there. Wish I did, although I do have a tftp copy. I just completed an exercise going through each of the routers and trying to make them more secure (according to Nipper). When it came the ISDN portion, though, I was careful to not mess with it. I know I saved to start when I saved to tftp which should be the last one, but there's no guarantee that I saved it to tftp if I made a minor change afterwards. I did discover in the Router B that the username for Router A was missing. Don't know how or why, but it was. The last copy saved to tftp had it. Re-added it, but none of the messages have changed. Does it look like Router A is the one failing to authenticate? That's how I'm reading the log. I have been comparing notes with older configurations and currently running A-types. Looks like a road trip coming up.

Carl

If router B was missing the user name of router A that could certainly contribute to the authentication error (which seems to be the root problem here). But if you added the name on router B and the problem persists then there is something else.

I do agree that it looks like the major authentication problem is on router A. I wonder if it is also missing a name for its dial peer?

I am afraid that a road trip does seem to be called for. Running debug ppp authentication on the remote would be a way to confirm the problem. I would also be very careful to veify the config for router A about ppp authentication.

HTH

Rick

Part of the problem is solved. I had set 'security password min-length 8' on the Router A. The password for the router was only 4. But the system didn't care until the router got rebooted. Then, apparently because the password didn't meet the standard, the IOS didn't load that command. Hence, no username, and no authentication. As soon as I resolved that problem, the router dialed and connected.

Now here's where it gets a little strange. The router immediately sent out NTP packets and got its clock set. However, I can not ping or connect to Router B or anything else. I went to Router B to check on its configuration. Nothing out of the ordinary. Compared it to two other similarly configured routers. Mind you, these routers have been running this way for several years. I also did a 'show cdp n' from Router B and that showed Router A. I am at a total loss (again). I do have a lot of debug info if there is something you want to see that would be helpful.

Carl

I am glad that you got the authentication issue resolved. That is an interesting explanation of why the problem did not manifest until the router rebooted.

When some applications work (like NTP) and others do not work my first guess is to look for some kind of access list that is filtering traffic.

If there is not a access list issue my second guess would be some kind of routing issue. Can you tell us how NTP is configured on the remote router? What address is it looking for to learn NTP? Does it perhaps have a route for the NTP address but not for others? It might be helpful to see the output of show ip interface brief from both routers and the output of show ip route from the remote router.

HTH

Rick

I will attach 3 files. Router-A.txt is from my first visit yesterday to Router-A. I'm using HyperTerminal and its Capture file feature, so the file looks a little weird at times. I tried to turn on and list everything that might be helpful. One of the interesting things is related to the pings. If I ping the network address of Router-B (192.168.7.1) it fails. If I ping the secondary address of Router-B(168.54.104.161 which used to be it's primary) I get some success. ?? Router-B.txt is my visit to Router-B after I couldn't get Router-A to ping or connect. You will also see some configurations from other similar routers on my network. Router-A2 is a return trip to Router-A, checking to see why it wouldn't reconnect when I cleared the connection at Router-B.

Here's the sh ip int brief from Router-B:

Fredericksberg_CM#sh ip int brief

Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 192.168.7.1 YES NVRAM up up

BRI0/0 192.168.7.1 YES TFTP up up

Serial0/0 10.32.0.38 YES NVRAM up up

BRI0/0:1 unassigned YES unset down down

BRI0/0:2 unassigned YES unset down down

Carl

I believe that the good news is that now that you have resolved the issue with names the PPP authentication works and the connection is established. The fact that NTP works and that show cdp neighbor shows neighbors on the ISDN make me believe that for the most part it is working (and the fact that trace misses the first hop but then generates a response is an indicator that the connection works - and it may provide a hint about why ping fails). It is a strange symptom that ping fails. I do not have a good explanation for it yet but I would like to suggest a change to address an inconsistency in the config. On router A the dialer map uses the old address:

dialer map ip 168.54.104.161 name Fredericksberg_CM broadcast 9902846

I believe that this causes some difficulty during the negotiation on both routers:

May 1 11:07:04: BR0/0:1 AAA/AUTHOR/IPCP: Start. Her address 192.168.7.1, we want 168.54.104.161

May 1 12:35:05: BR0/0:1 AAA/AUTHOR/IPCP: Start. Her address 192.168.6.1, we want 192.168.6.1

I would suggest that you change the dialer map so that it uses the newer (primary) address. When you do that lets see if it makes any difference in the behavior.

I have another suggestion - especially about using the Hyperterm capture function. When you are using this it would help if you execute the exec command terminal length 0. This will generate the output of things like show run without the more prompt (which is what causes a lot of the ugly effects in the output).

HTH

Rick

I'd rather be lucky than good, I guess. After spending a week getting the phone company to check out the circuits, they finally verified that they worked. They went to site A and used their test set to call site B successfully. So I began troubleshooting again. Replaced the ISDN card, replaced the router, replaced the cable. Nothing. I could ping the other router but only get 2/5 success. Put everything back and planned to go to site B. Turned the router back on and tried it again. 5/5. Tried pinging a server on the main network (one more hop). 5/5. Went up front to see about IP addresses. Computers already had them. As one of my guys said, "Who knew the router had to be rebooted 47 times to work?" Thanks for your help.