Chapter 8. Routing

Table of Contents

8.1. Routing logic
8.2. Routing targets
8.2.1. Subnet routes
8.2.2. Routing to an IP address (gateway route)
8.2.3. Special targets
8.3. Dynamic route creation / deletion
8.4. Routing tables
8.5. Bonding
8.6. Route overrides

8.1. Routing logic

The routing logic in the FB2900 operates primarily using a conventional routing system of most specific prefix, which is commonly found in many IP stacks in general purpose computers and routers.

Conventional routing determines where to send a packet based only on the packet's destination IP address, and is applied on a 'per packet' basis - i.e. each packet that arrives is processed independently from previous packets.

Note that with this routing system, it does not matter where the packet came from, either in terms of source IP address or which interface/tunnel etc. the packet arrived on.

The FB2900 also implements more specialised routing logic that can route traffic based on other characteristics, such as source address, that can be used when routing based on destination IP address alone is insufficient. This is linked into the session tracking logic (see Chapter 7).

A route consists of :-

  • a 'target' specifying where to send the packet to - this may be a specialised action, such as silently dropping the packet (a 'black-hole')
  • an IP address range that this routing information applies to - the routing destination

A routing table consists of one or more routes. Unlike typical IP stacks, the FB2900 supports multiple independent routing tables.

Routing destinations are expressed using CIDR notation - if you are not familiar with this notation, please refer to Appendix B for an overview. Note that ip-groups cannot be used when defining subnets or routes. IP-groups allow arbitrary ranges and not just prefixes, but routes can only use prefixes.

There are two cases that deserve special attention :-

  • A routing destination may be a single IP address, in which case it is a "/32" in CIDR notation (for IPv4). The /32 part (for IPv4) or /128 (for IPv6) is not shown when displaying such prefixes.
  • A routing destination may encompass the entire IPv4 (or IPv6) address space, written as 0.0.0.0/0 (for IPv4) or ::/0 (for IPv6) in CIDR notation. Since the prefix is zero-length, all destination IP addresses will match this route - however, it is always the shortest-prefix route present, and so will only match if there are no more specific routes. Such routes therefore acts as a default route.

The decision of where to send the packet is based on matching the packet's destination IP address to one or more routing table entries. If more than one entry matches, then the longest (most specific) prefix entry is used. The longest prefix is assumed to be associated with the optimal route to the destination IP address, since it is the 'most specific', i.e. it covers a smaller IP address range than any shorter matching prefix.

For example, if you have two routes, one for 10.0.1.32/27 , and another for 10.0.0.0/8 (which encompasses 10.0.1.32/27), then a destination IP address of 10.0.1.35 will match the longest-prefix (smallest address range) "/27" route.

The order in which routes are created does not normally matter as you do not usually have two routes that have the same prefix. However, there is an attribute of every route called the localpref which decides between identical routes - the higher localpref being the one which applies. If you have identical routes with the same localpref then one will apply (you cannot rely on which one) but it can, in some cases, mean you are bonding multiple links.

Tip

You can show the route(s) that apply for a specific destination IP address or address range using the CLI command show route. You can also see a list of all routes in a routing table using the CLI command show routes. There is also a routing display on the Diagnostics control web pages.