Network operators and service providers are consolidating their infrastructure yet adding significant amounts of new services. Engineers and architects are looking for new ways to add those services to backbones, which brings us to the topic of this article: common technologies which can deliver separation across both a shared infrastructure and shared devices.
As each new technology is unveiled, it's up to the engineers and architects to find ways to make the technology work while decreasing the impact of the initial investment. This could mean possibly consolidating the newer technologies on your current infrastructure without adding costly and unneeded circuits. Is your network ready? Forget for a second that we're heading towards service consolidation. Let's focus on a common task, which can serve as the foundation for bigger and better things in the future: separation.
Scenario
Here's the scenario: You're a small service provider with just two customers. Because of your size, you have chosen to pay for only one physical connection to the Internet (through another provider) which your customers will have to share.
Both customers A and B have chosen to use OSPF to exchange routing information with your router. This will allow each customer's networks to be known by all the routers in the Internet. But if you use OSPF for both customers, won't they be able to see each other's routes -- and potentially, everything in each other's networks? Well, maybe -- if you don't choose to separate them!
So how do you, as the provider of services, keep sensitive information between customers separate from each other? Enter the VRF.
The VRF
A virtual routing and forwarding (VRF) instance is, for all intents and purposes, a logical router. A VRF consists of an IP routing table, a forwarding table, a set of interfaces that use the forwarding table and a set of rules and routing protocols that determine what goes into the forwarding table.
With this "logical router" you -- as "the little provider that could" -- can keep customers A and B completely separate from one another. You also simplify management, troubleshooting and future enhancements to each client. In this scenario the provider router, which I will now refer to as the provider edge (PE) router, will use two different instances of OSPF to peer with each customer. The figure below illustrates what this might look like:
This solves the first phase of your separation. The situation is made a little easier because there are two physical interfaces connecting each customer. The harder task is figuring out how to keep A and B separate on the link which connects to the Internet.
Creating the VRF
The actual configuration of a VRF is not a difficult task. There are two main components: The route distinguisher and the route target.
A route distinguisher (RD) is a number, which doesn't actually have any real significance other than to help identify a VPN in a provider's network and allow for overlapping IP space. The RD is an 8-byte number with two parts, a 2-byte type field followed by a 6-byte value field. Without going into too much detail, the value field of the RD is most often represented as an autonomous system number (ASN 2 bytes) followed by an arbitrary number (4 bytes) or an IP address (4 bytes) followed by an arbitrary number (2 bytes). You can enter an RD in either of these formats:
16-bit AS number: your 32-bit number
For example, 101:3.
32-bit IP address: your 16-bit number
For example, 192.168.122.15:1.
The route target (RT) indicates the VPN membership of a route and allows VPN routes to be imported or exported into or out of your VRFs. The RT functions a little like a routing policy -- determining how routes are distributed throughout the particular VPN. Like the RD, the RT is 8 bytes in length and can be entered as:
16-bit AS number: your 32-bit number
For example, 101:3.
32-bit IP address: your 16-bit number
For example, 192.168.122.15:1.
Using the example scenario, let's configure two VRFs on the service provider router. Customer A will have an RD of 192.168.1.1:100 and Customer B will have an RD of 192.168.2.1:200
- Customer A
SP_Router(config)#interface loopback 1
SP_Router(config-if)#description Loopback interface for Customer_A VRF
SP_Router(config)#interface g0/0
SP_Router(config-if)#description Connection to the Customer_A router
SP_Router(config)#ip vrf Customer_A
SP_Router(config-vrf)#rd 192.168.1.1:100
SP_Router(config-vrf)#route-target import 192.168.1.255:100
SP_Router(config-vrf)#route-target export 192.168.1.255:100
- Customer B
SP_Router(config)#interface loopback 2
SP_Router(config-if)#description Loopback interface for Customer_B VRF
SP_Router(config)#interface g0/1
SP_Router(config-if)#description Connection to the Customer_B router
SP_Router(config)#ip vrf Customer_B
SP_Router(config-vrf)#rd 192.168.2.1:200
SP_Router(config-vrf)#route-target import 192.168.2.255:200
SP_Router(config-vrf)#route-target export 192.168.2.255:200
Assigning the interfaces
Once you have created the VRF, you can begin to assign the particular interfaces and start to separate the customers. Notice I did not assign an IP address to the interfaces which are intended to be in the VRF. If you put the IP addresses on prior to putting the interface in the VRF, the IP address will be removed and cause you to have to re-IP the interfaces.
- Customer A
SP_Router(config)#interface lo1
SP_Router(config-if)#ip vrf forwarding Customer_A
SP_Router(config-if)#ip address 192.168.1.1 255.255.255.255
SP_Router(config)#interface g0/0
SP_Router(config-if)#ip vrf forwarding Customer_A
SP_Router(config-if)#ip address 10.1.1.1 255.255.255.252
- Customer B
SP_Router(config)#interface lo2
SP_Router(config-if)#ip vrf forwarding Customer_B
SP_Router(config-if)#ip address 192.168.2.1 255.255.255.255
SP_Router(config)#interface g0/1
SP_Router(config-if)#ip vrf forwarding Customer_B
SP_Router(config-if)#ip address 10.1.2.1 255.255.255.252
These configurations have modified our picture somewhat. The figure below shows what the things look like now:
You can verify your configurations by using the show ip vrf command:
| SP_Router #show ip vrf |
| Name | Default RD | Interfaces |
| Customer_A | 192.168.1.1:100 | Loopback1 |
| | | GigabitEthernet0/0 |
| Customer_B | 192.168.2.1:200 | Loopback2 |
| | | GigabitEthernet0/1 |
Once you have the proper interfaces within the correct VRF, you can begin to establish IP connectivity and routing between the customer routers and the service provider routers.
Static routing
A static route is a manual method for "pointing" towards a route prefix (subnet) through a next-hop router. Traditionally static routing was used on small networks with low-powered routers. It saves processor power and leaves out dynamic mechanisms like convergence. An example of how to add a static route is shown below:
Router_A(config)#ip route 10.1.1.0 255.255.255.0 192.168.1.1
This command defines network 10.1.1.0/24 as reachable through the next-hop router of 192.168.1.1. Not depicted here is the relationship between Router_A and the next-hop router; keep in mind that the next-hop must be reachable without a route if this statement is to be valid. But what about a VRF? This command only puts a static route into the global routing table. To configure a static route within a VRF use the following:
Router_A(config)#ip route vrf VRF_A 10.1.1.0 255.255.255.0 192.168.1.1
This command will add the same static route into the VRF. To verify the entry use the command:
Router_A#show ip route vrf VRF_A
The route entered should be in the VRF routing table and labeled with an "s" for static.
Dynamic routing
Unlike static routing, dynamic routing uses various protocols to automatically distribute routing information between "like" routers. Such protocols include OSPF and RIP. To configure OSPF, a few commands can be used:
Router_A(config)#router ospf 1
Router_A(config-router)#network 192.168.1.0 0.0.0.3 area 0.0.0.0
At a bare minimum, these commands enable OSPF on Router_A's interface which is configured for the network 192.168.1.1. The second command places that particular interface in area 0, the OSPF backbone area. Any OSPF router with the same network command will form an adjacency and routing information will be distributed. To verify any routes learned use the following command:
Router_A#show ip route or Router_A#show ip route ospf
As with static routing, this configuration enables OSPF for routing within the global routing table. What if we wanted to expand our scenario to look like the following?
Using this scenario, both the customers' routers and service provider router must enable OSPF within the VRF. This can be accomplished using the following commands:
Router_A(config)#router ospf 1 vrf VRF_A
Router_A(config-router)#network 192.168.1.0 0.0.0.3 area 0.0.0.0
Router_A(config-router)#capability vrf-lite
Router_B(config)#router ospf 1 vrf VRF_B
Router_B(config-router)#network 172.16.1.0 0.0.3 area 0.0.0.0
Router_B(config-router)#capability vrf-lite
SP_Router(config)#router ospf 1 vrf VRF_A
SP_Router(config-router)#network 192.168.1.0 0.0.0.3 area 0.0.0.0
SP_Router(config-router)#capability vrf-lite
SP_Router(config)#router ospf 2 vrf VRF_B
SP_Router(config-router)#network 172.16.1.0 0.0.0.3 area 0.0.0.0
SP_Router(config-router)#capability vrf-lite
This list of commands will enable OSPF within each VRF for all routers and allow for routing communication to begin. The command capability vrf-lite is needed for the correct population of the VRF routing tables as discussed in the Internet draft "draft-ietf-ospf-2547-dnbit-04.txt." The discussion of this draft is beyond the scope of this article. To verify your adjacencies are formed and routes are being received you can issue the following commands:
SP_Router#show ip ospf neighbor
SP_Router#show ip route vrf VRF_A
SP_Router#show ip route vrf VRF_B
SP_Router#show ip vrf
Once you have the proper routing configurations, you can begin expanding your networks and providing Internet access to your customers.
About the author:
Doug Downer (CCIE #9848 and JNCIS #881) is a senior consultant with AT&T. Doug has over nine years experience in the industry and currently provides high-level business and technology consulting for various federal clients in the Washington D.C. area.
