This example netstat(1) output illustrates several aspects of routing:

The first two lines specify the default route, described in more detail in Section 31.2.2, “Default Routes”, and the localhost route.

The interface (Netif column) that this routing table specifies to use for localhost is lo0, also known as the loopback device. This says to keep all traffic for this destination internal, rather than sending it out over the network.

The addresses beginning with 0:e0: are Ethernet hardware addresses, also known as MAC addresses. FreeBSD will automatically identify any hosts, test0 in the example, on the local Ethernet and add a route for that host over the Ethernet interface, ed0. This type of route has a timeout, seen in the Expire column, which is used if the host does not respond in a specific amount of time. When this happens, the route to this host will be automatically deleted. These hosts are identified using the Routing Information Protocol (RIP), which calculates routes to local hosts based upon a shortest path determination.

FreeBSD will add subnet routes for the local subnet. 10.20.30.255 is the broadcast address for the subnet 10.20.30 and example.com is the domain name associated with that subnet. The designation link#1 refers to the first Ethernet card in the machine.

Local network hosts and local subnets have their routes automatically configured by a daemon called routed(8). If it is not running, only routes which are statically defined by the administrator will exist.

The host1 line refers to the host by its Ethernet address. Since it is the sending host, FreeBSD knows to use the loopback interface (lo0) rather than the Ethernet interface.

The two host2 lines represent aliases which were created using ifconfig(8). The => symbol after the lo0 interface says that an alias has been set in addition to the loopback address. Such routes only show up on the host that supports the alias; all other hosts on the local network will have a link#1 line for such routes.

The final line (destination subnet 224) deals with multicasting.

Finally, various attributes of each route can be seen in the Flags column. Below is a short table of some of these flags and their meanings:

When the local system needs to make a connection to a remote host, it checks the routing table to determine if a known path exists. If the remote host falls into a subnet that it knows how to reach, the system checks to see if it can connect using that interface.

If all known paths fail, the system has one last option: the “default” route. This route is a special type of gateway route (usually the only one present in the system), and is always marked with a c in the flags field. For hosts on a local area network, this gateway is set to the system which has a direct connection to the Internet.

The default route for a machine which itself is functioning as the gateway to the outside world, will be the gateway machine at the Internet Service Provider (ISP).

This example is a common configuration for a default route:

The hosts Local1 and Local2 are on the local network. Local1 is connected to an ISP using a PPP connection. This PPP server is connected through a local area network to another gateway computer through an external interface to the ISP.

The default routes for each machine will be:

A common question is “Why is T1-GW configured as the default gateway for Local1, rather than the ISP server it is connected to?”.

Since the PPP interface is using an address on the ISP's local network for the local side of the connection, routes for any other machines on the ISP's local network will be automatically generated. The system already knows how to reach the T1-GW machine, so there is no need for the intermediate step of sending traffic to the ISP's server.

It is common to use the address X.X.X.1 as the gateway address for the local network. So, if the local class C address space is 10.20.30 and the ISP is using 10.9.9, the default routes would be:

The default route can be easily defined in /etc/rc.conf. In this example, on Local2, add the following line to /etc/rc.conf:

It is also possible to add the route directly using route(8):

For more information on manual manipulation of network routing tables, refer to route(8).

A a dual-homed system is a host which resides on two different networks.

The dual-homed machine might have two Ethernet cards, each having an address on a separate subnet. Alternately, the machine can have one Ethernet card and uses ifconfig(8) aliasing. The former is used if two physically separate Ethernet networks are in use and the latter if there is one physical network segment, but two logically separate subnets.

Either way, routing tables are set up so that each subnet knows that this machine is the defined gateway (inbound route) to the other subnet. This configuration, with the machine acting as a router between the two subnets, is often used to implement packet filtering or firewall security in either or both directions.

For this machine to forward packets between the two interfaces, FreeBSD must be configured as a router, as demonstrated in the next section.

A network router is a system that forwards packets from one interface to another. Internet standards and good engineering practice prevent the FreeBSD Project from enabling this by default in FreeBSD. This feature can be enabled by changing the following variable to YES in rc.conf(5):

This option will set the sysctl(8) variable net.inet.ip.forwarding to 1. To stop routing, reset this to 0.

The new router will need routes to know where to send the traffic. If the network is simple enough, static routes can be used. FreeBSD comes with the standard BSD routing daemon routed(8), which speaks RIP versions 1 and 2, and IRDP. Support for BGPv4, OSPFv2, and other sophisticated routing protocols is available with the net/zebra package or port.

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 ISP?

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 your 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 routing propagation and some sites are unable to connect. Perhaps the most useful command for trying to figure out where routing is breaking down is traceroute(8). It is useful when ping(8) fails.

When using traceroute(8), include the name 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 traceroute(8).

FreeBSD natively supports both multicast applications and multicast routing. Multicast applications do not require any special configuration of FreeBSD; as applications will generally run out of the box. Multicast routing requires that support be compiled into a custom kernel:

The multicast routing daemon, mrouted(8), must be configured to set up tunnels and DVMRP via /etc/mrouted.conf. More details on multicast configuration may be found in mrouted(8).