In article , wrote: :This is santa. I am sorry to ask thi ssilly question. we are using :4-port switch-cum-router, also some hubs in home office, also linksys :5-port workgroup hub for some desktops, how to findout which device is :based on bridge implementtaion?.
If the devices are "managed", then you can use SNMP to probe the device facilities.
If not... well, there are some factors that might happen to provide useful clues:
- hubs are *always* half-duplex on all ports. If there is even one full-duplex port in the bunch, then the device has at least one built-in bridge (but does not necessarily bridge all the ports together.)
- hubs are not able to mix speeds, so if there are a mix of 10 and 100 speeds on a device, then the device has at least one built-in bridge (but could potentially be acting as a hub between the same-speed devices, and bridging the different speeds together; such a design did not last very long in the marketplace, but 3Com amongst others made devices like that.)
- hubs will always pass on BPDU ("spanning tree") packets from remote switches; switches are not supposed to pass on BPDU from remote switches (but it isn't uncommon for cheap unmanaged switches to pass on BPDU :(); routers never pass on BPDU from remote switches. Inbetween there is the "layer 3 switch", which might selectively pass on BPDU depending on how it is configured.
- in practice, hubs will transparently pass on "overlength" packets such as full-sized IP packets that have been extended with 802.1Q VLAN tags; unmanaged switches vary with how they handle such packets, with older switches more likely to discard them. "newer" managed switches are often configurable as to whether they pass on or discard
802.1Q packets.
:Also if a Linux machine can be converted into 4-port switch/router, :does Linux bridge has to be enabled in Linux kernel?.
No, but that might be the easiest approach. Recall that the switching and routing functions could be handled by a user-level process that is accepting all of the raw packets. Whether that approach were to be taken, or whether one relied on the kernel, or whether the functionality was pushed into the device driver level, would be a development decision -- and like all development decisions, would depend upon the extent to which the kernel and system libraries provided close matches in functionality to what was required for the purposes of the "converted" device. The balance might, for example, be different for an "embedded" device with uLinux, compared to a full-sized PC; and the balance might shift again if the device needed to handle wireless (WLAN).