1700 Router Traffic issue 2

[balartar123]

Background,



We are having some issues with our users on the Child1(child domain,172.16.11.x) side of our router. They are the users that have limited access to the Parent1(Parent domain,172.16.7.x) side of the network. I will describe the issue and you can let me know if the router/access-lists can be actually causing the issues.

If we take a typical user that is getting their IP from DHCP they can get to all of the critical resources. Mail (172.16.7.13), internal web page (172.16.7.36) and external internet access. We see intermittent users all of a sudden cannot get to their e-mail. At this point they can no longer even ping anything on the 172.16.7.x ip schema with the exception of the gateway on that side 172.16.7.1. They still retain their ability to browse the internet and can ping ip addresses on the web. The solution can be resolved by changing the IP address of the client and they begin working immediately. This happens to users that are using static addresses as well. While we are having some users stuck in this state, other users with the exact same settings are still functional. We have tried rebooting the router, the DHCP server, the Child1 DC's but that still leaves the clients in this hung state as well. I have connected to the router with the console cable and do not see collision messages either since we changed the interface setting to a static entry. The main reason that we are thinking that it may be a problem with the router is because we do not see this happening at all on the Parent1 side of our network.

My questions are:

1. Can the access-lists be causing this issue?
2. Does the router retain any IP information that would not be cleared by a reboot of the router?
3. What should we turn on for logging that would enable us to see if there were issues at the router level?
4. Have you ever seen this symptom occur on a network?

Any help would be appreciated. See config below:

!
memory-size iomem 25
ip subnet-zero
!
!
no ip domain lookup
!
ip audit notify log
ip audit po max-events 100
!
!
!
!
!
!
!
interface Ethernet0
ip address 172.16.11.1 255.255.252.0
ip access-group 102 out
half-duplex
no cdp enable
!
interface FastEthernet0
ip address 172.16.7.37 255.255.255.0
speed 100
full-duplex
no cdp enable
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.7.1
no ip http server
no ip http secure-server
!
!
!
access-list 102 permit ip any host 172.16.7.40
access-list 102 permit ip any host 172.16.7.36
access-list 102 permit ip any host 172.16.7.9
access-list 102 permit ip any host 172.16.7.8
access-list 102 permit ip any host 172.16.7.13
access-list 102 permit ip any host 172.16.7.12
access-list 102 permit ip any host 172.16.7.1
access-list 102 permit ip any host 172.16.7.115
access-list 102 permit ip any host 172.16.7.45
access-list 102 permit ip any host 172.16.7.98
access-list 102 permit ip host 172.16.7.40 any
access-list 102 permit ip host 172.16.7.36 any
access-list 102 permit ip host 172.16.7.8 any
access-list 102 permit ip host 172.16.7.9 any
access-list 102 permit ip host 172.16.7.13 any
access-list 102 permit ip host 172.16.7.12 any
access-list 102 permit ip host 172.16.7.1 any
access-list 102 permit ip host 172.16.7.115 any
access-list 102 permit ip host 172.16.7.45 any
access-list 102 permit ip host 172.16.7.98 any
access-list 102 deny ip 172.16.11.0 0.0.0.255 172.16.7.0 0.0.0.255
access-list 102 deny ip 172.16.7.0 0.0.0.255 172.16.11.0 0.0.0.255
access-list 102 permit ip any any
dialer-list 1 protocol ip permit
!
snmp-server community public RO
snmp-server enable traps tty
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
password xxxxxxxxxxxxxxxxxxxxxx
login
!
end

 

[tschouten]

I've seen something similar to this before not quite exactly the same...Are you using DNS (assuming you are) with active directory. If so are you using wins as well due to cross-platforms like win9x and nt in your infrastructure. If so I would say you might want to make sure your DHCP clients are getting all their information, and make sure the static clients are setup properly. If you have a bunch of cross-platforms make sure you have wins enabled this could be causing some of your problems. I really don't think you have a routing issue. But I am looking at everything and trying to go over it to see if there is anything else I can think of or may have missed.

 

[gunthnp]

if was the access list the routershould not let any one by but what is the load like across that line for the router because accesslist can be memory filling and you don't have a lot on that router

that a long shoot still I don't thinks its the router becuase you reseting the router does not help

gunthnp
If you like my tip please mark it.

 

[tschouten]

Forget my previous post, looked at it a little harder and noticed this:

