Inter-VRF-Lite routing

The main purpose of this post is to put forth the global approach of routing with VRF-lite throughout different deployment schemes, combining:

Network translation & address scheme

- Overlapping / non-overlapping customer prefixes

- Traditional NAT / NAT NVI

Deployment models:

- Customer VRFs and common site global routing instance

- Customer VRFs and a common site VRF

Access policy:

- Customers communicate ONLY with common site

- Customer-to-customer communications

Syllabus:

I) Non-overlapping Customer prefixes

• 1) Customer VRFs & Global routing instance
  

• 2) Customer VRFs & Common service VRF
  

                    2a) Customer-to-common service ONLY communication

               2a) Customer-to-Customer communication through HUB site

               2b) direct any-to-any communication

II) Overlapping Customer prefixes

• Customer VRFs & Common service global RIB + Traditional NAT
  

• Customer VRFs & Common service VRF + Dynamic NAT NVI

• Customer VRFs & Common service VRF + Static NAT NVI

All individual labs are mainly based on the below topology:

Picture0: General topology

- Routers “vhost5″ & R5 belong to CustomerA

- Routers “vhost4″ & R4 belong to CustomerB

- Access router R1 deploying VRFs for each customer (locally significant)

- Router “vhost7″ gateway to common services in a site accessible by both customers

Note:

End-hosts “vhost4″, “vhost5″ and “vhost7″ are deployed virtually inside a single physical router with VRF-Lite locally significant (independent from VRF-Lite deployed on R1)

For more detailed information about this technique refer to the post “VRF-Lite as an alternative to VPC“