A: You don't have bridging capability in your
kernel. Get a 2.0 or greater kernel, and recompile with
the BRIDGING option enabled.
A:
-
Did you enable bridging using brcfg -ena? (brcfg should say bridging is ENABLED)
-
Did you put the interfaces into promiscuous mode?
(issue the ifconfig
command. The PROMISC flag
should be on for both interfaces.)
-
If using multiple-media interface adapters, make
sure that the correct one is enabled. You may need to
use the config/setup program that came with the network
interface card.
A: This is because there is no IP address bound to
any of bridge interfaces. A bridge is to be a transparent
part of a network.
A: Nothing! All routing intelligence is handled by
the bridging code in the kernel. To see the ethernet
addresses as they are learned by the bridge, use the
brcfg program in debug
mode:
A: Due to the nature of a bridge, a traceroute should NOT show the
bridge as a part of the path. A bridge is to be a
transparent component of the network.
A: No. The bridging code in the kernel takes care
of the packet transport. IP_FORWARD is for a gateway that has IP
addresses bound to its interfaces.
A: No. Every port on a bridge intentionally is
assigned the same physical ethernet address by the
bridging code.
A: During the kernel config, answer "Y" to the question, Prompt for development and/or incomplete
code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?].
A: A bridge resets the 3/4/5 hubs rule. A bridge
does not deal with packets the way a hub does, and is
therefore not a contributor to timing problems on a
network.
A: Yes, a bridge can tie together a 10Mb segment
with a 100Mb segment. As long as the network card on the
fast network is 100Mb capable, TCP takes care of the
rest. While it's true that the packets from a host in the
100Mb network communicating to a host in the 10Mb network
are moving at only 10Mb/s, the rest of the traffic on the
fast ethernet is not slowed down.