Archived from groups: comp.dcom.lans.ethernet (
More info?)
In article <1127058654.097819.44410@g49g2000cwa.googlegroups.com>,
<santa19992000@yahoo.com> 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).
--
Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec
Facebook
Twitter
Instagram