Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring Junos OS Routing Tables

 

Understanding Junos OS Routing Tables

Junos OS automatically creates and maintains several routing tables. Each routing table is used for a specific purpose. In addition to these automatically created routing tables, you can create your own routing tables.

Each routing table populates a portion of the forwarding table. Thus, the forwarding table is partitioned based on routing tables. This allows for specific forwarding behavior for each routing table. For example, for VPNs, each VPN-based routing table has its own VPN-specific partition in the forwarding table.

It is common for the routing software to maintain unicast routes and multicast routes in different routing tables. You also might have policy considerations that would lead you to create separate routing tables to manage the propagation of routing information.

Creating routing tables is optional. If you do not create any, Junos OS uses its default routing tables, which are as follows:

  • inet.0—For IP version 4 (IPv4) unicast routes. This table stores interface local and direct routes, static routes, and dynamically learned routes.

  • inet.1—For the IPv4 multicast forwarding cache. This table stores the IPv4 (S,G) group entries that are dynamically created as a result of join state information.

  • inet.2—For subsequent address family indicator (SAFI) 2 routes, when multiprotocol BGP (MBGP) is enabled. This table stores unicast routes that are used for multicast reverse-path-forwarding (RPF) lookup. The routes in this table can be used by the Distance Vector Multicast Routing Protocol (DVMRP), which requires a specific RPF table. In contrast, Protocol Independent Multicast (PIM) does not need this table because it can perform RPF checks against the inet.0 table. You can import routes from inet.0 into inet.2 using routing information base (RIB) groups, or install routes directly into inet.2 from a multicast routing protocol.

  • inet.3—For IPv4 MPLS. This table stores the egress address of an MPLS label-swiched path (LSP), the LSP name, and the outgoing interface name. This routing table is used only when the local device is the ingress node to an LSP.

  • inet6.0—For IP version 6 (IPv6) unicast routes. This table stores interface local and direct routes, static routes, and dynamically learned routes.

  • inet6.1—For IPv6 multicast forwarding cache. This table stores the IPv6 (S,G) group entries that are dynamically created as a result of join state information.

  • instance-name.inet.0—If you configure a routing instance, Junos OS creates the default unicast routing table instance-name.inet.0.

  • instance-name.inet.2—If you configure routing-instances instance-name protocols bgp family inet multicast in a routing instance of type VRF, Junos OS creates the instance-name.inet.2 table.

    Another way to create the instance-name.inet.2 table is to use the rib-group statement. See Example: Exporting Specific Routes from One Routing Table Into Another Routing Table.

    Note

    Importing inet-vpn multicast routes from the bgp.l3vpn.2 table into the instance-name.inet.2 table does not create the instance-name.inet.2 table. The import operation works only if the instance-name.inet.2 table already exists.

  • instance-name.inetflow.0—If you configure a flow route, Junos OS creates the flow routing table instance-name.inetflow.0.

  • bgp.l2vpn.0—For Layer 2 VPN routes learned from BGP. This table stores routes learned from other provider edge (PE) routers. The Layer 2 routing information is copied into Layer 2 VPN routing and forwarding instances (VRFs) based on target communities.

  • bgp.l3vpn.0—For Layer 3 VPN routes learned from BGP. This table stores routes learned from other PE routers. Routes in this table are copied into a Layer 3 VRF when there is a matching route table.

  • l2circuit.0—For l2circuit routes learned from LDP. Routes in this table are used to send or receive l2circuit signaling messages.

  • mpls.0—For MPLS label switching operations. This table is used when the local device is a transit router.

  • iso.0—For IS-IS routes. When you are using IS-IS to support IP routing, this table contains only the local device’s network entity title (NET).

  • juniper_private—For Junos OS to communicate internally between the Routing Engine and PIC hardware.

Routing Table Features in Junos OS

Junos OS maintains two databases for routing information:

  • Routing table—Contains all the routing information learned by all routing protocols. (Some vendors refer to this kind of table as a routing information base [RIB].)

  • Forwarding table—Contains the routes actually used to forward packets. (Some vendors refer to this kind of table as a forwarding information base [FIB].)

By default, Junos OS maintains three routing tables: one for IP version 4 (IPv4) unicast routes, a second for multicast routes, and a third for MPLS. You can configure additional routing tables.

The Junos OS maintains separate routing tables for IPv4 and IP version 6 (IPv6) routes.

The Junos OS installs all active routes from the routing table into the forwarding table. The active routes are routes that are used to forward packets to their destinations. The Junos operating system kernel maintains a master copy of the forwarding table. It copies the forwarding table to the Packet Forwarding Engine, which is the component responsible for forwarding packets.

The Junos routing protocol process generally determines the active route by selecting the route with the lowest preference value. The Junos OS provides support for alternate and tiebreaker preferences, and some of the routing protocols, including BGP and MPLS, use these additional preferences.

You can add martian addresses and static, aggregate, and generated routes to the Junos routing tables, configuring the routes with one or more of the properties shown in Table 1.

Table 1: Routing Table Route Properties

Description

Static

Aggregate

Generated

Destination address

X

X

X

