Routing network traffic

Basic routing
Using routing tables
Interpreting routing tables

When traffic is going to be sent out, then routing tables are used.

Destination
In Unix and Microsoft Windows, and perhaps other implementations, the first column typically shown is the “Destination”. This refers to the destination specified by the IP packet. If the IP packet's specified destination matches the “Destination” address or subnet specified by the routing table, then that route could be used unless another route has a higher priority.
Priority

Routes with smaller subnets typically have a higher priority than routes with a larger subnet.

The priority of a route is also known as the route's “Metric”. Microsoft Windows may have a column called Metric. Unix may call this a Prio. These sort of values may be used to favor one route over another, particularly if there is a tie.

Gateway column

The “Gateway” indicates where the traffic is sent to. The IP packet is going to be encapsulated into a Layer 2 “frame”, which will have a “physical” network (MAC) address. If the “Gateway” column in the routing table shows a MAC address (which may happen in Unix, and perhaps not in Microsoft Windows), then that MAC address will be used as the destination of the frame. Otherwise, an ARP lookup will determine what MAC address the frame will be sent to. If the value of the Gateway column in the routing table shows an IP address, then the ARP request will look for a MAC associated with the IP address specified by the Gateway column in the routing table. This will be required for traffic which needs to be routed because of a destination IP address which is not part of a subnet being used by the NIC. On the other hand, the value of the “Gateway” column might not be a physical/MAC address, nor an IP address. Instead, the value fo the “Gateway” column might contain the word link (e.g. “On-link” in Microsoft Windows, or something like link#2 in Unix). In that case, the ARP request will look for the physical/MAC address that is related to the IP address that is specified by the IP packet.

Interface column

The Interface (as it is called in Microsoft Windows: Unix may abbrevate that as Iface) indicates the NIC that the traffic will be going out. In Unix, this may be a NIC's name. In Microsoft Windows, this may appear as an IP address. In that case, the NIC being used will be whatever NIC uses the IP address shown in the Interface column. Also in that case, the “source” physical/MAC address for the outgoing frame will probably(/certainly?) use the MAC address that matches the IP address in the ARP tables.

[#viewrout]: Viewing routing tables
Unix and Microsoft Windows

Routing tables may be viewed viewable with “ netstat -nr

Additionally, routing tables may be seen using the route command. In Microsoft Windows, using “ route print ” will work. That will probably not work in Unix, but “ route show ” should work. Both of these commands prints output that is very similar, if not identical, to what is shown by running “ netstat -nr ”.

[#ciosshrt]: Cisco IOS command to view routing tables

Note: There is quite a bit more to working with a professional-level Cisco device than just knowing the command line. Some introductory material to using such devices can be found from: introduction to using Cisco devices, using Cisco equipment, and Cisco IOS basic usage guide.

To see routes on a Cisco IOS device, here is a command that may be typed at the command line.

routerName>show ip route

For some more commands that are useful to get the status on a Cisco device, see: Cisco show commands (approximately Pre-CCNA/CCNA level).

[#noneedgw]: Routing for local subnets

When a NIC has an IP address, and a (CIDR) prefix length (or, for IPv4, a subnet mask, which is generally convertable into a CIDR prefix length), then a computer can determine the defined subnet that the IP is a part of. Generally, each network devices will assign a route (which is usually an explicitly reported route, but the route might be implicit on some network devices) for every subnet that contains an IP address that is used by one of the network device's network interfaces. The route for each such subnet simply indicates that the traffic should go out the network interface that has the IP address on that route.

With this sort of simple, standard routing, it is not common to have multiple network interfaces using the same subnet on a single device. The simple reason for that is that this could cause multiple routes for the same subnet. Any variation, such as bridging (which may commonly have multiple NICs using the same subnet), is more elaborate and so is not a case of this type of simple, standard networking.

Traffic which does not go out to a local subnet will generally not be able to be delivered unless a suitable route is added. Generally, traffic that goes to a device that is not on the local subnet will get “routed” to a “gateway” address. A “default gateway” is a gateway that is typically used whenever there isn't another usable gateway (from a more specific route).

[#addnetrt]: Adding a networking route
NIC-based routes

As a general rule, routes are typically automatically created based on a NIC's network configuration settings. The network interface card/device will need to have a configured IP address for this to happen, and there might be some additional requirement(s) such as the card being marked as “up” (in Unix), which may have some additional requirements like the card being enabled and the “media state” showing a physical connection. Perhaps there is even more requirements, like an IPv6 address not being in the “transitional” state that happens before the DAD (“duplicate address detection”) process is completed. In short: the card needs to be operational.

As a general rule, the network stack will typically check for any IP address, figure out the related “network prefix” (or equivilent, such as an IPv4 subnet mask), and add a route for all traffic in that subnet. The destination for that route will be a name/identifier for the specific NIC. This ends up causing the network stack to send an Ethernet frame to the MAC address shown in the NDP table (for IPv6 or the MAC address shown in the ARP table (for IPv4).

(Traffic sent to destinations outside of the route will be processed as normal, which might include sending an IP packet to the default gateway so that the traffic may be routed appropriately.)

As a result of this process, the computer will generally know how to “route” traffic that does not need to be routed to remote subnets.

A very noteworthy exception to this process is IPv6 link-local addresses. Each functioning NIC will have (at least) one IPv6 link-local address. Very often, a computer will have the same subnet (usually fe80::/64) be assigned to each and every NIC. As a result of this behavior, the computer might not have a super easy time using only the routing table to determine which NIC is used to connect to a remote fe80::/64 address. This is why the ping command may have a command line parameter to specify the NIC (“-I” in KAME's ping6, -S for “ping -6” in Microsoft Windows).

Manually adding a networking route
Special syntax notes for adding a default gateway

Some operating systems have a special syntax that can be used when a “default gateway” is being specified. This syntax might be slightly simpler, such as using the word “default”, which may make the process a bit less error-prone (perhaps especially if somebody with less expertise is being asked to type things based on audio directions).

In general, any such special syntax may be just one option. Another option to add a default gateway is simply to specify the network size of /0 when adding a network route manually. For instance, with IPv4, this would be done by specifying a network address of “0.0.0.0” and a subnet mask that looks identical, “0.0.0.0”. So the more generalized syntax is an option.

Unix and Microsoft Windows

Permissions must be granted: In Unix, the command may need to be elevated. (If needed, see the section on running a command as a superuser.)

Microsoft Windows and Unix can both use the following command:

route add default 192.0.2.1

This generally specifies a subnet with a prefix length of zero. (Since the prefix length is zero, no IP address would be necessary to identify which specific subnet is being referred to.)

It would also be possible to use syntax that isn't specific to the default gateway, but specifying a network instead of using the term “default”.

Cisco IOS

For routers: no such details are provided here, and there might be no such syntax that is even available. Simply use the general syntax that works with any size route.

For switches, the following may work:

deviceName(config)#ip default gateway 192.0.2.1

... or ...

deviceName(config)#ip default-gateway 192.0.2.1

(The difference between those examples is the hyphenated “default-gateway” rather than the multi-word “default-gateway”.)

(The command(s) for switches have also been documented by the section about using VLANs with Cisco IOS.)

Manually adding a route (which may be a route other than a default gateway)
Adding an IPv6 route

This is done with the route command. In Windows Vista, running route/? shows an example for IPv6. Lowercasing the parameters (to be similar to Unix), the shown example is:

route add 3ffe::/32 3ffe::1

(This sort of example is using addresses within the range of 3ffe::/16, which should no longer be used (according to RFC 3701: “6bone (IPv6 Testing Address Allocation) Phaseout”. A better example would be the 2001:db8::/32 subnet, which is meant for documentation/examples, but also should not be literally used.)

The address at the end is the gateway that the specified traffic will be routed to.

In Unix, if that same syntax doesn't work, try a variation such as:

route add -inet6 2001:db8:: -prefixlen 32 2001:db8::1

In Microsoft Windows, the just-provided documentation shows one way to add a route. Another option may be to use:

(At the time of this writing, the following has not been recently tested by the author of this text. Hopefully it'll work well.)
netsh interface ipv6 add route prefix=2001:db8::/32 "1" 2001:db8::1

In this example, the part between the quotation marks is the index (number) or name of a NIC. (For more details, see the section about available NICs.) (If running “ netsh interface ipv6 add route /? ” on Windows Vista, the example interface name (surrounded by quotation marks) provided is "Internet".)

Adding an IPv4 route

Like many things, the way to do this with IPv4 (on a modern system) may often be similar to how it is done with IPv6. Naturally, a reference to an IPv4 network/address will be used instead of an IPv6 address.

Unix

In Unix, using IPv4 is similar, with a reference to “ -inet ” instead of “ -inet6 ”. Actually, just specifying neither “ -inet ” nor “ -inet6 ” may result in a default of “ -inet ” being assumed, so try just leaving off the “ -inet ” if it causes problems. However, if a machine does support specifying “ -inet ” then it may be better to specify that, as a general practice, in case future operating systems ever break compability by changing the default.

route add -inet 192.0.2.0/24 203.0.113.1
route add 198.51.100.0 -netmask 255.255.255.0 203.0.113.1
Adding an IPv4 route in Microsoft Windows

In Microsoft Windows, there is another syntax used with IPv4 addresses. It looks like this:

route add 192.0.2.0 MASK 255.255.255.0 192.0.2.1

References for Microsoft Windows: KB 262397: How to Configure a Default Gateway for Multihomed Computer with LAN and Internet Access (for Win95/98) (is for IPv4, which is unsurprising since Win95/98 don't come with built-in support for IPv6).

Adding a (default) route in Cisco IOS

Note: There is quite a bit more to working with a professional-level Cisco device than just knowing the command line. This is actually discussed further even within this section on routing. For more references to further details about working with Cisco devices, see: Cisco IOS command to view routing tables.

In the following example, some pieces of the command should be customized. Those pieces are the network, the prefix length, and the “gateway” (next hop to the destination). Gateway may be a network interface or address. e.g.:

routerName>en
routerName#conf t
routerName(config)#ip route 198.51.100.0 255.255.255.0 Fa0/1

or

routerName>en
routerName#conf t
routerName(config)#ip route 198.51.100.0 255.255.255.0 192.0.2.1

or, slightly more complex:

routerName>en
routerName#conf t
routerName(config)#ip route 198.51.100.0 255.255.255.0 192.0.2.1 optionalAdministrativeDistance

e.g.:

routerName>en
routerName#conf t
routerName(config)#ip route 198.51.100.0 255.255.255.0 192.0.2.1 150
Automatically adding additional routes
Using automatic addressing

Technologies involving automatic network address assignment will often provide at least one detail about routing, which is an automatic gateway to use. (More advanced routing is generally not implemented in standard/common/popular implementations of automatic addressing, but will instead use a routing protocol.)

[#netrtptc]: Using a routing protocol

There are some protocols which are commonly referred to as “routing protocols”.

Other techniques/protocols, like firewall redudancy protocols, or load balancing, might also involve making an adjustment to routes. However, those may be even more advanced topics with goals beyond just having devices communicate about a route that exists.

Routing Information Protocol (“RIP”)
Versions of RIP
Versions of RIP for IPv4
RIP(v1)

RFC 1058

RIPv1 does not distribute a prefix length. Therefore, devices need to guess what prefix length to use.

The intended way to determine the prefix length (also known as the “subnet size”, or “subnet mask”) was to use a default prefix length for the IPv4 class. However, that made less sense as the Internet got larger and CIDR started to be used. Some devices try to use some other technique, like considering the prefix length of the network interface that received the route, to determine a better guess of an appropriate subnet size.

RIPv2

IETF STD 56 RFC 2453

(updated by RFC 4822)

(Perhaps IETF 1723 1388, although they might have been meant as an add-on to RIPv1's RFC 1058?)

RIPv2 added support for VLSM/CIDR.

RIPv2 uses IPv4 multicast address 224.0.0.9 (as reserved by IANA IPv4 Multicast Address Assignments), where RIPv1 used IPv4 broadcast. This may reduce work for some network equipment that simply ignores this multicast traffic.

RIPv2 added some support for authentication (RFC 2453 section 4.1 and RFC 2453 section 5.2). Although the RIPv2 RFC 2453 refers to RFC 2082 for further details on authentication, RFC 2082 has been marked as obsolete by RFC 4822: RIPv2 Cryptographic Authentication. (Still, even if MD5 is not considered to be crytographically secure against skilled attackers, using some sort of authentication might introduce some barriers against some potential problems. For instance, if routers check that RIP updates come from a device that is using a proper authentication password, this could enable authorized routers to reject updates from a device that accidentally started RIP but which did not have the passwords configured.)

for IPv6 (a.k.a. which was previously better known as “IPng”)
RIPng
RFC 2080: RIPng for IPv6 states, “This document is a modified version of RFC 1058”... “The modifications reflect RIP-2 and IPv6 enhancements”.
Limits/Problems

RIP defines a hop count of 16 (or perhaps anything greater than 15) as “infinity”, which indicates that a route should be deleted. (This limits RIP's scalability. Rather than giving the number zero, or -1, a special value, the special value was assigned to 16. RFC 1058: RIP, section 1.1: “Limitations of the protocol” states, “The designers believe that the basic protocol design is inappropriate for larger networks.” RFC 1058: RIP, page 14 notes, “The designers of RIP believed that the protocol was unlikely to be practical for networks with a diameter larger than 15.”)

RIPv1 does not distribute a prefix length. Devices may guess what a prefix length is, by considering the prefix length of the network interface that received the route, or perhaps by using a default prefix length for the IPv4 class.

Overview
Technique/Classification
Distance Vector
Updates

Information is sent after an interval of 30 seconds plus the “addition of a small random time” designed to avoid all routers updating simultaneously. (The quote came from RFC 3.3 (RIPv1) section 3.3: “Timers”.)

RIP implementations
Cisco IOS's RIP

Note: the ifnormation in this section is meant for people using Cisco IOS, and most or all of these details will likely not be applicable for people who are trying to use other operating systems. For further discussion, see the standard Cisco IOS warning.

Cisco IOS's RIP for IPv4
routerName>en
routerName#conf t
routerName(config)#router rip
Setting the version of RIP for IPv4 (in IOS)

The default may, tragically (but, for maximum compatability, understandably), be to send out information using version 1. For IPv4 usage, using RIPv2 is generally a much preferred option, for the sole reason of sensibly supporting the transmission of prefix lengths. Enable the ability to use RIPv2:

routerName(config-router)#version 2

(The default may actually be to listen for traffic that is RIPv1 and also RIPv2 traffic. This can be changed per interface, and the current settings may be seen with “ sh ip protocols ”. However, setting the version is needed to enable the ability to not summarize routes at class boundaries, and/or to enable authenticated updates.)

Add support for sensible VLSM/CIDR info to be transmitted.

routerName(config-router)#no auto-summary

(This option requires not using RIPv1. Without this option, the provided subnets will be converted into a full-sized /8 Class A, /16 Class B, or /24 Class C network.

If RIP updates are supposed to be using one network interface, but not another network interface, a network interface may be marked as “passive”. (This would be done to the network interface which should not use routing updates.) e.g.:

routerName(config-router)#passive-interface Serial 0/0/0

Add one or more networks to transmit information about.

routerName(config-router)#network networkIDIPv4address

e.g.:

routerName(config-router)#network 192.0.2.0

To also share static routes: “redistribute static”. (Perhaps as follows?)

routerName(config-router)#redistribute static

The following may also be helpful to distribute a default gateway:

routerName(config-router)#default-information originate
Authentication (of RIP for IPv4 in IOS)

To use MD5 authentication, go into the configuration for each interface where the authentication is desired, and specify:

routerName(config-router)#ip rip authentication mode md5

Note that MD5 authentication is not considered to be strong against attackers. However, MD5 might be supported by a wider range of older equipment. Even if MD5 is not suitable to offer much prevention from a malicious attack, using authentication might help to prevent some routes from being accidentally spread by a device which hasn't been configured with a sufficient password.

The router should be able to determine the prefix lengths based on information stored elsewhere in the router configuration.

Routes should then show up (see: viewing routing tables). Another command to get some info is “ show ip protocols ”. Another is “ debug ip rip ”, which may cause the router to start showing messages related to RIP. Using such debug commands may reduce performance (speed) of the router's operations, or even stability of the router (likely meaning that the router crashes, becoming inoperable until after power is temporarily removed from the router.)

RIPv6 in Cisco IOS

Note: the ifnormation in this section is meant for people using Cisco IOS, and most or all of these details will likely not be applicable for people who are trying to use other operating systems. For further discussion, see the standard Cisco IOS warning.

At the moment, these directions may be partial. (Further details may be needed for this section to really feel complete.)

Make sure to also traffic forwarding in Cisco IOS is enabled. (It is presumed that this is desirable.)

This is enabled on a paritcular interface. Also, the RIPv6 process will need to be named, so come up with a name.

deviceName(config)# interface fa0/1
deviceName(config-if)# ipv6 rip ripPIDName enable

Note: when configuring, do not try to share networks with the network commands. Share networks with interface commands.

Note: This is all of the information provided by this guide at this time. For more extensive information, consider reviewing additional information that may be online, or check out the equivilent protocol that is designed for IPv4, because presumably some similarities may be likely.

The status of this protocol being running can be seen with:

show ipv6 protocol
Open Shortest Path First (“OSPF”)
Versions
Initial OSPF
Information about the original OSPF standard

IETF record of RFC 1131 looks very unsatisfying: this RFC was not initially released as pure plain text, but rather just as a PostScript file. See RFC-Editor information on RFC 1131 for hyperlinks to the PostScript file, or PDF conversions. (pages 6 and 23 and 56 have some images, and pages 8, 9, 13, 15, and 27 have some more elaborate images that might take some work to try to make ASCII art equivilent).

Yeah, yeah, yeah: it is widely believed that RFC documents should be written in ASCII text, using ASCII art as needed. (See: RFC rules.) Well, RFC 2223bis version 8, page 9 states, “A very few exceptions have been made over the 30 year history of RFCs, allowing a definitive PostScript (.ps) version with no .txt version.” This standard happens to be one of those. Presumably this was allowed more in the past.

OSPFv2

IETF STD 54 (RFC 2328)

updated by 6845 and 6860 (which is also considered as updates for OSPF version 3), and 5709 and 6549

The RFC (2328) document simply titles itself “OSPF Version 2” and its abtract refers to the “version 2 of the OSPF protocol”. Other RFCs do refer to it as OSPFv2.

OSPF version 3
IPv6 RFC 5340, updated by RFC 6845 and RFC 6860, replaced older RFC 2740.
Overview
Technique/Classification

This is a “link-state” algorithm. This link-state algorithm sends a “link-state advertisement” (“LSA”) and the “Dijkstra algorithm”.

(RFC 2328 refers to this as the Dijkstra algorithm. Some people also refer to this as the “Shortest Path First” (“SPF”) algorithm. The algorithm is named after Edsger Wybe Dijkstra. The Dutch last name is generally pronounced with a hard I and a silent J: like Dyke-stra. Wikipedia's page for Dijkstra's algorithm. Wikipedia's page on Edsger Dijkstra.)

The protocol also stores information about the network topology which is provided by the link-state advertisement packets.

Router roles
Some networks do not bother with these roles

Some networks do not bother with these roles. As a simple summary that will address this for many people, networks using Ethernet do.

However, in order to be a technically accurate resource, some further discussion is warranted, in order to be a bit more complete.

From reading some Cisco documentation, these roles are typically implemented on Ethernet networks, which support broadcast communications. Other types of networks might not bother with assigning these roles, including point-to-point types of connections or non-broadcast networks like an “Asynchronous Transfer Mode” (“ATM”) connection. (Note that an IPv4 /24 over Ethernet would use these roles, even if there are only two routers connected, because the style of connection is Ethernet which is a broadcast-type connection. Presumably this might also be true with a /30, just because the physical port represents a type of connection that could have multiple routers. Using a serial port on a Cisco router, which is a physical technology that is generally treated as being exclusively point-to-point, may just avoid these roles.)

The RFC (2328) might not be quite as clear. It does state (in the sentence just before RFC 2328 page 11), “Each broadcast and NBMA network that has at least two attached routers has a Designated Router.” (RFC 2328 section 7.3, on RFC 2328 page 54, states “Every broadcast and NBMA network has a Designated Router.”) RFC 2328 page 16 states, “In Point-to-MultiPoint mode, OSPF treats all” router-to-router “connections over the non-broadcast network as if they were point-to-point links. No Designated Router is elected for the network, nor is there an LSA generated for the network.” This seems to imply that point-to-point links do not elect a Designated Router.

The RFC uses an “ATM subnet utilizing SVCs” (that is, an Asyncronous Transfer Mode subnet using switched virtual circuits), and contrasts that type of network layout with “PVC-only Frame Relay networks.” (PVC would be referring to permanent virtual circuits.) From this text, it sounds like classifying ATM or Frame Relay as being either NMBA, or not, may vary a bit based on implementation.

A router participating in OSPF has a role called “designated router” (“DR”), or “backup designated router” (“Backup” according to RFC 2328 page 68 chart, although Cisco has been known to refer to this as “BDR”), or “DROther”.

With OSPF (which is for IPv4; perhaps actually only OSPFv2?), when a link goes down, routers use multi-cast address 224.0.0.6 to send information that is listened to by both the DR and the Backup DR. The DR (and not the backup DR) will then use multicast address 224.0.0.5 to forward details to all other routers (which means the Backup DR and any router with the role of “DROther”).

IANA IPv4 Multicast Addresses reserves 224.0.0.5 for “OSPFIGP OSPFIGP All Routers” (presumably referring to OSPF Interior Gateway Protocol) and references RFC 2328. Similarly, 224.0.0.6 is reserved for “OSPFIGP OSPFIGP Designated Routers”. (So, these descriptions are named after which type of routers will be receiving the traffic.)

Areas

An “area” is a group. Devices within the same OSPF “Autonomous System” (which is an OSPF-specific “Autonomous System”, and not related to the global OSPF “Autonomous System” overseen by IANA) can be grouped into different areas.

From briefly looking through RFC 2328, areas do not appear to be strictly required (based on RFC 2328 page 21 in section 2.2, which starts by referring to, “When no OSPF areas are configured”, and RFC 2328 page 26 referring to “the introduction of areas”.) However, Cisco CCNA Discovery 4.0 Module 3: “Introducting Routing and Switching in the Enterprise”, Slide #6.2.1.1 states, “Even if there are no areas specified, there must be an Area 0.” So, using an area (even if there is only one area used) may be a method of communication that is compatible with more OSPF implementations.

When multiple areas are used, some information about the topology in one area is not transmitted to other areas. This restricts how many details are shared, which can have some advantages including reducing the amount of information that needs to be transmitted.

Cisco documentation has indicated that an area may support up to 50 routers. So, larger networks may need to use multiple OSPF areas (in order to use OSPF).

An area ID is 32-bit number (per RFC 2328 page 220 and RFC 5340 section 2.2), and RFC 2328 page 27 notes “OSPF Area ID's are typically formatted as IP addresses”. (What this is referring to is an IPv4 address's standard “dotted quad” notation.) However, area IDs are also often written in a format other than the dotted-quad format: that same section, as well as RFC 2328 page 241 (near the end of the first paragraph of section G.2), refer to “Area 0”. Cisco documentation has demonstrated just refer to areas as numbers (and has mentioned that such devices might have a limitation that an area ID might not be allowed to be larger than 65,535). However, some exploring with Packet Tracer indicates the area may have a range of 0 to 4,294,967,295 and may be specified in the standard (IPv4-like) “dotted quad” format.

Every OSPF autonomous systems (meaning each instance where OSPF is deployed/used) using areas will have an Area 0, which is sometimes also called the OSPF “backbone”. Other areas may be referred to as “non-backbone areas”. Every non-backbone area must be able to communicate with Area 0. (RFC 2328 page 27 states, “When routing a packet between two non-backbone areas the backbone is used.” Network Engineering @ Stack Exchange question: “Why is area 0 the backbone area in OSPF discusses why area 0 is required.)

When trying to have full information be shared with other routers, have them all be in the same area. Having routers in separate areas may limit how much information is being shared, which is probably not desirable for people who are trying to create their very first small OSPF network, and who therefore are just trying to make everything communicate fully.

RFC 2328 page 28 (in section 3, third paragraph, in parenthesis) states, “Routers connected to multiple areas are called area border routers”. Although that RFC does not abbreviate that term, the term “area border router” may be abbreviated as “ABR”.

Implementations
OSPF in Cisco IOS

Note: the ifnormation in this section is meant for people using Cisco IOS, and most or all of these details will likely not be applicable for people who are trying to use other operating systems. For further discussion, see the standard Cisco IOS warning.

OSPF for IPv4 in Cisco IOS
Getting to “(config-router)” prompt

Select an OSPF process ID, which is a non-zero number that fits within 16 bits (meaning a number from 1 through 65,535). This number does not need to match any number on any other router, but needs to be unique for this router.

routerName>en
routerName#conf t
routerName(config)#router ospf 12345
Sharing routes
Sharing routes of directly connected networks

Specify a network, a wildcard mask, and an Area ID. (To convert from an IPv4 “subnet mask” to a “wildcard mask”, subtract the value of each octet from 255. So, since 255-255=0, and 255-255=0, and 255-255=0, and 255-0=255, a subnet mask of 255.255.255.0 would have an equivilent wildcard mask of 0.0.0.255. Similarly, if a wildcard mask is able to be converted to a valid subnet mask, the way to convert back is to take each octet and subtract from 255. If these masks are being viewed in binary, the equivilent action is simply to flip every single bit. The technical difference between a subnet mask and a wildcard mask is simply that a subnet mask should generally have all of the bits set to one at the start of the mask, and all bits set to zero are at the end of the mask: no zeros appear earlier than any ones. A wildcard mask purposefully does not have a similar limitation.)

routerName(config-router)#network 192.0.2.0 0.0.0.255 area 0

The Area ID may be specified as a number, or as a dotted quad (so that it looks similar to an IPv4 address's typical syntax/notation).

The routes may show up on the routing tables of other Cisco routers as type O (OSPF)

Sharing more routes

Some types of routes, such as a default gateway, may be excluded from OSPF routing (at least by default). To change that, on a system that sends traffic outside of the autonomous system (which is an “ASBR”: Autonomous System Border/Boundary Router), run the following command:

routerName(config-router)#default-information originate

Other routes may then receive the route, which may look like a type E2. (The output of “show ip route” may show as “O*E2”, where “E2” shows up in the code list as “OSPF external type 2”) The route will still look like the same type (“S*”) on the router that originally had the route.

Summarizing routes
routerName(?)#area 0 192.0.2.0 255.255.254.0
Using authentication
Using MD5 authentication

Note that using MD5 is not considered to be secure against attackers. (Similar notes are in the section about RIPv2.)

(This may be done after assigning the networks to share.)

First, enable MD5 in the area.

routerName(config-router)#area 0 authentication message-digest

Then, configure each interface that will be using this MD5 key.

routerName(config)#interface fa0/0

(Assign an IPv4 address and subnet mask, if that has not yet already been done.)

routerName(config-router)#ip ospf message-diget-key keyID md5 password

The keyID may be a number from 1 to 255. (In some examples, it may be the same as the OSPF AS number that is included in the “router ospf” line.) The password may be a maximum of 16 characters. e.g.:

routerName(config-router)#ip ospf message-diget-key 8 md5 $cr4/\/\b|_edPw
Using a key

The key gets transmitted in plain text, which is even easier for an attacker to attack than MD5 authentication.

Adjusting cost
routerName(config-if)#ip ospf cost 1536

For Cisco IOS's OSPF, the default cost is based on bandwidth. To see the (default?) bandwidth of a physical link, “show interfaces Fa0/0” will show a line such as “  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,”. (“show ip protocols” may show some info? (Or perhaps that is just for EIGRP? (This may need to be checked...)) The BW refers to bandwidth, so the number right after that is the bandwidth that the router is assuming based on the hardware type.

Another way may be to use a command to adjust bandwidth. e.g.:

routerName(config-if)#bandwidth 64

That may take a speed (e.g. a reference bandwidth of 100,000,000mbps) and divide by the specified number times a thousand (e.g. 64,000) to get a cost (e.g. 1536.5, which apparently gets truncated down to 1562). Cisco documentation has identified these approaches (adjusting bandwidth or adjusting cost) as having an identical result. (Disc 3 6.2.3.3 says modifying, using either technique, “achieves the same result.”) (One would presume, though, that the OSPF cost would override if both are set? Also, that the bandwidth setting would affect more than just OSPF.)

If a reference bandwidth of 100,000,000bps is too slow, adjust the value as needed, specifying a different number of 1,000,000bps. For instance, 10 gigabits may be used as a reference bandwidth by using a value of 10,000. A command “auto-cost reference-bandwidth” may be helpful. Following is an example for gigabit:

routerName(config)#router ospf 1 routerName(config-router)#auto-cost reference-bandwidth 1000

Note: the auto-cost command did not seem to be supported by an IOS used by Packet Tracer.

Viewing some results
routerName#show ip ospf interface

Shows Process ID, Router ID, Network Type (e.g. “BROADCAST” or “POINT-TO-POINT”), Cost, and State (e.g. “DR”, “BDR”, “DROTHER”, “POINT-TO-POINT”. Specifies which address is the Designated Router (based on the “Router ID” of that router?) and similar for the BDR. Shows timer intervals (indcluding Hellow timer and Dead timer), and some information about the numbers of neighbors and adjacent neighbors.

routerName#show ip ospf neighbor
OSPFv3 for Cisco IOS

Like all other OSPFv3 implementations, this is designed to work with IPv6.

At the moment, these directions may be partial. (Further details may be needed for this section to really feel complete.)

Make sure to also traffic forwarding in Cisco IOS is enabled. (It is presumed that this is desirable.)

This is enabled on a paritcular interface. Also, the OSPFv3 process will need to be numbered, so come up with a process number. (Many examples will use the process number of 1, and there seems to be no real compelling reason not to.)

deviceName(config)# interface fa0/1
deviceName(config-if)# ipv6 ospf 1 area 0

After issuing the above command, the following message may be shown:

%OSPFv3-4-NORTRID: OSPFv3 process # could not pick a router-id

OSPFv3 needs to have a “router ID” that it can use. The “router ID” is 32 bits and can be specified in dotted-quad form. The router will try to automatically figure out an appropriate “router ID” to use by looking for an available IPv4 address. If no IPv4 address has been configured, then a unique address needs to be selected. (Simply make up a valid IPv4 address that won't be used elsewhere.) Then, specify that so the router knows to use that as the OSPFv3 “router ID”.

deviceName(config-if)# router-id 192.0.2.1

Note: when configuring, do not try to share networks with the network commands. Share networks with interface commands.

Note: This is all of the information provided by this guide at this time. For more extensive information, consider reviewing additional information that may be online, or check out the equivilent protocol that is designed for IPv4, because presumably some similarities may be likely.

The status of this protocol being running can be seen with:

show ipv6 protocol
Other OSPF

These surely exist and may become documented here at a later time.

(Other OSPF topics)
(...)
Interior Gateway Routing Protocol (IGRP) (and related)

Proprietary by Cisco

Interior Gateway Routing Protocol (IGRP)

Proprietary by Cisco, and Cisco recommends that it not be used. (Instead, Cisco is more likely to refer to EIGRP.)

Discontinued with IOS 12.2(13)T and 12.2(R1s4)S, so this protocol has no future. (People needing an alternative could consider EIGRP because the commands used for IGRP may be similar to EIGRP. In some cases, the IOS commands may be 100% similar (matching exactly).) Lifespan was 1985 to 2005.

Enhanced Interior Gateway Routing Protocol (“Enhanced IGRP”, “EIGRP”)

Cisco proprietary. First supported in IOS 9.2.1

Limit(s)

Maximum hop count is 224. (Or, rather, the maximum maximum hop count is 224. The current “EIGRP maximum hopcount” may default to “100”, and may be seen by running “ sh ip prot ” when there is a route being shared.)

Traffic details

In theory, EIGRP may use multicast. However, even if it does use multicast, it also uses unicast for some of the traffic. Also, “show ip eigrp interfaces detail” may show a line (for each network interface being reported) that says “Use multicast” or “Use unicast”.

[#cscorlbt]: Cisco's Reliable Transport Protocol

Traffic may use Cisco's proprietary “Reliable Transport Protocol (which Cisco may refer to as “RTP”, although “RTP” may more often refer to the “real-time transport protocol” by IETF STD 64 (July 2003's RFC 3550 and the older January 1996's RFC 1889).

Note that, when discussing protocols, the term “reliable” generally means that communications are acknowledged, or re-sent. For Cisco's “Reliable Transport Protocol”, reliability is actually optional. Some communications over this protocol are connectionless, and may be described as “best effort” (using only a single effort, and not retrying).

This is documented (by Cisco) to be a Layer 4 protocol.

hello packets

These use the connectionless communications.

The “hello” packets do not really contain much/anything in the form of routing data, which is probably done to keep them small.

They get sent every 5 seconds if the link's speed is at least 1.544 Mbps (which is the speed reported for a T1). Slower link speeds result in a “hello” packet being sent every minute. The frequency that the sends these out can be seen by using “show ip eigrp interfaces detail” (where the output says   Hellow interval is 5 sec”.)

acknowledgement packet

Unicast. Connectionless.

reply packet

Unicast. Created in response to a “query” packet.

These communications use a “connection” for “reliable” communication (which does mean that the communication gets acknowledged).

query

These communications use a “connection” for “reliable” communication (which does mean that the communication gets acknowledged). Each neighbor should be sent a query packet when a route goes down. Since this type of packet was not documented to be Unicast, presumably this type of packet may be multicast to 224.0.0.10.

update packet

These communications use a “connection” for “reliable” communication (which does mean that the communication gets acknowledged).

Some Cisco documentation has used the term “Unicast” when describing an update packet.

Cisco CCNA Discovery 4.0 Module 3: “Introducting Routing and Switching in the Enterprise”, Slide #5.3.2.1 states, “EIGRP contains many features that are not found in any other routing protocols.”

EIGRP for IPv4 in IOS

Note: the ifnormation in this section is meant for people using Cisco IOS, and most or all of these details will likely not be applicable for people who are trying to use other operating systems. For further discussion, see the standard Cisco IOS warning.

Example
Getting to “(config-router)” prompt

Select a process ID, which is a non-zero number that fits within 16 bits (meaning a number from 1 through 65,535).

routerName>en
routerName#conf t
routerName(config)#router eigrp 12345
Sharing routes
Sharing routes of directly connected networks

routerName(config-router)#network 192.0.2.0
Additional commands
Summarization

It appears that the way EIGRP creates auto-summary routes is by using classes (/8 Class A, /16 Class B, or /24 Class C network).

routerName ... #no auto-summary

Summarized routes can be specified on an interface configuration.

routerName(config)#interface Fa0/0
routerName(config-if)#ip summary-address eigrp 12345 192.0.2.0 255.255.255.252

The first number shown there is the EIGRP ASN (autonomous system number, which in this case is locally specified and unrelated to any globally-unique centralized ASNs handled out by RIR's/IANA). The next parameter is the IP address and then the subnet mask.

Bandwidth

If communication is going to be over a serial link, use the bandwidth command. (This may typically be unnecessary for Ethernet links, or serial links that report the default EIGRP bandwidth value of 1.544Mbps.) (The value given to bandwidth should be in kbps.)

Logging

Modifications to neighbor adjacencies may be seen with:

routerName ... #eigrp log-neighbor-changes
Using authentication

This is based on some documentation by Cisco. This appears to not be supported by an IOS image used by Packet Tracer.

routerName#config terminal
routerName(config)#key chain keyName

Note that keyName is meant to be customizable.

routerName(config-keychain)#key numeric-key-id

e.g.:

routerName(config-keychain)#key 1

That may send the router into a configuration mode specific to the specified key identifier.

routerName(config-keychain-key)#key-string password

also:

routerName(config-keychain-key)#end
routerName#config terminal
routerName(config)#interface Fa0/0
routerName(config-if)#ip authentication mode eigrp md5

and...

routerName(config-if)#ip authentication key-chain eigrp 1 keyName

The first digit shown there is the EIGRP ASN (autonomous system number), which is local (and not the same thing as a globally centralized/unique ASN overseen by RIR's/IANA). The next parameter is also customizable, and probably should match the key chain command from earlier.

The parts that will need to match other routers are the ASN and the key-string. Other values, like the name of the chain and the numeric key-id, do not need to match other routers.

EIGRP for IPv6 in IOS

Note: the ifnormation in this section is meant for people using Cisco IOS, and most or all of these details will likely not be applicable for people who are trying to use other operating systems. For further discussion, see the standard Cisco IOS warning.

At the moment, these directions may be partial. (Further details may be needed for this section to really feel complete.)

Make sure to also traffic forwarding in Cisco IOS is enabled. (It is presumed that this is desirable.)

This is enabled on a paritcular interface. Also, it seems that the EIGRP process will need to be numbered, so come up with a process number.

deviceName(config)# interface fa0/1
deviceName(config-if)# ipv6 eigrp 1 area 0

Also, there is a logical “EIGRP for IPv6” something that needs to be brought out of shutdown status. (This sort of thing is not required for OSPFv3 or RIPv6).

deviceName(config-if)# exit
deviceName(config)# ipv6 router eigrp 1
deviceName(config-rtr)# no shutdown

Note: when configuring, do not try to share networks with the network commands. Share networks with interface commands.

Note: This is all of the information provided by this guide at this time. For more extensive information, consider reviewing additional information that may be online, or check out the equivilent protocol that is designed for IPv4, because presumably some similarities may be likely.

The status of this protocol being running can be seen with:

show ipv6 protocol

IANA IPv4 Multicast Assignments has 224.0.0.10 reserved for IGRP. The address is also used by EIGRP.

Border Gateway Protocol

Wikipedia's article on Border Gateway Protocol states, “BGP does not involve traditional Interior Gateway Protocol (IGP) metrics, but routing decisions are made based on path, network policies and/or rule-sets. For this reason, it is more appropriately termed a reachability protocol rather than routing protocol.” However, despite any technical distinction being made there, BGP is often mentioned as a “routing protocol”.

Wikipedia's article on Border Gateway Protocol states that RFC 4271 (BGP-4) “corrected a number of errors, clarified ambiguities and brought the RFC much closer to industry practices.” (January 2006's BGP-4 had multiple earlier RFC documents. The previous one may have been March 1995's RFC 1771.)

Implementations

OpenBGPD is a free implementation. Other “Open source packages that run BGP” are mentioned by Wikipedia's article for “Border Gateway Protocol”, section called “Requirements of a router for use of BGP for Internet and backbone-of-backbones purposes”, and the following section (mostly repeating the list), Wikipedia's article for “Border Gateway Protocol”, section called “Free and open source implementations”. Following sections of the article mention simulators and test equipment.

Cisco IOS

Note: There is quite a bit more to working with a professional-level Cisco device than just knowing the command line. This is actually discussed further even within this section on routing. For more references to further details about working with Cisco devices, see: Cisco IOS command to view routing tables.

Note: the ifnormation in this section is meant for people using Cisco IOS, and most or all of these details will likely not be applicable for people who are trying to use other operating systems. For further discussion, see the standard Cisco IOS warning.

Warning: these instructions are probably based on some documentation, and not experience.

routerName>en
routerName#conf t
routerName(config)#router bgp ASN

(“ASN” is an AS number, so that parameter should actually be numeric.)

For a CPE (Customer Premise Equipment) router to communicate with an ISP router that is a BGP neighbor:

routerName(config-router)#neighbor 192.0.2.1 remote-as ASN

The IPv4 address pecified is the neighbor router, and the ASN specified is the same ASN.

To advertise an internal route:

routerName(config-router)#network 203.0.113.0
Sending received traffic to another NIC
[#bdgvsfwd]: [#brdvsfwd]: Overviews to decide which method to use

The difference between traffic forwarding and bridging are often miniscule enough that commonly either method may be used, without significant advantages of one method over another. Here is a brief summary of some differences that may exist.

Overview of (Layer 3) traffic forwarding

Forwarding layer 3 traffic, such as IP packets, may offer an insignificant larger amount of control over the network, because traffic that doesn't match the specific supported forms of layer 3 traffic won't be forwarded. There may be a bit more of a separation of traffic, which needs to be handled (by making sure that routing is sufficiently updated to get things to work). That may take a bit more initial configuration time, although the end results may be that more equipment has configurations that accurately describe more details of how the network is really set up.

Overview of bridging
Bridging layer 2 frames may induce a bit less overhead. Communication between NICs may appear to be on the same subnet, which may simplify the handling of some routing barriers, and that may cause some of the more advanced routing to be unnecessary. This unnecessity of dealing with routing can have a drawback, which is that the need for routing could essentially help to hide hide some of the complexity of what devices is actually hooked up to which other devices. Hiding the complexity, rather than dealing with it in a controlled fashion, could cause some people to forget about the real complexity of how things really are set up, and cause other people (who might be attackers) and computers (that may be attackers) to never even realize the true complexity.

If traffic handling (firewalling/routing) rules are in place, using the traffic handling technology that matches those rules may simplify some tasks (including initial setup and/or auditing/debugging/troubleshooting down the road). What that last sentence means is that if the traffic handling rules are implemented in layer 3, use traffic forwarding instead of bridging.

If in doubt, a simple recommendation is to go ahead with traffic forwarding, and for this simple amount of logic (as right or wrong as it may be): Although traffic forwarding may very likely take a bit longer to implement, the end result may be nicer in some ways, and more learning is more likely.

Some people may disagree with that recommendation. As stated in the first paragraph of the overviews to decide which method to use, the differences may be rather miniscule, so the provided recommendations are not strong. (Flexibility may certainly be an option.)

[#trfwdbas]: Basic traffic forwarding/routing
The web page about “basic traffic forwarding/routing” of network traffic involves the process of listening on one NIC, and sending traffic to a different NIC (even if neither NIC is on a network with the destination address).
[#bridging]: Bridging
What bridging is

Bridging involves having a device listen to all traffic of some type, on one or more NICs, and sending a copy of that traffic onto another NIC. Bridging is typically set up to allow all sorts of Layer 2 traffic, including broadcast traffic which routers do not typically forward from one link segment to another (except when they are performing the task of bridging). (Since this is done on a level of dealing with Layer 2 frames, such as Ethernet frames, it does not matter if the content/payload of the layer 2 frame involves IPv6 packets, or IPv4 packets, or IPX data, or any other payload that are commonly contained entirely within Layer 2 frames. A similar process can be done for layer three packets: In such a case, the process is generally called “forwarding” and is typically not called “bridging”. If that process is what details are being sought for, then see the traffic forwarding section.)

A hardware device that performs this function, but which has only two ports, is called a (network) bridge. A hardware device which performs this function with more than two ports might be called a multi-port bridge, although the name given to such a specialized device is usually to call such a device a “switch”, unless the device performs other functions that causes it to have another (more specialized) name. (For example, a device that bridges a wireless network to a wired network may be more commonly referred to by a more specific name such as a “wireless access point”. Another example of a device which may have switch-like characteristics, but is usually called by another name, is a hardware firewall.)

Software may also be used to perform bridging technology. Typically (using operating systems that use standard terminology), a computer/device will review the received data and determine what the “physical address” is the destination for the data. If the destination address is the MAC address of the NIC that received the traffic, then the contents of the frame are reviewed. Otherwise, the computer will typically ignore the received data if the NIC that received the data is not in “promiscious mode”. Having the NIC in “promiscious mode” specifically means that the computer is not going to choose to ignore the data just because the data's destination address doesn't match the MAC address of the NIC that received the data.

Implementations
OpenBSD
OpenBSD Bridging Basics/Overview
OpenBSD's implementation involves having a “bridge” “device”. The bridge devices may be viewed with brconfig -a quite similarly to how standard network interface cards can be viewed with ifconfig -a.
Starting to use a bridge
To create a bridge interface, identify the desired bridge device number (such as zero) and then use a command such as: “ ifconfig bridge0 create ” Then to add a NIC to the list of NICs that are part of that bridge device, find the name of the NIC to add and use a command similar to the following example (which is meant for a NIC called “if0”):
brconfig bridge0 add if0
Naturally, after adding one interface, be sure to add another interface. Based on an old note, it looks like the word “ up” should be added to a brconfig line?
Ending the use of a bridge

To remove all devices from the bridge, first identify which devices are on the bridge, using a command such as: “ brconfig bridge0 ”. Such a command may provide more information than just the list of devices: look for a line that says “flags” as such a line may/will start with the name of a network interface. Then remove all such devices using a command such as the following (which would remove an interface called if0 from a bridge named bridge0).

brconfig bridge0 delete if0

If any of the bridged devices were virtual network interface cards

If all devices are removed from the bridge and the bridge doesn't need to exist anymore, remove the bridge device itself with:

ifconfig bridge0 destroy
Using a bridge in Microsoft Windows

Shannon Bray's Wordpress site: article “Configuring RRAS for Windows Server 2008 R2” discusses making a bridge, provides several screenshots, and notes that if a NIC is part of a bridge, and has IPv6 enabled, then that configuration “causes errors that gets reported” [sic]. The error has a source of “RemoteAccess”, Event ID 20106, and says “Unable to add the interface {” ([interface ID]) “} with the Router Manager for the IPv6 protocol. The following error occurrebd: Cannot complete this function.”

Warning: When following the below instructions to the physical adapter is added to the bridge, it stops communicating with its own MAC address. This can completely disrupt an existing RDP session, so this may not be the easiest/safest approach if trying to set this up remotely.

In the Network Connections of the control panel, hold down the Ctrl key and then click each NIC to be added. Alternatively, hold Ctrl and press Space to select, and use Ctrl with arrow keys to move without losing the selection. Once each NIC is selected, bridge.

[#firewall]: Firewalling

At its core, firewalling is basically an implementation of traffic routing. Dropping packets may be thought of as the act of sending certain types of traffic to a specific destination: non-existance.

Block/Deny/Drop/Decline traffic
(This is discussed more in the section dedicated to Firewalling.)
Allowing Traffic
Passing allowed traffic
e.g. Accepting allowed traffic (e.g. allowing ICMP, and forwarding traffic.) (This is discussed more in the section dedicated to Firewalling.)
Modifying traffic

NAT, redirection, and asymmetric routing

(This is discussed more in the section dedicated to Firewalling.)

Some other traffic handling (commonly implemented by firewalls)

Details, such as the [#portfwdi]: Port forwarding section, have been moved to the firewalling section.

[#tunltraf]: Tunneling Traffic
[#sshptfwd]: Creating a port forwarding rule using SSH
This is often a simple way to add encryption to traffic, even if the traffic is created (sent) or used (received) by software which does not support the method of encryption being used.
Authpf
...
VPN
...
Other ways to handle traffic

Multiple options may be discussed in the section about firewalling. Details focused more on the decision making are covered in more detail in that section of text.

[#drctsvrt]: Direct (Server) Return/Routing

OpenBSD Journal's article on DSR describes this, including showing a picture. The picture has traffic going from a router to a load balancer, and then to an individual server, but then the individual server will send the return traffic back to the router instead of going through the load balancer. This prevents the load balancer from needing to handle return traffic, which reduces the amount of work that device/process needs to handle, and the reduction in overhead (by needing to go through the device/process that is load balancing) will likely make the return traffic reach the router faster.

With DSR, the load balancer is often not needing to be the bottleneck (assuming all equipment has equal capabilities) because the traffic (web requests) sent to the individual servers is a small amount compared to the greater amount of traffic sent from the servers. (Without DSR, all return traffic from multiple servers may go through a smaller number of load balancers, resulting in the load balancers being the bottleneck.)

In addition to the DSR page on the OpenBSD Journal, Calomel.org's Relayd proxy "how to" (relayd.conf ) article (in the section titled “Example 7: Direct Server Return (DSR)”) has some additional information.

Calomel's guide (mentioned above) has stated that using some of the techniques mentioned, such as the “sloppy state” “directive in PDF is incredibly insecure and easily compromised.” The page quote some text on the OpenBSD Journal's page where a developer, reyk, summarizes: “Don't use it.” He describes the process as “scary”.

Until this feature is announced without such warnings about the security risks to using such techniques, this may be a technology to hold off from implementing. Therefore, no further instructions are being provided at the time of these notes were made. However, it is anticipated that such a technique will be offered in the future, and instructions may be provided at/after that time.

Direct Routing
A term in Linux, similar/identical to Direct Server Return/Routing.
[#netldbal]: Load balancing of network traffic

This involves setting up multiple possible routes (if that hasn't already been done). The desire is going to be to send the traffic using the most desirable route. Often this may be implemented in the negative, by sending traffic along the route which is least undesirable. There may be a value that indicates how undesirable a route is. A route may be less desirable for multiple reasons. Examples include: The route being unlikely to work (because of a portion of a network which is intentionally down, or otherwise not working desirably), because the route is more expensive to send traffic over, because there is a longer period of time required to transmit the traffic over that route, or the performance hit expected if sending website traffic to one server which is already overloaded instead of using another web server which is less utilized (and perhaps under-utilized). Any combination of methods, whether using those examples or other methods of determining how desirable a route is, may be used. The word “cost” may, rather commonly, refer to a numeric value that indicates how undesirable a route is, whether the reason for the route being undesirable is because of an actual financial cost or because of any other reason.

A commonly introduced method of using load balancing, at least initially, may check for only one thing: is that the route which, out of all available routes believed to be working, the route which has not been used for the longest period of time? If all other available routes have had traffic sent more recently, then the route may have traffic be sent. (The next time a choice needs to be made, that route will have had the traffic sent most recently, and so that route is not likely to be used again sooner than any other route.)

Some further information may be available at: PF: Address Pools and Load Balancing, Microsoft KB Q323431: How To Set Up TCP/IP for Network Load Balancing in Windows Server 2003, Microsoft KB Q323437: How To Configure Network Load Balancing Parameters in Windows Server 2003

Similar techniques
(Some of the following text may be speculation, providing points of ways to check out, but not necessarily be thoroughly tested at the time of this writing.) Throttling might be doable using load balancing rules. (Another option might be to use CStream.)
[#fwlrdndc]: Firewall Redundancy

The term “First Hop Redundancy Protocol” (“FHRP”) may apply to some of these protocols.

[#carp]: Common Address Redundancy Protocol (“CARP”)

Amazingly, this protocol's acronym is reminiscent of an undersea creature. Who'd've ever guessed that the OpenBSD team would've ever done a thing like that?

PF Guide: Firewall Redundancy with CARP and pfsync

CARP has been heavily supported by OpenBSD. It appears that there may be a variation, floating around in some other source operating systems, called carpd. Documentation for carpd does not seem super-abundant on the web: perhaps Security Target (viewed by Google Docs) may have some more details. CompTIA has mentioned it as an objective of the Network+ certification. (In Objective section 4.6 of the N10-005 version of the exam, CARP is listed as a method of optimization. The attached glossary does show that this is indeed referring to the Common Address Redundancy Protocol.)

OpenBSD 3.5 commentary: “CARP License” and “Redundancy must be free” boasts, “To date, we have built a few networks that include as many as 4 firewalls, all running random reboot cycles. As long as one firewall is alive in a group, traffic through them moves smoothly and correctly for all of our packet filter functionality.”

[#vrrp]: Virtual Router Redundancy Protocol (“VRPP”)

RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6

OpenBSD 3.5 commentary: “CARP License” and “Redundancy must be free” has some serious discussion and parodies VRRP.

Hot Standby Router Protocol (“HSRP”)

RFC 2281: Cisco Hot Standby Router Protocol includes RFC 2281: “Cisco Hot Standby Router Protocol” section 2: “Conditions of Use” which identifies Cisco's US Patent number 5,473,599.

OpenBSD 3.5 commentary: “CARP License” and “Redundancy must be free” notes, “Due to some HSRP flaws fixed by VRRP and for compatibility with the (HSRP-licensed) VRRP implementations of their competitors, Cisco in recent times has largely abandoned HSRP and now relies on VRRP instead”. Being that HSRP is a Cisco protocol, it seems like HSRP is likely doomed to share the same fate as IGRP (another proprietary Cisco protocol which was abandoned in favor of a variation; in this case, EIGRP).

IPSTB

This is mentioned by RFC 5798 (VRRP) reference to IPSTB, and the last sentence of the section called “Introduction” in that same RFC document.

VLANs

Some people may say that VLANs operate at Layer 2, whereas routing operates at Layer 3, and so the topic of VLANs isn't exactly routing traffic. However, VLANs can prevent communication similar to if devices are on different subnets and are not being routed, so this topic is considered to be close enough to be documented in this section. As a similar example, some people may consider firewalling to be a separate topic, but that is mentioned in this routing section. This guide to routing is not intended to be very strict about what topics can be considered to be broadly related in nature.

See: VLANs.

Spanning-Tree Protocol (“STP”)

Like VLANs, this is not about routing traffic between networks. This is about determining the path that routers will take through a network of switches. One of the key goals to the design of the Spanning-Tree Protocol was to prevent switching loops.

Note: The abbreviation of “STP” can refer to Spanning-Tree Protocol or shielded twisted pair (copper cabling) or, less commonly, screened twisted pair (“ScTP”) (copper cabling).

For further details, see the section on the Spanning-Tree Protocol.

That section is also the home for details about successor variations, like Rapid Spanning-Tree Protocol.

Troubleshooting network communications

See: Troubleshooting network communications. (Some of the solutions are related to routing.)