1. Home
  2. Cisco Systems
  3. Curious Ip address: Cisco Sup720 MAC/IP/ARP debugging

Curious Ip address: Cisco Sup720 MAC/IP/ARP debugging

Our LAN consists of a few subnets which are routed.

A few days ago, when looking at the firewall log files I noticed that our radio controlled clock sends NTP responses to a private IP address

10.0.41.1. Curious: this IP address is not part of our LAN, nor do we route any 10.X.X.X subnet. Thus, the packet is routed from our internal router (Cisco C6509/Sup720) to the firewall where it is blocked.

I've created a monitoring session on the switch (C2950) to which the radio controlled clock is connected. Ethereal told me that the Cisco router is source or destination of the 10.0.41.1 NTP requests/responses.

10.0.41.1 ---> Cisco router ---> ntp clock [ 192.168.1.X ] ---> back to Cisco router ---> to firewall ---> [udp packet is blocked ]

I connected to the router and looked at the ARP table. But "sh arp" gives me only addresses from our regular internal subnets. I want to know the MAC address to locate the switch port for 10.0.41.1 within our LAN. I don't know how to determine the MAC address from the 10.0.4.1 address as "sh arp" did not give me the MAC address.

How do I debug this issue?

Another question is: why does the Cisco router even route the NTP request packets originating from a subnet in which the Cisco router has no ip address configured to act as a gateway? As far as I know, a client's default gateway must always be in the same subnet as the client. On the way back (NTP response packets), the Cisco router has no route to 10.X.X.X, and it uses the default route to the internet. This is clear to me, but how about the way forth?

Any help would be appreciated

Greetings from Germany Georg

Reply to
Georg Mueller
Loading thread data ...

well, here you have it. change config of your clock ...

well maybe the address doesn't exist.

again, just because the clock wants to send a packet to this address, doesn't mean there is a mac address listening for it.

Reply to
mak

It is not a clock issue. I have contacted the clock manufacturer's support which reviewed the configuration and I've reviewed the clock configuration myself. There is no such IP address configured.

You mean, my Ethereal network sniffer has hallucinations? I've analyzed the network traffic from/to the radio clock. There is a REQUEST from 10.0.41.1 and then the clock RESPONDS. If there is a request (routed thru the router), there must be a MAC address.

See above. It isn't the clock which starts sending. The clock RESPONDS. But where is the initiator 10.0.41.1? Regards, Georg

Reply to
Georg Mueller

[snip]

ARP entries are there to map local (subnets connected to the router) addresses to MAC addresses. Since 10.0.4.1 is not on a locally connected network there is no need nor point to having an ARP table entry fot it.

The router is merely forwarding traffic to the NTP server. You need to find out where the traffic enters the router.

You could sniff your other subnets to see from where the errant packets enter the router on their way to the NTP server. The source MAC of those frames will be the MAC of the device the forwarded the traffic to the router.

You could use an ACL with the log-input keyword on the router. See

formatting link
for an explaination.

Routers of all stripes regularly forward traffic with source addresses half a world away. All the router looks at is the destination address to see where it should go next.

Yes, but a misconfigured or malicious client can put the wrong source address in a packet and still forward it to the correct gateway.

Reply to
Martin Gallagher

You can use "debug ip packet" to see which interface the original request packets are arriving on. Make an ACL that matches these NTP packets, and use "debug ip packet detailed ". You should also be able to see the originating MAC address.

Once you have the interface and MAC address, you can then check the MAC address table on the switch connected to that interface to see where that MAC is.

Routing is normally based only on destination address, not source address. So the request packets are routed because the destination address it the address of the clock, and you don't have any filters blocking the packets.

Reply to
Barry Margolin

. . .

From do You know that this packet is initiated out of the Sup720? Maybe 720 generates this packet for ntp purposes and use such strange ip address (together with internal nat)? I know that it is strange but I met similar concept with Cisco CNA (Cisco Network Assistant). Does Your Sup720 use ntp clock services? Is it proper synchronized?

Wlodek.

Reply to
Everyman

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.