1. Home
  2. Cisco Systems
  3. internal name servers stop recursive lookups

internal name servers stop recursive lookups

This is weird - I hope it rings some bells with someone as I have no Idea what is going on.

I have a Cisco 2621XM. We have 5 tunnels from it. One to a cosine router which is quite heavily used and the other to home networks, Dratek 2600. All are using IPSEC and 3Des.

Saturday, our internal nameserver, windows 2003 server stopped being able to resolve external websites. I had a sniffer on the server itself and I can see the requests going out of it, but not coming back. If I rebooted the server and reloaded the router, it would work again for about 10-15 minutes and then lock up again. I tried just about everything I can think of, finally out of desperation I shutdown the lightly used tunnels to users home LANs. This fixed the problem.

The router is running Version 12.3(16) IOS.

I am a rookie when it comes to Cisco routers, I haven't done any real packet debugging on them. Is there some way I can figure out where these packets are going? If they are actually getting through the router? As the router is connected directly to our E1 circuit, I can't sniff on the other side of it.

If I set a DNS server on my internal name server, it does then resolve names, but the nameserver itself still can't...

Does anyone have any ideas on what this is, how I can diagnose it, anything? I'm really lost on this and users are giving me hell cos their tunnels are down. The home use tunnels are really lightly used is the thing, so I can't imagine the volume of data is the problem.

Thanks for your help.

Reply to
jogdial
Loading thread data ...

On 24 Oct 2005 05:36:57 -0700, snipped-for-privacy@gmail.com wrote: ...

Using the debug ip packet detail command will get you displays like this:

Aug 29 11:00:26.084 pdt: IP: s=66.53.174.70 (Ethernet0), d=63.162.241.3 (Dialer1), g=63.162.241.3, len 60, forward Aug 29 11:00:26.084 pdt: UDP src=3335, dst=53

Sep 18 19:07:53.026 pdt: IP: s=66.81.75.140 (local), d=192.43.244.18 (Dialer1), len 76, sending Sep 18 19:07:53.026 pdt: UDP src=123, dst=123

I don't know how to intelligently filter which packets get displayed, so using this can produce _lots_ of debug! (To stop it, use the undebug all command.)

And the problem is, those only say that some part of the router thinks it forwarded those packets. It doesn't prove they actually went out on the line. And when no response is displayed, you can't tell if there really was no response on the line, or some part of the router dropped it before the logging stage - which is where I'm stuck at the moment on my own problem.

Loren

Reply to
Loren Amelang

debug ip packet detail

will only show the packets that match the specified access list. In this case, he'd want to create an ACL that matches UDP port 53 in both directions:

access-list 180 permit udp any any eq 53 access-list 180 permit udp any eq 53 any

Reply to
Barry Margolin

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.