13.8 Forwarding Tables

As was mentioned earlier, BGP/MPLS VPNs use BGP to distribute routes. More specifically the PE routers will control how routing information is distributed between other PE routers within the service provider network. Each of these PE routers will maintain at least one per-site forwarding table. These forwarding tables will contain all of the route information learned from the CE routers about all of the networks that they know about and want the PE routers to distribute to other PE routers and all other CE routers in the same VPN.

The PE routers will only install routes into those per-site forwarding, or virtual routing and forwarding (VRF), tables learned from CE routers that are directly connected to the PE router or routes from the same VPN received from other PEs. All routing look ups for packets destined for networks in the per-site-forwarding table will be handled within the VRF. If there are packets destined for other networks the look up will be based on the standard IP routing table, inet.0 . To control how the routing information is distributed between the PE routers within the service provider network, the per-site forwarding table will be associated with target VPNs or route targets.

The route target is a new BGP extended community attribute defined in RFC 2547 used to control how VPN routing information is distributed between PE routers within the service provider network. When a VPN route is created, it will be associated with one or more route-target attributes and carried in BGP as attributes of the route. This information will be used to identify to each of the PE routers within the service provider network which routes belong to which VPN. Any route that is marked as a VPN route and associated with a route target must be distributed to all PE routers that have the same route target. When a PE router receives a BGP route with the route target attribute set, it identifies that route as eligible to be installed in the per-site forwarding table. Whether or not the route is actually installed into the table is still based on the BGP route decision process.

The route target has a type code of 16 and is encoded in 8 octets. Each extended community attribute has a type field and a value field. The type field is either one or two bytes and the value field will be the remaining bytes. If the type field is one byte, it defines a regular type; if it is two bytes, it defines an extended type. The first bit of the type field is the IANA authority bit. If this bit is set to 0, it defines an IANA-assigned type; if it is set to 1, it defines a vendor-specific type. The second bit of the type field determines whether or not this is a transitive attribute. With the route target community used with VPNs, the type field will be 0 x 0002 or 0 x 0102 (notice that the low-order byte is always 0 x 02). The values of these fields are important in determining whether the assignment of the attribute was based on an IP address or ASN. If the type field value is set to 0 x 00, it identifies that the assignment of this attribute is based on an ASN, while a value of 0 x 01 defines an IP address. Another newly defined attribute used with VPNs is the site-of-origin attribute. This attribute is used to identify the router or routers that inject routes into BGP. It is also transitive across the AS and is used to prevent routing loops between member sites in the VPN. Just like the route target community, the site of origin will have a high-order type field value of either 0 x 00 or 0 x 01, and if this value is 0 x 00, the ASN in the local administrator field must be unique across the AS defined in the global administrator field. The low-order byte for the route of origin will be 0 x 03.

Figure 13-10 explains how the route target community is used. When PE router Chicago receives routes from CE router Rome, Chicago will mark these routes and distribute them to the other PE routers in the network. In the example in Figure 13-10, CE routers Rome and Berlin are member sites of the VPN named "VPN-Red," and CE router Hong Kong is a member site of the VPN named "VPN-Blue." PE router Chicago will distribute the routes for VPN-Red with a route target of 2:64000:100 . PE routers New York and Seattle will receive these routes from the Chicago PE router. New York will install the routes into the VRF for VPN-Red because it has a routing-instance associated with VPN Red that has been configured to import routes with the extended community string set to 2:64000:100 . However, the Seattle PE router's configuration is set to handle routes for VPN Blue, and therefore, will not accept routes for VPN Red.

Figure 13-10. Route Target Operation