3. VRFs - Multiple Forwarding Tables in PEs
3. VRFs: Multiple Forwarding Tables in PEs
Each PE router maintains a number of separate forwarding tables. One of the forwarding tables is the "default forwarding table". The others are "VPN Routing and Forwarding tables", or "VRFs".
3.1. VRFs and Attachment Circuits
Every PE/CE attachment circuit is associated, by configuration, with one or more VRFs. An attachment circuit that is associated with a VRF is known as a "VRF attachment circuit".
In the simplest case and most typical case, a PE/CE attachment circuit is associated with exactly one VRF. When an IP packet is received over a particular attachment circuit, its destination IP address is looked up in the associated VRF. The result of that lookup determines how to route the packet. The VRF used by a packet's ingress PE for routing a particular packet is known as the packet's "ingress VRF". (There is also the notion of a packet's "egress VRF", located at the packet's egress PE; this is discussed in Section 5.)
If an IP packet arrives over an attachment circuit that is not associated with any VRF, the packet's destination address is looked up in the default forwarding table, and the packet is routed accordingly. Packets forwarded according to the default forwarding table include packets from neighboring P or PE routers, as well as packets from customer-facing attachment circuits that have not been associated with VRFs.
Intuitively, one can think of the default forwarding table as containing "public routes", and of the VRFs as containing "private routes". One can similarly think of VRF attachment circuits as being "private", and of non-VRF attachment circuits as being "public".
If a particular VRF attachment circuit connects site S to a PE router, then connectivity from S (via that attachment circuit) can be restricted by controlling the set of routes that gets entered in the corresponding VRF. The set of routes in that VRF should be limited to the set of routes leading to sites that have at least one VPN in common with S. Then a packet sent from S over a VRF attachment circuit can only be routed by the PE to another site S' if S' is in one of the same VPNs as S. That is, communication (via PE routers) is prevented between any pair of VPN sites that have no VPN in common. Communication between VPN sites and non-VPN sites is prevented by keeping the routes to the VPN sites out of the default forwarding table.
If there are multiple attachment circuits leading from S to one or more PE routers, then there might be multiple VRFs that could be used to route traffic from S. To properly restrict S's connectivity, the same set of routes would have to exist in all the VRFs. Alternatively, one could impose different connectivity restrictions over different attachment circuit from S. In that case, some of the VRFs associated with attachment circuits from S would contain different sets of routes than some of the others.
We allow the case in which a single attachment circuit is associated with a set of VRFs, rather than with a single VRF. This can be useful if it is desired to divide a single VPN into several "sub-VPNs", each with different connectivity restrictions, where some characteristic of the customer packets is used to select from among the sub-VPNs. For simplicity though, we will usually speak of an attachment circuit as being associated with a single VRF.
3.2. Associating IP Packets with VRFs
When a PE router receives a packet from a CE device, it must determine the attachment circuit over which the packet arrived, as this determines in turn the VRF (or set of VRFs) that can be used for forwarding that packet. In general, to determine the attachment circuit over which a packet arrived, a PE router takes note of the physical interface over which the packet arrived, and possibly also takes note of some aspect of the packet's layer 2 header. For example, if a packet's ingress attachment circuit is a Frame Relay VC, the identity of the attachment circuit can be determined from the physical Frame Relay interface over which the packet arrived, together with the Data Link Connection Identifier (DLCI) field in the packet's Frame Relay header.
Although the PE's conclusion that a particular packet arrived on a particular attachment circuit may be partially determined by the packet's layer 2 header, it must be impossible for a customer, by writing the header fields, to fool the SP into thinking that a packet that was received over one attachment circuit really arrived over a different one. In the example above, although the attachment circuit is determined partially by inspection of the DLCI field in the Frame Relay header, this field cannot be set freely by the customer. Rather, it must be set to a value specified by the SP, or else the packet cannot arrive at the PE router.
In some cases, a particular site may be divided by the customer into several "virtual sites". The SP may designate a particular set of VRFs to be used for routing packets from that site and may allow the customer to set some characteristic of the packet, which is then used for choosing a particular VRF from the set.
For example, each virtual site might be realized as a VLAN. The SP and the customer could agree that on packets arriving from a particular CE, certain VLAN values would be used to identify certain VRFs. Of course, packets from that CE would be discarded by the PE if they carry VLAN tag values that are not in the agreed-upon set. Another way to accomplish this is to use IP source addresses. In this case, the PE uses the IP source address in a packet received from the CE, along with the interface over which the packet is received, to assign the packet to a particular VRF. Again, the customer would only be able to select from among the particular set of VRFs that that customer is allowed to use.
If it is desired to have a particular host be in multiple virtual sites, then that host must determine, for each packet, which virtual site the packet is associated with. It can do this, e.g., by sending packets from different virtual sites on different VLANs, or out different network interfaces.
3.3. Populating the VRFs
With what set of routes are the VRFs populated?
As an example, let PE1, PE2, and PE3 be three PE routers, and let CE1, CE2, and CE3 be three CE routers. Suppose that PE1 learns, from CE1, the routes that are reachable at CE1's site. If PE2 and PE3 are attached, respectively, to CE2 and CE3, and there is some VPN V containing CE1, CE2, and CE3, then PE1 uses BGP to distribute to PE2 and PE3 the routes that it has learned from CE1. PE2 and PE3 use these routes to populate the VRFs that they associate, respectively, with the sites of CE2 and CE3. Routes from sites that are not in VPN V do not appear in these VRFs, which means that packets from CE2 or CE3 cannot be sent to sites that are not in VPN V.
When we speak of a PE "learning" routes from a CE, we are not presupposing any particular learning technique. The PE may learn routes by means of a dynamic routing algorithm, but it may also "learn" routes by having those routes configured (i.e., static routing). (In this case, to say that the PE "learned" the routes from the CE is perhaps to exercise a bit of poetic license.)
PEs also need to learn, from other PEs, the routes that belong to a given VPN. The procedures to be used for populating the VRFs with the proper sets of routes are specified in Section 4.
If there are multiple attachment circuits leading from a particular PE router to a particular site, they might all be mapped to the same forwarding table. But if policy dictates, they could be mapped to different forwarding tables. For instance, the policy might be that a particular attachment circuit from a site is used only for intranet traffic, while another attachment circuit from that site is used only for extranet traffic. (Perhaps, e.g., the CE attached to the extranet attachment circuit is a firewall, while the CE attached to the intranet attachment circuit is not.) In this case, the two attachment circuits would be associated with different VRFs.
Note that if two attachment circuits are associated with the same VRF, then packets that the PE receives over one of them will be able to reach exactly the same set of destinations as packets that the PE receives over the other. So two attachment circuits cannot be associated with the same VRF unless each CE is in the exact same set of VPNs as is the other.
If an attachment circuit leads to a site which is in multiple VPNs, the attachment circuit may still associated with a single VRF, in which case the VRF will contain routes from the full set of VPNs of which the site is a member.