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

Discussion in 'Cisco' started by Georg Mueller, Oct 11, 2006.

  1. 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
     
    Georg Mueller, Oct 11, 2006
    #1
    1. Advertising

  2. Georg Mueller

    mak Guest

    Georg Mueller wrote:
    > 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.


    well, here you have it.
    change config of your clock ...
    > 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.

    well maybe the address doesn't exist.

    > 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.


    again, just because the clock wants to send a packet to this address, doesn't mean
    there is a mac address listening for it.
    > 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
    >
     
    mak, Oct 11, 2006
    #2
    1. Advertising

  3. mak wrote:

    > Georg Mueller wrote:
    > > 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.

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


    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.

    > > 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.

    > well maybe the address doesn't exist.


    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.

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


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

    Regards,
    Georg
     
    Georg Mueller, Oct 11, 2006
    #3
  4. On Tue, 10 Oct 2006 22:47:17 -0700, Georg Mueller wrote:

    > Our LAN consists of a few subnets which are routed.
    >


    [snip]

    >
    > 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.


    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.

    >
    > How do I debug this issue?


    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
    http://www.cisco.com/warp/public/707/22.html#topic10 for an explaination.

    >
    > 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?


    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.

    > client's default gateway must always be in the same subnet as the
    > client.


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

    --
    Rgds,
    Martin
     
    Martin Gallagher, Oct 12, 2006
    #4
  5. In article <>,
    "Georg Mueller" <> wrote:

    > 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?


    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 <acl#>". 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.

    > 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.


    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.

    > 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


    --
    Barry Margolin,
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***
     
    Barry Margolin, Oct 12, 2006
    #5
  6. Georg Mueller

    Everyman Guest


    > 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.


    ..
    ..
    ..
    > Greetings from Germany
    > Georg



    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.
     
    Everyman, Oct 12, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. network buyer
    Replies:
    0
    Views:
    777
    network buyer
    Dec 13, 2009
  2. network buyer
    Replies:
    3
    Views:
    1,765
    ciscoberton
    Jun 7, 2011
  3. network buyer
    Replies:
    2
    Views:
    1,276
    tammyyonny
    May 12, 2011
  4. network buyer
    Replies:
    1
    Views:
    898
    saarllc
    May 6, 2010
  5. Network/Software Buyer
    Replies:
    0
    Views:
    601
    Network/Software Buyer
    Mar 18, 2010
Loading...

Share This Page