layer-2 tracking - TCP-IP

This is a discussion on layer-2 tracking - TCP-IP ; we have ethernet network with many segments, something like campus, quite a lot of cascading switches, most of them unmanageable. sometimes, we have guests who come with their notebuk and attaches to the lan. their ip address is all i ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: layer-2 tracking

  1. layer-2 tracking

    we have ethernet network with many segments, something like campus, quite a
    lot of cascading switches, most of them unmanageable.
    sometimes, we have guests who come with their notebuk and attaches to the
    lan. their ip address is all i may notice, but is har to detect where is it
    located, which part of campus

    is there some tool to trace on which switch is the computer with particular
    ip address attached? something like "tracert" command does, telling me over
    which routers is the computer connecte.
    but, in my case, i will like to trace not layer-3, but layer-2 info, i mean
    to check switches [supposing each port on each switch has its own layer-2
    address, is it correct?]

    thnx



  2. Re: layer-2 tracking

    sali wrote:
    > we have ethernet network with many segments, something like campus,
    > quite a lot of cascading switches, most of them unmanageable.
    > sometimes, we have guests who come with their notebuk and attaches
    > to the lan. their ip address is all i may notice, but is har to
    > detect where is it located, which part of campus


    > is there some tool to trace on which switch is the computer with
    > particular ip address attached? something like "tracert" command
    > does, telling me over which routers is the computer connecte. but,
    > in my case, i will like to trace not layer-3, but layer-2 info, i
    > mean to check switches [supposing each port on each switch has its
    > own layer-2 address, is it correct?]


    Not with unmanaged switches.

    With managed switches you would examine the forwarding tables on the
    switches looking to see out which port traffic for that laptops MAC
    address goes. Any MAC address on a switch isn't really interesting in
    this exercise.

    The other option is to start wandering around with a packet sniffer,
    connecting it inline on ports here and there looking for traffic
    to/from the MAC address in question.

    This is probably as much a question for comp.dcom.lans.ethernet as
    anything else, so I've set followups to that group.

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  3. Re: layer-2 tracking

    In article , sali wrote:
    >we have ethernet network with many segments, something like campus, quite a
    >lot of cascading switches, most of them unmanageable.
    >sometimes, we have guests who come with their notebuk and attaches to the
    >lan. their ip address is all i may notice, but is har to detect where is it
    >located, which part of campus
    >


    >ip address attached? something like "tracert" command does, telling me over
    >which routers is the computer connecte.
    >but, in my case, i will like to trace not layer-3, but layer-2 info, i mean
    >to check switches [supposing each port on each switch has its own layer-2
    >address, is it correct?]
    >


    There is no -reliable- way of doing this, even when you don't
    count the effects of VLANs. If you have fully managed switches,
    you can query the MAC addresses known for each interface, but
    those MAC addresses tend to time out fairly quickly. It isn't uncommon
    to have to narrow down the list of potential switches by finding the
    MAC in the tables of other switches, checking the number of known
    MAC addresses for that interface over time (to figure out whether
    it is an untagged trunk, possibly trunked without authorization),
    and chase through to the next switch connected along that port
    and repeat. Dead ends are more common than not. When I set up
    this kind of automated probing, it was not uncommon for a device
    to be present for a single SNMP probe (about 10 minutes apart)
    every few hours.

    Even if you are all on the same Layer-2 network with no in-house
    layer-3, you often cannot -successfully- do a "layer 2 ping".
    (you can find software that attempts that) as the destination
    often will simply refuse to respond.

    Roberson's First Rule Of Network Monitoring: SNMP Agents *lie*.
    Some worse than others, some in ways that can be worked around,
    but I have yet to find one that did not lie about -something-.

    You mention that most of your switches are unmanageable and
    are cascaded: if so, then you should rate the average time to
    track down any particular MAC address in the *months*. Yes,
    many will show up nicely in the the first probe, but the ones that
    do not will often hide quite effectively. Replacing the
    unmanaged switches with managed switches gives you a fighting chance,
    but with those guests coming along, you should expect to lose a
    fair number of the bouts.


    Devices that are harder than usual to track down:

    - Printers. Not uncommon for the lower-end networked models to send
    out data on valid MAC addresses that they will otherwise refuse to
    acknowledge.

    - Virtual OS's for PCs. I do not recall now which one was the worst,
    but on some of the programs, each different virtual instance will use
    a different MAC that only answers when that particular virtual
    instance is the one in control -- but the virtual instance might
    be sending out the packets "in the background" while it is configured
    but not the primary virtual instance. Keep-alives for example

    - There is some random function associated with MS Windows and
    multicast that triggers the Windows boxes to send out packets with
    virtual MAC sources when sending to multicast destinations. There
    was a distinct pattern to the MACs that depended upon the multicast
    destination IP, but all the official sources I could find indicated
    that those MAC addresses were not reserved for anything. Of course
    this was difficult to track down as it was intermittent and would
    "move" from switch port to switch port as different machines
    happened to send out those packets. The switches didn't know to
    keep multiple copies of the MAC around because the MACs were not
    in any official broadcast or multicast range. Unfortunately I
    am having trouble tracking down my technical notes on this problem.
    My memory associates HP's printer availability checking agent with
    this problem, but that could be a false memory.

  4. Re: layer-2 tracking

    "Walter Roberson" wrote in message
    news:0oirk.202799$gc5.9408@pd7urf2no...
    > In article , sali wrote:
    >>sometimes, we have guests who come with their notebook and attaches to the
    >>lan. their ip address is all i may notice, but is hard to detect where is
    >>it
    >>located, which part of campus
    >>

    >
    > There is no -reliable- way of doing this,


    thnx [thnx to rick jones who told the same thing too]

    basicly does it mean that the only way to trace-down [with dumb switches]
    where the suspicious ip address [laptop] is attached, is to block that
    address at the main firewall and to wait someone come and comply he can't
    reach internet, true?

    does it count if konowing that ip addresses of each attached device is
    obtained by dhcp, dynamicaly [of course, excluding few predefined well known
    campus servers and networked printers which have fixed ip]



  5. Re: layer-2 tracking

    On Thu, 21 Aug 2008 21:35:43 +0100, sali wrote:

    > "Walter Roberson" wrote in message
    > news:0oirk.202799$gc5.9408@pd7urf2no...
    >> In article , sali
    >> wrote:
    >>>sometimes, we have guests who come with their notebook and attaches to
    >>>the lan. their ip address is all i may notice, but is hard to detect
    >>>where is it
    >>>located, which part of campus
    >>>
    >>>

    >> There is no -reliable- way of doing this,

    >
    > thnx [thnx to rick jones who told the same thing too]
    >
    > basicly does it mean that the only way to trace-down [with dumb
    > switches] where the suspicious ip address [laptop] is attached, is to
    > block that address at the main firewall and to wait someone come and
    > comply he can't reach internet, true?
    >
    > does it count if konowing that ip addresses of each attached device is
    > obtained by dhcp, dynamicaly [of course, excluding few predefined well
    > known campus servers and networked printers which have fixed ip]


    Well, that makes it a bit easier and a bit more difficult.

    1) Go to the dhcp server and find the MAC associated with the IP.

    2) Block that MAC in the DHCP server, and block the IP at the firewall.
    Otherwise the user will get a fresh IP address instead of complaining.
    (Also make sure your DHCP server does not give out that IP address later
    to someone else!)

    3) Look up to which manufacturer that MAC address is assigned. You may
    get lucky in that knowing the manufacturer might help in tracking down
    the machine in question.

    Obviously, the user might just use some random unused IP address in the
    DHCP range. That would almost put you back at square one.

    If all else fails:

    1) set of a continuous ping to the IP in question. Use arping if he uses
    a firewall to block pings. Use a higher frequency than 1 ping per second
    for best results.

    2) start unplugging all connections for a second or so. Other users will
    be inconvenienced, but not very much. Note when a break in the ping
    replies corresponds to you unplugging a cable. Start at the core switch
    (es) and work out to the hub-switches.

    HTH,
    M4

  6. Re: layer-2 tracking

    Walter Roberson wrote:

    > you often cannot -successfully- do a "layer 2 ping". (you can find
    > software that attempts that)


    The MPE/HP-UX linkloop command or its linux port at:

    http://freshmeat.net/projects/linkloop/

    come to mind

    rick jones
    --
    web2.0 n, the dot.com reunion tour...
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  7. Re: layer-2 tracking

    sali wrote:
    > basicly does it mean that the only way to trace-down [with dumb
    > switches] where the suspicious ip address [laptop] is attached, is
    > to block that address at the main firewall and to wait someone come
    > and comply he can't reach internet, true?


    It wouldn't surprise me if that was the most effective way.

    > does it count if konowing that ip addresses of each attached device
    > is obtained by dhcp, dynamicaly [of course, excluding few predefined
    > well known campus servers and networked printers which have fixed
    > ip]


    It could still be anywhere in the broadcast domain.

    Since you mention DHCP, if you are concerned about random devices on
    your network, why not restrict DHCP service to a known set of MAC
    addresses?

    rick jones
    --
    firebug n, the idiot who tosses a lit cigarette out his car window
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  8. Re: layer-2 tracking

    "Martijn Lievaart" wrote in message
    newsan.2008.08.21.20.58.35@rtij.nl.invlalid...
    > On Thu, 21 Aug 2008 21:35:43 +0100, sali wrote:
    >
    >> "Walter Roberson" wrote in message
    >> news:0oirk.202799$gc5.9408@pd7urf2no...
    >>> In article , sali
    >>> wrote:
    >>>>sometimes, we have guests who come with their notebook and attaches to
    >>>>the lan. their ip address is all i may notice, but is hard to detect
    >>>>where is it
    >>>>located, which part of campus
    >>>>
    >>>>
    >>> There is no -reliable- way of doing this,

    >>
    >> thnx [thnx to rick jones who told the same thing too]
    >>
    >> basicly does it mean that the only way to trace-down [with dumb
    >> switches] where the suspicious ip address [laptop] is attached, is to
    >> block that address at the main firewall and to wait someone come and
    >> comply he can't reach internet, true?
    >>
    >> does it count if konowing that ip addresses of each attached device is
    >> obtained by dhcp, dynamicaly [of course, excluding few predefined well
    >> known campus servers and networked printers which have fixed ip]

    >
    >


    > 1) set of a continuous ping to the IP in question. Use arping if he uses
    > a firewall to block pings. Use a higher frequency than 1 ping per second
    > for best results.



    arping seems good.

    but again, does it help knowing that it is not likely to have guest laptop
    alone at the classroom/offoce.
    i mean, usualy, there are few active comps attached to each switch, doeas
    arping return similar or alike return time-footprint when arping two
    neigbrhood computers connected to the same switch?

    what if issuing thruly networked arping, each comp arpinging all other
    computers [of course just for some limited test time not to overload the
    network], and capturing the result, and then analysing the overall result
    and looking which computer is "topologicaly" the nearest to the targeted
    guest laptop

    i can try it, but is there chance that this idea might work?

    to rick jones:
    i am not so much concerned about guest laptops to forbid their access
    without having their mac registerd, just wandered if i could know where they
    are attached

    thnx for all yours answers and experience!




  9. Re: layer-2 tracking

    sali wrote:
    > arping seems good.


    > but again, does it help knowing that it is not likely to have guest
    > laptop alone at the classroom/offoce.


    > i mean, usualy, there are few active comps attached to each switch,
    > doeas arping return similar or alike return time-footprint when
    > arping two neigbrhood computers connected to the same switch?


    > what if issuing thruly networked arping, each comp arpinging all
    > other computers [of course just for some limited test time not to
    > overload the network], and capturing the result, and then analysing
    > the overall result and looking which computer is "topologicaly" the
    > nearest to the targeted guest laptop


    > i can try it, but is there chance that this idea might work?


    You will be looking to tease-out microseconds. ARP packets are pretty
    small, so if netperf TCP_RR experience is any guide the biggest part
    of the latency on a LAN comes from the stack processing at either end.
    To see what I mean, run a TCP_RR test between two systems with a
    request/response size set to be 'close' to the side of an ARP request
    and response. Include CPU utilization measurements and then compare
    the service demands (microseconds of CPU per transaction) to the RTT.

    Now, admittedly, ARP will be a smaller number of "layers" gone through
    and so a shorter code path. But you may still be looking to tease
    microseconds out of something on the order of several score
    microseconds, with what is likely to be somewhat "noisy" data because
    the networks won't be idle while you are doing this and the CPU
    horsepower of all the systems at the far side of the arping will
    probably vary considerably from machine to machine. So a slow system
    closer and a fast system father may look to be the same distance from
    you.

    Yet another complication is that most Gigabit Ethernet and higher NICs
    have interrupt coalescing, with defaults set to favor CPU utilization
    of bulk transfers over low latency, and that can have a big effect on
    the round trip times on something like a ping or netperf TCP_RR:

    ftp://ftp.cup.hp.com/dist/networking...cy_vs_tput.txt

    Long term, the best thing (IMO) for you to do is start replacing
    unmanaged with managed switches. Otherwise, you are heading upstairs
    without a lantern and likely to be eaten by a Grue.

    rick jones
    --
    portable adj, code that compiles under more than one compiler
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

+ Reply to Thread