The translation is temporarily closed for contributions due to maintenance, please come back later.


(itstool) path: sect2/indexterm
<primary>multicast routing</primary>
Context English Spanish State
<prompt>%</prompt> <userinput>netstat -nr</userinput>
Routing tables

Destination Gateway Flags Refs Use Netif Expire
default UGS 0 49378 xl0 UH 0 6 lo0 link#1 UC 0 0 xl0 link#2 UC 0 0 xl1
With the current routing table, <systemitem>RouterA</systemitem> does not have a route to the <systemitem class="ipaddress"></systemitem> network. The following command adds the <literal>Internal Net 2</literal> network to <systemitem>RouterA</systemitem>'s routing table using <systemitem class="ipaddress"></systemitem> as the next hop:
<prompt>#</prompt> <userinput>route add -net</userinput>
Now, <systemitem>RouterA</systemitem> can reach any host on the <systemitem class="ipaddress"></systemitem> network. However, the routing information will not persist if the FreeBSD system reboots. If a static route needs to be persistent, add it to <filename>/etc/rc.conf</filename>:
# Add Internal Net 2 as a persistent static route
The <literal>static_routes</literal> configuration variable is a list of strings separated by a space, where each string references a route name. The variable <literal>route_<replaceable>internalnet2</replaceable></literal> contains the static route for that route name.
Using more than one string in <literal>static_routes</literal> creates multiple static routes. The following shows an example of adding static routes for the <systemitem class="ipaddress"></systemitem> and <systemitem class="ipaddress"></systemitem> networks:
static_routes="net1 net2"
When an address space is assigned to a network, the service provider configures their routing tables so that all traffic for the network will be sent to the link for the site. But how do external sites know to send their packets to the network's <acronym>ISP</acronym>?
There is a system that keeps track of all assigned address spaces and defines their point of connection to the Internet backbone, or the main trunk lines that carry Internet traffic across the country and around the world. Each backbone machine has a copy of a master set of tables, which direct traffic for a particular network to a specific backbone carrier, and from there down the chain of service providers until it reaches a particular network.
It is the task of the service provider to advertise to the backbone sites that they are the point of connection, and thus the path inward, for a site. This is known as route propagation.
Sometimes, there is a problem with route propagation and some sites are unable to connect. Perhaps the most useful command for trying to figure out where routing is breaking down is <command>traceroute</command>. It is useful when <command>ping</command> fails.
When using <command>traceroute</command>, include the address of the remote host to connect to. The output will show the gateway hosts along the path of the attempt, eventually either reaching the target host, or terminating because of a lack of connection. For more information, refer to <citerefentry><refentrytitle>traceroute</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
Multicast Considerations
<primary>multicast routing</primary>
<primary>kernel options</primary> <secondary>MROUTING</secondary>
FreeBSD natively supports both multicast applications and multicast routing. Multicast applications do not require any special configuration in order to run on FreeBSD. Support for multicast routing requires that the following option be compiled into a custom kernel:
options MROUTING
The multicast routing daemon, <application>mrouted</application> can be installed using the <package>net/mrouted</package> package or port. This daemon implements the <acronym>DVMRP</acronym> multicast routing protocol and is configured by editing <filename>/usr/local/etc/mrouted.conf</filename> in order to set up the tunnels and <acronym>DVMRP</acronym>. The installation of <application>mrouted</application> also installs <application>map-mbone</application> and <application>mrinfo</application>, as well as their associated man pages. Refer to these for configuration examples.
<acronym>DVMRP</acronym> has largely been replaced by the <acronym>PIM</acronym> protocol in many multicast installations. Refer to <citerefentry><refentrytitle>pim</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.
Wireless Networking
<personname> <othername>Loader</othername> </personname>
<personname> <firstname>Marc</firstname> <surname>Fonvieille</surname> </personname>
<primary>wireless networking</primary>
<primary>802.11</primary> <see>wireless networking</see>
Wireless Networking Basics
Most wireless networks are based on the <trademark class="registered">IEEE</trademark> 802.11 standards. A basic wireless network consists of multiple stations communicating with radios that broadcast in either the 2.4GHz or 5GHz band, though this varies according to the locale and is also changing to enable communication in the 2.3GHz and 4.9GHz ranges.
802.11 networks are organized in two ways. In <emphasis>infrastructure mode</emphasis>, one station acts as a master with all the other stations associating to it, the network is known as a <acronym>BSS</acronym>, and the master station is termed an access point (<acronym>AP</acronym>). In a <acronym>BSS</acronym>, all communication passes through the <acronym>AP</acronym>; even when one station wants to communicate with another wireless station, messages must go through the <acronym>AP</acronym>. In the second form of network, there is no master and stations communicate directly. This form of network is termed an <acronym>IBSS</acronym> and is commonly known as an <emphasis>ad-hoc network</emphasis>.
802.11 networks were first deployed in the 2.4GHz band using protocols defined by the <trademark class="registered">IEEE</trademark> 802.11 and 802.11b standard. These specifications include the operating frequencies and the <acronym>MAC</acronym> layer characteristics, including framing and transmission rates, as communication can occur at various rates. Later, the 802.11a standard defined operation in the 5GHz band, including different signaling mechanisms and higher transmission rates. Still later, the 802.11g standard defined the use of 802.11a signaling and transmission mechanisms in the 2.4GHz band in such a way as to be backwards compatible with 802.11b networks.
Separate from the underlying transmission techniques, 802.11 networks have a variety of security mechanisms. The original 802.11 specifications defined a simple security protocol called <acronym>WEP</acronym>. This protocol uses a fixed pre-shared key and the RC4 cryptographic cipher to encode data transmitted on a network. Stations must all agree on the fixed key in order to communicate. This scheme was shown to be easily broken and is now rarely used except to discourage transient users from joining networks. Current security practice is given by the <trademark class="registered">IEEE</trademark> 802.11i specification that defines new cryptographic ciphers and an additional protocol to authenticate stations to an access point and exchange keys for data communication. Cryptographic keys are periodically refreshed and there are mechanisms for detecting and countering intrusion attempts. Another security protocol specification commonly used in wireless networks is termed <acronym>WPA</acronym>, which was a precursor to 802.11i. <acronym>WPA</acronym> specifies a subset of the requirements found in 802.11i and is designed for implementation on legacy hardware. Specifically, <acronym>WPA</acronym> requires only the <acronym>TKIP</acronym> cipher that is derived from the original <acronym>WEP</acronym> cipher. 802.11i permits use of <acronym>TKIP</acronym> but also requires support for a stronger cipher, AES-CCM, for encrypting data. The <acronym>AES</acronym> cipher was not required in <acronym>WPA</acronym> because it was deemed too computationally costly to be implemented on legacy hardware.


User avatar None

New source string

FreeBSD Doc / books_handbookSpanish

New source string a year ago
Browse all component changes


English Spanish
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect2/indexterm
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/es_ES/handbook.po, string 10589