Default route to the destination

X

X

X

IP address or interface of the next hop to the destination

X

Label-switched path (LSP) as next hop

X

Drop the packets, install a reject route for this destination, and send Internet Control Message Protocol (ICMP) unreachable messages

X

X

X

Drop the packets, install a reject route for this destination, but do not send ICMP unreachable messages

X

X

X

Cause packets to be received by the local router

X

Associate a metric value with the route

X

X

X

Type of route

X

X

X

Preference values

X

X

X

Additional preference values

X

X

X

Independent preference (qualified-next-hop statement)

X

BGP community information to associate with the route

X

X

X

Autonomous system (AS) path information to associate with the route

X

X

X

OSPF tag strings to associate with the route

X

X

X

Do not install active static routes into the forwarding table

X

Install the route into the forwarding table

X

Permanently retain a static route in the forwarding table

X

Include only the longest common leading sequences from the contributing AS paths

X

Include all AS numbers for a specific route

X

Retain an inactive route in the routing and forwarding tables

X

X

X

Remove an inactive route from the routing and forwarding tables

X

X

X

Active policy to associate with the route

X

X

Specify that a route is ineligible for readvertisement

X

Specify route to a prefix that is not a directly connected next hop

X

Understanding Default Routing Table Groups for Interface Routes on PTX Routers

On PTX Series Packet Transport Routers, the default interface-route routing table groups differ from that of other Junos OS routing devices.

The PTX Series routers are MPLS transit platforms that do IP forwarding, typically using interior gateway protocol (IGP) routes. Interface routes are directly connected and local routes.

PTX Series routers are unlike other Junos OS routing devices in that they force an indirect next-hop resolution. PTX Series routers need the indirect next hop be resolved to create the chained composite next hop. This can cause routes to be hidden when the next-hop type is unusable.

To prevent routes from being hidden, PTX Series platforms automatically copy the routes in inet.0 into inet.2 and inet.3, and the routes in inet6.0 into inet6.2 and inet6.3.

The default interface routing table configuration on the PTX Series routers is as follows:

Example: Creating Routing Tables

This example shows how to create a custom routing table.

Requirements

In this example, no special configuration beyond device initialization is required.

Overview

Creating routing tables is optional. You might have policy considerations that would lead you to create separate routing tables to manage the propagation of routing information. This capability is rarely used, but it is demonstrated here for completeness.

If you do not create any routing tables, Junos OS uses its default routing tables.

Note

If you want to add static, aggregate, generated, or martian routes only to the default IPv4 unicast routing table (inet.0), you do not have to create any routing tables because, by default, these routes are added to inet.0. You can add these routes by including the static, aggregate, generate, and martians statements.

To explicitly create a routing table, include the rib statement and child statements under the rib statement.

The routing table name, routing-table-name, includes the protocol family, optionally followed by a period and a number. The protocol family can be inet for the IPv4 family, inet6 for the IPv6 family, or iso for the International Standards Organization (ISO) protocol family. The number represents the routing instance. The first instance is 0.

This example shows how to configure a custom IPv4 routing table called inet.14. The example also shows how to populate the routing table with a single static route.

Note

On EX Series switches, only dynamically learned routes can be imported from one routing table group to another.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To create a routing table:

  1. Configure the routing table.
  2. If you are done configuring the device, commit the configuration.

Results

Confirm your configuration by issuing the show routing-options command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Checking the Routing Table

Purpose

Make sure that the static route appears in the custom routing table.

Action

user@host> show route table inet.14

Meaning

The static route is in the custom routing table.

Example: Exporting Specific Routes from One Routing Table Into Another Routing Table

This example shows how to duplicate specific routes from one routing table into another routing table within the same routing instance.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

This example uses the auto-export statement and the rib-group statement to accomplish the goal of exporting specific routes from one routing table to another.

Consider the following points:

  • When auto-export is configured in a routing instance, the vrf-import and vrf-export policies are examined. Based on the route target and community information in the policies, the auto-export function performs route leaking among the local routing instance inet.0 tables.

  • You can use the rib-group statement if it is necessary to import routes into tables other than instance.inet.0. To use a RIB group with auto-export, the routing instance should specify explicit vrf-import and vrf-export policies. The vrf-import and vrf-export policies can be extended to contain additional terms to filter routes as needed for the RIB group.

In this example, access-internal routes are added into the vpna.inet.0 routing table. The access-internal routes are also duplicated into the vpna.inet.2 routing table.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Configuring Specific Route Export Between Routing Tables

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure the device:

  1. Configure the interfaces.
  2. Configure the routing policy that specifies particular routes for import into vpna.inet.0 and export from vpna.inet.0.
  3. Configure the routing instance.

    The vrf-import and vrf-export statements are used to apply the vpna-import and vpna-export routing policies configured in 2.

  4. Configure the RIB group, and import routes into the vpna.inet.2 routing table.
  5. Configure the auto-export statement to enable the routes to be exported from one routing table into another.
  6. Configure BGP.
  7. Configure the autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show routing-options, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly by running the show table route vpna.inet.0 and show route table vpna.inet.2 commands.