In Bridging section:
- Use of hostid tags and manual page entities where needed - s/IP Masquerading (NAT)/network address translation (NAT)/ which is more consistent with all our docs and the applications names - Some tags fixes - IPFIREWALL_DEFAULT_TO_ACCEPT is not anymore an undocumented option, so fix a comment In ISDN section: - expand "sync/TA" --> synchronous card/TA - s/I/We - s/page/section/ - Some punctuation and case fixes - Remove an useless ironic comment about Windows 95 in the ascii art version of a diagram.
This commit is contained in:
parent
fbea94ab71
commit
8c6ab39821
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=19321
1 changed files with 15 additions and 15 deletions
|
@ -1549,8 +1549,8 @@ rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
|
|||
|
||||
<para>Let us 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,
|
||||
users all use server <hostid>A</hostid> for file service, and the Production users
|
||||
are on server <hostid>B</hostid>. An Ethernet network 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
|
||||
|
@ -1565,10 +1565,10 @@ rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
|
|||
<sect3>
|
||||
<title>Filtering/Traffic Shaping Firewall</title>
|
||||
<indexterm><primary>firewall</primary></indexterm>
|
||||
<indexterm><primary>IP Masquerading</primary></indexterm>
|
||||
<indexterm><primary>network address translation</primary></indexterm>
|
||||
|
||||
<para>The second common situation is where firewall functionality is
|
||||
needed without IP Masquerading (NAT).</para>
|
||||
needed without network address translation (NAT).</para>
|
||||
|
||||
<para>An example is a small company that is connected via DSL
|
||||
or ISDN to their ISP. They have a 13 globally-accessible IP
|
||||
|
@ -1618,12 +1618,12 @@ rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
|
|||
<title>Firewall Support</title>
|
||||
<indexterm><primary>firewall</primary></indexterm>
|
||||
<para>If you are planning to use the bridge as a firewall, you
|
||||
will need to add the <varname>IPFIREWALL</varname> option as
|
||||
will need to add the <literal>IPFIREWALL</literal> 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
|
||||
through the bridge, there is a 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.
|
||||
|
@ -1667,8 +1667,8 @@ rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
|
|||
<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
|
||||
<para>If you want to be able to &man.telnet.1; into the bridge from the network,
|
||||
it is correct to assign one of the network cards an IP address. The
|
||||
consensus is that assigning both cards an address is a bad
|
||||
idea.</para>
|
||||
|
||||
|
@ -1676,7 +1676,7 @@ rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
|
|||
than one path between any two workstations. Technically, this means
|
||||
that there is no support for spanning tree link management.</para>
|
||||
|
||||
<para>A bridge can add latency to your ping times, especially for
|
||||
<para>A bridge can add latency to your &man.ping.8; times, especially for
|
||||
traffic from one segment to another.</para>
|
||||
|
||||
</sect2>
|
||||
|
@ -2930,9 +2930,9 @@ Exports list on foobar:
|
|||
router, and with a simple 386 FreeBSD box driving it, probably more
|
||||
flexible.</para>
|
||||
|
||||
<para>The choice of sync/TA v.s. stand-alone router is largely a
|
||||
<para>The choice of synchronous card/TA v.s. stand-alone router is largely a
|
||||
religious issue. There has been some discussion of this in
|
||||
the mailing lists. I suggest you search the <ulink
|
||||
the mailing lists. We suggest you search the <ulink
|
||||
url="../../../../search/index.html">archives</ulink> for
|
||||
the complete discussion.</para>
|
||||
</sect2>
|
||||
|
@ -2946,9 +2946,9 @@ Exports list on foobar:
|
|||
<para>ISDN bridges or routers are not at all specific to FreeBSD
|
||||
or any other operating system. For a more complete
|
||||
description of routing and bridging technology, please refer
|
||||
to a Networking reference book.</para>
|
||||
to a networking reference book.</para>
|
||||
|
||||
<para>In the context of this page, the terms router and bridge will
|
||||
<para>In the context of this section, the terms router and bridge will
|
||||
be used interchangeably.</para>
|
||||
|
||||
<para>As the cost of low end ISDN routers/bridges comes down, it
|
||||
|
@ -2976,7 +2976,7 @@ Exports list on foobar:
|
|||
|
||||
<para>For example to connect a home computer or branch office
|
||||
network to a head office network the following setup could be
|
||||
used.</para>
|
||||
used:</para>
|
||||
|
||||
<example>
|
||||
<title>Branch Office or Home Network</title>
|
||||
|
@ -2996,7 +2996,7 @@ Exports list on foobar:
|
|||
|
|
||||
---FreeBSD box
|
||||
|
|
||||
---Windows 95 (Do not admit to owning it)
|
||||
---Windows 95
|
||||
|
|
||||
Stand-alone router
|
||||
|
|
||||
|
|
Loading…
Reference in a new issue