Tip

VRFs and routing

Doug Downer continues his series about VPN routing and forwarding instances focused on the task of configuring and verifying a VRF scenario with a requirement for separate customers on a shared device. In this tip, he shows how to configure a method for communication between each customer outside of the shared interfaces and how to ensure that all customer routes are being advertised correctly.

 

The last tip in this series about VPN routing and forwarding instances focused on the task of configuring and verifying a VRF scenario in which the requirement was to separate customers on a shared device. In that article, I did not define a method for communication between each customer outside of the shared interfaces such as static routes or dynamic routing protocols. This week I will show you how to configure this communication and ensure that all customer routes are being advertised correctly.

Scenario recap

Recall from my last few articles the small service provider scenario. A shared device, acting as the edge of a provider network (PE) connects two customers (A & B) to provide for Internet access. Each customer must be kept separate and each customer must have the ability to advertise subnets behind their individual routers (CEs). Last week I showed how to configure two VPN routing and forwarding instances (VRFs), named Customer_A and Customer_B and assign the individual interfaces to each VRF.

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:

More on this topic

Configuring a VRF

Keeping it all separate with VRFs

Crash Course: Routers

Crash Course: VPNs

More VPN tips

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.

 


Doug Downer (CCIE #9848 and JNCIS #881) is a Sr. Consultant with Callisma, Inc., a wholly owned subsidiary of SBC Communications. Doug has over seven years' experience in the industry and currently provides high-level business and technology consulting for various federal clients in the Washington D.C. area.

Dig Deeper on WAN technologies and services

Unified Communications
Mobile Computing
Data Center
ITChannel
Close