debug ip packet output help needed

[stevennowell]

I have a customer router who bri will make a call every minute or so. I suspected some kind of keep alive process not that was being marked intersting by my dialer list due to the pattern of the calls, so I debuged ip packet for the acl used by the dialer list and got the output below. My question is about what is in the parenthesis next to the source and dest? I have always thought that this was the port number, but you will see in this case I am showing a 0 for this value. I need to identify the nature of this udp process, but I am not aware of any udp process using this port. Thanks for any help.

Aug 26 18:23:12.211 cdt: %SEC-6-IPACCESSLOGP: list 101 permitted udp 10.213.128.44(0) -> 10.213.128.1(0),

[vijayasankar]

Hi,

Check what is the source ip and destination ip involved in this debug capture, to trace down what is happening.

What is the present configuration of access-list 101.

Im not sure about the port 0 stuff.

Looks like PIX uses UDP port 0, when an inside client intiates a PPTP connection over PAT. Not sure whether this is related to your setup.

HTH

-VJ

[Richard Burts]

VJ

I doubt that the PIX behavior is related to this situation. This is a very common behavior. If an access list is permitting and denying based on address (or protocol) but is not examining the port numbers as part of its decision process then when it is configured to log hits in the access list it will report the port number as 0.

I am confident that if Steve would post the content of the access list that it is not asking for examination of values of any ports. If he changes the access list so that it checks for values in UDP packets (since the debug output says it was a UDP packet) or values in TCP packets then the debug output will report the port value.

Perhaps a more effective way to get to the answer would be to do debug dialer. That output should be helpful in identifying the source of the dialing activity.

HTH

Rick

[stevennowell]

Here is the acl in question for my dialer list. in previous debug dialers I am seeing unicast sourced locally with destination to dialer map. This is the cause of repetitive dialing. I also know from debug ip packet that this is a udp packet. I could easily filter by dialer list, but I am really want to understand why I am seeing this udp packet come from router.

I should add that this customer has 500 of these sites and this is the only one having the problem. All configs are standard and I have compared this dialer list to sites that are not having this problem and they are the same.

access-list 101 deny ip any host 255.255.255.255

access-list 101 deny eigrp any any

access-list 101 deny ospf any any

access-list 101 permit ip any any log

dialer-list 1 protocol ip list 101

[vijayasankar · Accepted solution]

HI Steve

From the ACL we could see that you are denying only the ip broadcasts, eigrp and ospf packets.

Any other packets will trigger the dialer.

You can modify the ACL as below, to trace the source/destination port of the udp packet

which is triggering the traffic.

access-list 101 deny ip any host 255.255.255.255

access-list 101 deny eigrp any any

access-list 101 deny ospf any any

access-list 101 permit tcp any range 0 65535 any range 0 65535 log

access-list 101 permit udp any range 0 65535 any range 0 65535 log

HTH

-VJ

[Richard Burts]

VJ

This certainly does implement the checking for port values that I suggested. I see that you have removed the permit ip any any and replaced it with permit tcp ... and permit udp ... I believe that the access list still needs to end with permit ip any any. Your version would not permit ICMP (or GRE, or ESP, or any number of other protocols that might be present depending on what the network is doing).

Steve if you add the lines about permit tcp port range and permit udp port range in your access list before the permit ip any any then I believe that you will get the information that you are looking for to identify the particular traffic that is initiating the dial.

HTH

Rick

[vijayasankar]

Hi Richard,

Thanks a lot for correcting me.

-VJ

[stevennowell]

Thanks a lot for the help here. As it turns out before implementing acl changes you requested, I ran sh run | include with ip in question and found extra ntp server on this to dest that was same as isdn hub. Removed that and problem stopped.

Thanks again

[stevennowell]

I should have added to my comment above that ouput in my original post is the interesting traffic that is initiating the call to my hub. The dialer list is correctly configured, but I am trying to identify the source of the unicast that is given as part of my debug ip packet ouput.