Add a section about using FreeBSD as a bridge.
PR: docs/19105 Submitted by: Steve Peterson <steve@zpfe.com>
This commit is contained in:
Nik Clayton
parent
a42eebcfca
commit
4f20439b93
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=7416
2 changed files with 330 additions and 2 deletions
|
|
@ -1,7 +1,7 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.25 2000/06/08 01:55:49 jim Exp $
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.26 2000/06/13 18:05:22 jim Exp $
|
||||
-->
|
||||
|
||||
<chapter id="advanced-networking">
|
||||
|
|
@ -323,6 +323,170 @@ Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1)
|
|||
&man.traceroute.8;.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="bridging">
|
||||
<title>Bridging</title>
|
||||
|
||||
<para><emphasis>Written by Steve Peterson
|
||||
<email>steve@zpfe.com</email></emphasis>.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>It is sometimes useful to divide one physical network (i.e., an
|
||||
Ethernet segment) into two separate network segments, without having
|
||||
to create IP subnets and use a router to connect the segments
|
||||
together. A device that connects two networks together in this
|
||||
fashion is called a bridge. and a FreeBSD system with two network
|
||||
interface cards can act as a bridge.</para>
|
||||
|
||||
<para>The bridge works by learning the MAC layer addresses (i.e.,
|
||||
Ethernet addresses) of the devices on each of its network interfaces.
|
||||
It forwards traffic between two networks only when its source and
|
||||
destination are on different networks.</para>
|
||||
|
||||
<para>In many respects, a bridge is like an Ethernet switch with very
|
||||
few ports.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Situations where bridging is appropriate</title>
|
||||
|
||||
<para>There are two common situations in which a bridge is used
|
||||
today.</para>
|
||||
|
||||
<sect3>
|
||||
<title>High traffic on a segment</title>
|
||||
|
||||
<para>Situation one is where your physical network segment is
|
||||
overloaded with traffic, but you don't want for whatever reason to
|
||||
subnet the network and interconnect the subnets with a
|
||||
router.</para>
|
||||
|
||||
<para>Let's consider an example of a newspaper where the Editorial and
|
||||
Production departments are on the same subnetwork. The Editorial
|
||||
users all use server A for file service, and the Production users
|
||||
are on server B. An Ethernet is used to connect all users together,
|
||||
and high loads on the network are slowing things down.</para>
|
||||
|
||||
<para>If the Editorial users could be segregated on one network
|
||||
segment and the Production users on another, the two network
|
||||
segments could be connected with a bridge. Only the network traffic
|
||||
destined for interfaces on the "other" side of the bridge would be
|
||||
sent to the other network, reducing congestion on each network
|
||||
segment.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Filtering/traffic shaping firewall</title>
|
||||
|
||||
<para>The second common situation is where firewall functionality is
|
||||
needed without IP Masquerading (NAT).</para>
|
||||
|
||||
<para>An example is a small company that is connected via DSL or ISDN
|
||||
to their ISP. They have a 13 address global IP allocation for their
|
||||
ISP and have 10 PCs on their network. In this situation, using a
|
||||
router-based firewall is difficult because of subnetting
|
||||
issues.</para>
|
||||
|
||||
<para>A bridge-based firewall can be configured and dropped into the
|
||||
path just downstream of their DSL/ISDN router without any IP
|
||||
numbering issues.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Configuring a bridge</title>
|
||||
|
||||
<sect3>
|
||||
<title>Network interface card selection</title>
|
||||
|
||||
<para>A bridge requires at least two network cards to function.
|
||||
Unfortunately, not all network interface cards as of FreeBSD 4.0
|
||||
support bridging. Read &man.bridge.4; for details on the cards that
|
||||
are supported.</para>
|
||||
|
||||
<para>Install and test the two network cards before continuing.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Kernel configuration changes</title>
|
||||
|
||||
<para>To enable kernel support for bridging, add the</para>
|
||||
|
||||
<programlisting>option BRIDGE</programlisting>
|
||||
|
||||
<para>statement to your kernel configuration file, and rebuild your
|
||||
kernel.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Firewall support</title>
|
||||
|
||||
<para>If you are planning to use the bridge as a firewall, you will
|
||||
need to add the IPFIREWALL option as well. Read <xref
|
||||
linkend="firewalls"> for general information on configuring the
|
||||
bridge as a firewall.</para>
|
||||
|
||||
<para>If you need to allow non-IP packets (such as ARP) to flow
|
||||
through the bridge, there is an undocumented firewall option that
|
||||
must be set. This option is
|
||||
<literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal>. Note that this
|
||||
changes the default rule for the firewall to accept any packet.
|
||||
Make sure you know how this changes the meaning of your ruleset
|
||||
before you set it.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Traffic shaping support</title>
|
||||
|
||||
<para>If you want to use the bridge as a traffic shaper, you will need
|
||||
to add the <literal>DUMMYNET</literal> option to your kernel
|
||||
configuration. Read &man.dummynet.4; for further
|
||||
information.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Enabling the bridge</title>
|
||||
|
||||
<para>Add the line</para>
|
||||
|
||||
<programlisting>net.link.ether.bridge=1</programlisting>
|
||||
|
||||
<para>to <filename>/etc/sysctl.conf</filename> to enable the bridge at
|
||||
runtime. If you want the bridged packets to be filtered by ipfw, you
|
||||
should also add</para>
|
||||
|
||||
<programlisting>net.link.ether.bridge_ipfw=1</programlisting>
|
||||
|
||||
<para>as well.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Performance</title>
|
||||
|
||||
<para>My bridge/firewall is a Pentium 90 with one 3Com 3C900B and one
|
||||
3C905B. The protected side of the network runs at 10mbps half duplex
|
||||
and the connection between the bridge and my router (a Cisco 675) runs
|
||||
at 100mbps full duplex. With no filtering enabled, I've found that
|
||||
the bridge adds about 0.4 milliseconds of latency to pings from the
|
||||
protected 10mbps network to the Cisco 675.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Other information</title>
|
||||
|
||||
<para>If you want to be able to telnet into the bridge from the network,
|
||||
it is OK to assign one of the network cards an IP address. The
|
||||
consensus is that assigning both cards an address is a bad
|
||||
idea.</para>
|
||||
|
||||
<para>If you have multiple bridges on your network, there cannot be more
|
||||
than one path between any two workstations. Technically, this means
|
||||
that there is no support for spanning tree link management.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="nfs">
|
||||
<title>NFS</title>
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.25 2000/06/08 01:55:49 jim Exp $
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.26 2000/06/13 18:05:22 jim Exp $
|
||||
-->
|
||||
|
||||
<chapter id="advanced-networking">
|
||||
|
|
@ -323,6 +323,170 @@ Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1)
|
|||
&man.traceroute.8;.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="bridging">
|
||||
<title>Bridging</title>
|
||||
|
||||
<para><emphasis>Written by Steve Peterson
|
||||
<email>steve@zpfe.com</email></emphasis>.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>It is sometimes useful to divide one physical network (i.e., an
|
||||
Ethernet segment) into two separate network segments, without having
|
||||
to create IP subnets and use a router to connect the segments
|
||||
together. A device that connects two networks together in this
|
||||
fashion is called a bridge. and a FreeBSD system with two network
|
||||
interface cards can act as a bridge.</para>
|
||||
|
||||
<para>The bridge works by learning the MAC layer addresses (i.e.,
|
||||
Ethernet addresses) of the devices on each of its network interfaces.
|
||||
It forwards traffic between two networks only when its source and
|
||||
destination are on different networks.</para>
|
||||
|
||||
<para>In many respects, a bridge is like an Ethernet switch with very
|
||||
few ports.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Situations where bridging is appropriate</title>
|
||||
|
||||
<para>There are two common situations in which a bridge is used
|
||||
today.</para>
|
||||
|
||||
<sect3>
|
||||
<title>High traffic on a segment</title>
|
||||
|
||||
<para>Situation one is where your physical network segment is
|
||||
overloaded with traffic, but you don't want for whatever reason to
|
||||
subnet the network and interconnect the subnets with a
|
||||
router.</para>
|
||||
|
||||
<para>Let's consider an example of a newspaper where the Editorial and
|
||||
Production departments are on the same subnetwork. The Editorial
|
||||
users all use server A for file service, and the Production users
|
||||
are on server B. An Ethernet is used to connect all users together,
|
||||
and high loads on the network are slowing things down.</para>
|
||||
|
||||
<para>If the Editorial users could be segregated on one network
|
||||
segment and the Production users on another, the two network
|
||||
segments could be connected with a bridge. Only the network traffic
|
||||
destined for interfaces on the "other" side of the bridge would be
|
||||
sent to the other network, reducing congestion on each network
|
||||
segment.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Filtering/traffic shaping firewall</title>
|
||||
|
||||
<para>The second common situation is where firewall functionality is
|
||||
needed without IP Masquerading (NAT).</para>
|
||||
|
||||
<para>An example is a small company that is connected via DSL or ISDN
|
||||
to their ISP. They have a 13 address global IP allocation for their
|
||||
ISP and have 10 PCs on their network. In this situation, using a
|
||||
router-based firewall is difficult because of subnetting
|
||||
issues.</para>
|
||||
|
||||
<para>A bridge-based firewall can be configured and dropped into the
|
||||
path just downstream of their DSL/ISDN router without any IP
|
||||
numbering issues.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Configuring a bridge</title>
|
||||
|
||||
<sect3>
|
||||
<title>Network interface card selection</title>
|
||||
|
||||
<para>A bridge requires at least two network cards to function.
|
||||
Unfortunately, not all network interface cards as of FreeBSD 4.0
|
||||
support bridging. Read &man.bridge.4; for details on the cards that
|
||||
are supported.</para>
|
||||
|
||||
<para>Install and test the two network cards before continuing.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Kernel configuration changes</title>
|
||||
|
||||
<para>To enable kernel support for bridging, add the</para>
|
||||
|
||||
<programlisting>option BRIDGE</programlisting>
|
||||
|
||||
<para>statement to your kernel configuration file, and rebuild your
|
||||
kernel.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Firewall support</title>
|
||||
|
||||
<para>If you are planning to use the bridge as a firewall, you will
|
||||
need to add the IPFIREWALL option as well. Read <xref
|
||||
linkend="firewalls"> for general information on configuring the
|
||||
bridge as a firewall.</para>
|
||||
|
||||
<para>If you need to allow non-IP packets (such as ARP) to flow
|
||||
through the bridge, there is an undocumented firewall option that
|
||||
must be set. This option is
|
||||
<literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal>. Note that this
|
||||
changes the default rule for the firewall to accept any packet.
|
||||
Make sure you know how this changes the meaning of your ruleset
|
||||
before you set it.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Traffic shaping support</title>
|
||||
|
||||
<para>If you want to use the bridge as a traffic shaper, you will need
|
||||
to add the <literal>DUMMYNET</literal> option to your kernel
|
||||
configuration. Read &man.dummynet.4; for further
|
||||
information.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Enabling the bridge</title>
|
||||
|
||||
<para>Add the line</para>
|
||||
|
||||
<programlisting>net.link.ether.bridge=1</programlisting>
|
||||
|
||||
<para>to <filename>/etc/sysctl.conf</filename> to enable the bridge at
|
||||
runtime. If you want the bridged packets to be filtered by ipfw, you
|
||||
should also add</para>
|
||||
|
||||
<programlisting>net.link.ether.bridge_ipfw=1</programlisting>
|
||||
|
||||
<para>as well.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Performance</title>
|
||||
|
||||
<para>My bridge/firewall is a Pentium 90 with one 3Com 3C900B and one
|
||||
3C905B. The protected side of the network runs at 10mbps half duplex
|
||||
and the connection between the bridge and my router (a Cisco 675) runs
|
||||
at 100mbps full duplex. With no filtering enabled, I've found that
|
||||
the bridge adds about 0.4 milliseconds of latency to pings from the
|
||||
protected 10mbps network to the Cisco 675.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Other information</title>
|
||||
|
||||
<para>If you want to be able to telnet into the bridge from the network,
|
||||
it is OK to assign one of the network cards an IP address. The
|
||||
consensus is that assigning both cards an address is a bad
|
||||
idea.</para>
|
||||
|
||||
<para>If you have multiple bridges on your network, there cannot be more
|
||||
than one path between any two workstations. Technically, this means
|
||||
that there is no support for spanning tree link management.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="nfs">
|
||||
<title>NFS</title>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue