VPN Routing and Forwarding Tables

To separate a VPN’s routes from routes in the public Internet or those in other VPNs, the PE router creates a separate routing table for each VPN, called a VPN routing and forwarding (VRF) table. The PE router creates one VRF table for each VPN that has a connection to a CE router. Any customer or site that belongs to the VPN can access only the routes in the VRF tables for that VPN.

Figure 11 illustrates the VRF tables that are created on the PE routers. The three PE routers have connections to CE routers that are in two different VPNs, so each PE router creates two VRF tables, one for each VPN.

Each VRF table is populated from routes received from directly connected CE sites associated with that VRF routing instance and from routes received from other PE routers that passed BGP community filtering and are in the same VPN.

Each PE router also maintains one global routing table (inet.0) to reach other routers in and outside the provider’s core network.

Each customer connection (that is, each logical interface) is associated with one VRF table. Only the VRF table associated with a customer site is consulted for packets from that site.

You can configure the router so that if a next hop to a destination is not found in the VRF table, the router performs a lookup in the global routing table, which is used for Internet access.

The Junos OS uses the following routing tables for VPNs:

• bgp.l3vpn.0—Stores all VPN-IPv4 unicast routes received from other PE routers. (This table does not store routes received from directly connected CE routers.) This table is present only on PE routers.

  When a PE router receives a route from another PE router, it places the route into its bgp.l3vpn.0 routing table. The route is resolved using the information in the inet.3 routing table. The resultant route is converted into IPv4 format and redistributed to all routing-instance-name.inet.0 routing tables on the PE router if it matches the VRF import policy.

  The bgp.l3vpn.0 table is also used to resolve routes over the MPLS tunnels that connect the PE routers. These routes are stored in the inet.3 routing table. PE-to-PE router connectivity must exist in inet.3 (not just in inet.0) for VPN routes to be resolved properly.

  To determine whether to add a route to the bgp.l3vpn.0 routing table, the Junos OS checks it against the VRF instance import policies for all the VPNs configured on the PE router. If the VPN-IPv4 route matches one of the policies, it is added to the bgp.l3vpn.0 routing table. To display the routes in the bgp.l3vpn.0 routing table, use the show route table bgp.l3vpn.0 command.

• routing-instance-name.inet.0—Stores all unicast IPv4 routes received from directly connected CE routers in a routing instance (that is, in a single VPN) and all explicitly configured static routes in the routing instance. This is the VRF table and is present only on PE routers. For example, for a routing instance named VPN-A, the routing table for that instance is named VPN-A.inet.0.

  When a CE router advertises to a PE router, the PE router places the route into the corresponding routing-instance-name.inet.0 routing table and advertises the route to other PE routers if it passes a VRF export policy. Among other things, this policy tags the route with the route distinguisher (route target) that corresponds to the VPN site to which the CE belongs. A label is also allocated and distributed with the route. The bgp.l3vpn.0 routing table is not involved in this process.

  The routing-instance-name.inet.0 table also stores routes announced by a remote PE router that match the VRF import policy for that VPN. The remote PE router redistributed these routes from its bgp.l3vpn.0 table.

  Routes are not redistributed from the routing-instance-name.inet.0 table to the bgp.l3vpn.0 table; they are directly advertised to other PE routers.

  For each routing-instance-name.inet.0 routing table, one forwarding table is maintained in the router’s Packet Forwarding Engine. This table is maintained in addition to the forwarding tables that correspond to the router’s inet.0 and mpls.0 routing tables. As with the inet.0 and mpls.0 routing tables, the best routes from the routing-instance-name.inet.0 routing table are placed into the forwarding table.

  To display the routes in the routing-instance-name.inet.0 table, use the show route table routing-instance-name.inet.0 command.

• inet.3—Stores all MPLS routes learned from LDP and RSVP signaling done for VPN traffic. The routing table stores the MPLS routes only if the traffic-engineering bgp-igp option is not enabled.

  For VPN routes to be resolved properly, the inet.3 table must contain routes to all the PE routers in the VPN.

  To display the routes in the inet.3 table, use the show route table inet.3 command.

  Interior gateway protocol (IGP) shortcuts do not work in VPN environments and should not be configured. IGP shortcuts move routes in inet.3 to inet.0. VPN IBGP (family inet-vpn) relies on next hops that are in the inet.3 table; thus, IGP shortcuts are incompatible with VPNs.

• inet.0—Stores routes learned by the IBGP sessions between the PE routers. To provide Internet access to the VPN sites, configure the routing-instance-name.inet.0 routing table to contain a default route to the inet.0 routing table.

  To display the routes in the inet.0 table, use the show route table inet.0 command.

The following routing policies, which are defined in VRF import and export statements, are specific to VRF tables.

• Import policy—Applied to VPN-IPv4 routes learned from another PE router to determine whether the route should be added to the PE router’s bgp.l3vpn.0 routing table. Each routing instance on a PE router has a VRF import policy.
• Export policy—Applied to VPN-IPv4 routes that are announced to other PE routers. The VPN-IPv4 routes are IPv4 routes that have been announced by locally connected CE routers.

VPN route processing differs from normal BGP route processing in one way. In BGP, routes are accepted if they are not explicitly rejected by import policy. However, because many more VPN routes are expected, the Junos OS does not accept (and hence store) VPN routes unless the route matches at least one VRF import policy. If no VRF import policy explicitly accepts the route, it is discarded and not even stored in the bgp.l3vpn.0 table. As a result, if a VPN change occurs on a PE router—such as adding a new VRF table or changing a VRF import policy—the PE router sends a BGP route refresh message to the other PE routers (or to the route reflector if this is part of the VPN topology) to retrieve all VPN routes so they can be reevaluated to determine whether they should be kept or discarded.