access-list 102 deny ip 172.16.11.0 0.0.0.255 172.16.7.0 0.0.0.255
access-list 102 deny ip 172.16.7.0 0.0.0.255 172.16.11.0 0.0.0.255


You are using the 172.16.11.1/22 ip address scheme. As well as the 172.16.7.1/24 address scheme.

You have the access-list set to outbound traffic. But if you notice you aren't allowing any traffic from 172.16.11.0 to 172.16.7.0 you have it blocked in both directions from host to destination and vice versa. This is where I would say your problem may be coming from, though I could be wrong.Would say try removing those lines from the access list see if it clears the problem if it does and you still want to block certain things from those two areas research and be more explicit in what you want to deny.

 

[balartar123]

We have checked all of the IP settings to assure that they are correct for DHCP clients as well as the static clients. I don't think the issue is with those settings.

 

[fmonteiro]

I would like to suggest that you take one of these hung users and create an access-list. Lets suppose the hung user has an IP address 172.16.11.99. You would create the following access-list:
access-list 99 permit 172.16.11.99
On the router you would issue the following command:
terminal monitor
debug ip packet 99
Lets try to identify the cause of the problem looking at the packtes. It could help.

Another option: considering the same host add an access-list entry on the top of your access-list, e.g:
access-list 102 permit ip host 172.16.11.99 host 172.16.7.13 log
access-list 102 permit ip host 172.16.11.99 host 172.16.7.36 log
Note the log option at the end of the command.
Do not forget the term monitor command.

On both cases try to reproduce the problem forcing the host to access the servers.

Please, post some output for us.

 

[gaveeve]

I understand you to say that you have one router with 2 ethernet interfaces.

Router
Child------172.16.11.1/172.16.7.37--------Parent

But you are using 172.16.7.1 as the gateway. Where is that address? Also you are using 0.0.0.0 0.0.0.0 172.16.7.1 as a default route. This would be for both subnets and the 172.16.11.x subnet would not know where that is. Is there another interface or router?

 

[tschouten]

fmonterios suggestion is bloody brilliant, wish I had thought of it myself. Suggest trying that idea out it would give you a more defined look into what is happening allowing for better analysis.

 

[balartar123]

fmonteiro,

I will give that a try as soon as we have another failed client. That will definately give us some more information and I will post.


gaveeve

I'm sorry, when I mentioned that the only thing on the 172.16.7.x side, I should have mentioned that it was the gateway but only for the 172.16.7.x side. The gateway for the 172.16.11.x domain is 172.16.11.1 which is the router itself. There are two interfaces on the router and they look as you had listed
Child------172.16.11.1/172.16.7.37--------Parent
We have the route 0.0.0.0 0.0.0.0 172.16.7.1 so that anybody in the 172.16.11.x subnet can access certain resources on the 172.16.7.x subnet and use the 172.16.7.1 for that routing.

 

[tschouten]

I have a question, just a vague idea in the back of my head. Is some of your dhcp pool going into 172.16.8.1 255.255.255.0 range? If so I may have spotted why you are seeing intermittent problems. If you are using CIDR and are summarizing your routing tables this may be the whole problem. The 172.16.11.1 255.255.252.0 address you are using on the ethernet0 interface contains the leading subnet in it that breaks down to 172.16.8.0.

If you use the anding process you will see what I mean:

10101100.00010000.00001011.00000001 =172.16.11.1
11111111.11111111.11111100.00000000 =255.255.252.0
___________________________________
00101100.00010000.00001000.00000000 =172.16.8.0

This could be causing you a problem if your pool has the .8 portion in its' range.

 

[balartar123]

I had looked at that issue but we are only using 172.16.11.x range for the entire child1 domain. We thought that the subnet mask might be an issue because we were looking at the router addressing itself as 172.16.8.0 because of the subnet 255.255.252.0. Could that be causing some of our issues or as long as 172.16.11.x is included in the subnet should we be ok?

 

[irasman]

What you need is a consultant drop me a line.
TH

 

[balartar123]

The issue has been resolved. What was happening was that we had a route statement in the router to get to the 172.16.7.x addresses but the gateway on 172.16.7.x didn't have a return route to the 172.16.11.x addresses. The reason that it was working sometimes but then failing was due to the device that was the gateway using the proxy arp table. We have added the route statement to the gateway and we are working fine now. Thanks for all the help.

Scott