Detecting a swtich

snipped-for-privacy@gmail.com wrote in news:1114590799.617477.218320 @o13g2000cwo.googlegroups.com:

if you use a traffic analyzer - e.g.: ethereal - you can tell if it's a hub by the traffic. you will see traffic for other MAC addy's. on a switch you will only see your own and the broadcasts.

as far as managed or unmanaged. if it's managed - it will have an IP addy and you will be able to telnet to it to manage it. but that can be turned off by SA.

In article , wrote: :Is there a tool that lets u detect if the device is a hub, unmanaged :switch or a managed switch connected on a network.?

Not reliably.

Another poster indicated that with a hub, you can see frames destined for other MAC addresses, but not with a switch. That is not quite the case, as there are instances when you will see other destination MACs:

a) The switch doesn't know which port the destination is on, and so floods the packet to all ports in the same VLAN;

b) The switch MAC table is full and the switch is designed to flood packets in that situation;

c) Multicast and broadcast and various other packets don't have -your- MAC address as their destination: they have standard MAC addresses that are specially recognized by your system.

d) The switch has been configured to 'span' (or 'mirror') traffic to your port. When traffic is spanned/mirrored, it is switch dependant as to whether VLAN tags are removed, and switch dependant as to whether the original source MAC is preserved or if the source MAC is replaced with the MAC of the egress switch port.

e) Your system might be on a shared media segment itself, rather than a fully-switched segment, so there might be legitimate other destination MAC addresses on your segment.

These factors don't mean you can't apply heuristics -- e.g., if you see TCP SYN packets for other destinations, but seldom SYN ACK, then you are likely connected to a switch. Similarily, if you see ARP replies from other hosts then either you are attached to a hub or you are on a shared segment.

One factor you can look at is whether your connection is full duplex or not. If it is full duplex, then either there is a misconfiguration problem, or else you are attached to a switch: hubs are inherently half-duplex.

You cannot reliably detect whether a switch is "managed" or not.

You can monitor for packets addressed to the switch IP, but you probably won't see them unless you are on a shared media segment yourself -- because when a packet arrives at a switch that is addressed to the switch, the switch is going to know exactly which port and MAC address the packet is from, and is only going to reply there.

Similarily, you can monitor for packets -from- the switch IP, but again you are not likely to see them because of the above factor.

If you see RIP broadcasts or RIP or OSPF multicasts coming from the switch, the switch is -probably- managed and probably a Layer 3 or higher device... but then one gets into debates about what it means for a switch to be "managed". A configurable switch is not necessarily a "managed" switch, and a switch which allows you to telnet or http in and see per-port error counters and so on, is not necessarily going to be willing to talk SNMP or RMON.

In article , Walter Roberson wrote: |In article , | wrote: |:Is there a tool that lets u detect if the device is a hub, unmanaged |:switch or a managed switch connected on a network.?

|Not reliably.

I forgot a case:

Some switches, such as Cisco switches, may send out proprietary packets such as CDP (Cisco Discovery Protocol) packets. If you see CDP packets and the IP embedded in the CDP matches the device IP, then you can be fairly sure that the device is a managable Cisco device. Most non-Cisco switches will, though, pass on CDP instead of blocking it, so the presence of CDP packets by themselves is not enough.

You can look for -hints- in factors such as the structure of the BPDU's and details of the spanning tree costs passed to you. This is not reliable.

You can always try sending SNMP or RMON packets with a community of "public" or "rmon" respectively -- if the device replies then you know it is managed. If the device does not reply, then it just might not be allowing that community string, or might be requiring SNMP Authentication, or might be set to disallow SNMP from you.

If you somehow see SYSLOG (udp 514) or SNMP Trap (UDP/TCP 162) from the device, you know it is managed... but see the notes in the previous posting about it being unlikely you would see these.

Thanks a ton Roberson!!!. This was quite detailed.

Manohar