|
NAMEng_bridge —
Ethernet bridging netgraph node type
SYNOPSIS#include <sys/types.h>
#include <netgraph/ng_bridge.h>
DESCRIPTIONThebridge node type performs Ethernet bridging over one
or more links. Each link (represented by a connected hook) is used to transmit
and receive raw Ethernet frames. As packets are received, the node learns
which link each host resides on. Packets unicast to a known host are directed
out the appropriate link only, and other links are spared the traffic. This
behavior is in contrast to a hub, which always forwards every received packet
to every other link.
LOOP DETECTIONThebridge node incorporates a simple loop detection
algorithm. A loop is when two ports are connected to the same physical medium.
Loops are important to avoid because of packet storms, which severely degrade
performance. A packet storm results when the same packet is sent and received
over and over again. If a host is detected on link A, and is then detected on
link B within a certain time period after first being detected on link A, then
link B is considered to be a looped back link. The time period is called the
minimum stable time.
A looped back link will be temporarily muted, i.e., all traffic received on that link is ignored. IPFW PROCESSINGProcessing of IP packets via the ipfirewall(4) mechanism on a per-link basis is not yet implemented.HOOKSThis node type supports an unlimited number of hooks. Each connected hook represents a bridged link. The hooks are named link0, link1, etc. Typically these hooks are connected to the lower hooks of one or more ng_ether(4) nodes. To connect the host machine to a bridged network, simply connect the upper hook of an ng_ether(4) node to the bridge node.Instead of naming a hook linkX the hook might be also named uplinkX. The node does not learn MAC addresses on uplink hooks, which keeps the internal address table small. This way it is desirable to connect the lower hook of an ng_ether(4) node to an uplink hook of the bridge, and ignore the complexity of the outside world. Frames with unknown MACs are always sent out to uplink hooks, so no functionality is lost. Frames with unknown destination MAC addresses are replicated to any available hook, unless the first connected hook is an uplink hook. In this case the node assumes, that all unknown MAC addresses are located soley on the uplink hooks and only those hooks will be used to send out frames with unknown destination MACs. If the first connected hook is an link hook, the node will replicate such frames to all types of hooks, even if uplink hooks are connected later. CONTROL MESSAGESThis node type supports the generic control messages, plus the following:
SHUTDOWNThis node shuts down upon receipt of aNGM_SHUTDOWN
control message, or when all hooks have been disconnected. Setting the
persistent flag via a NGM_BRIDGE_SET_PERSISTENT
control message disables automatic node shutdown when the last hook gets
disconnected.
FILES
SEE ALSOif_bridge(4), netgraph(4), ng_ether(4), ng_hub(4), ng_one2many(4), ngctl(8)HISTORYTheng_bridge node type was implemented in
FreeBSD 4.2.
AUTHORSArchie Cobbs <archie@FreeBSD.org>
Visit the GSP FreeBSD Man Page Interface. |