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

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

               2c) 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”