VRF Lite Configuration on Cisco IOS

Hello Jenny

Take a look at this post:

If you have any further questions, please feel free to elaborate!

I hope this has been helpful!

Laz

1 Like

Thank you Laz, you are one of the few people who had explained, how we can use the keyword “match-in-vrf”, and you had explained extremely well ! thank you :smiley:

Looking at the syntax format, I think the keyword “pool natpool1”, was an option of “match-in-vrf”;

Now, if Cisco said , for the ip nat Inside Source Statement, we could put to use, two keywords , ie “match-in-vrf” and “pool natpool1”;

Then my question was, could there be a big difference in the functionality between match-in-vrf pool natpool1 Vs. pool natpool1 match-in-vrf. ( ie should we put the keyword “pool natpool1” before “match-in-vrf” , or after ? )

For example, If we use pool natpool1 match-in-vrf, I think, this means ALL of the IG addresses can be re-used ( overlapped) by other VRFs, in their Ip Nat Inside Source Statements;

As oppose to match-in-vrf pool natpool1, which means that not all of the IG addresses can be re-used ( overlapped) by other VRFs , when you wanted to do intra-vrf nat mapping ; I think, only a portion of the IG addresses that correspond to the pool range , can be re-used.

Hope my elaboration was clear ? Thanking you warmly !

G’day from Australia and Best Regards
jw

Hello Jenny

Looking deeper into this topic and with the help of @ReneMolenaar, I can give you some more information.

On IOSv as well as on regular IOS XE versions, the match-in-vrf parameter is only possible as an option of the vrf parameter. In other words, in these versions I was unable to reproduce the command in these IOS versions. For example:

In IOSv:

R1(config)#ip nat inside source list global-list pool natpool1 vrf 1 match-in-vrf ?
  no-payload  No translation of embedded address/port in the payload
  overload    Overload an address translation
  <cr>        <cr>

In regular IOS XE:

R1(config)#ip nat inside source static 192.168.11.10 10.11.11.10 vrf 1 match-in-vrf ?
  extendable  Extend this translation when used
  mapping-id  Associate a mapping id to this mapping
  no-alias    Do not create an alias for the global address
  no-payload  No translation of embedded address/port in the payload
  <cr>        <cr>

The syntax that you are proposing is only found within IOS XE SD-WAN image where it is possible to place the pool after the match-in-vrf keyword. That’s a feature that seems to have been added since Cisco IOS XE Release 17.5.1a, which is a release from March of 2021.

Even so, after doing some testing on IOS XE Software, Version 17.05.01a the “pool” parameter is only an option for “vrf X match-in-vrf”. You can’t do something like “pool vrf” or “pool match-in-vrf” or anything like that.

I hope this has been helpful!

Laz

1 Like

I enjoyed learning awesome knowledge from your forum !! very impress with you and Rene !!

1 Like

Hi Rene,

what actually the advantage of VRF and can u pls tell a user case scenario where it scores over global routing table

Hello Ananth

VRFs allow you to create multiple routing instances within a specific router. The implementation of VRFs is useful in a multi-tenant situation, where you may be serving multiple customers using the same physical network infrastructure. Specifically, VRFs are used to keep customer traffic and routing separate, but using the same physical hardware.

VRFs are implemented in the following situations:

  • Datacenters in a colocation arrangement where multiple “tenants” have a presence and require a logically separate routing fabric
  • MPLS VPN uses VRFs extensively to achieve its operation
  • Corporate buildings with multiple tenants can employ VRFs in their hardware to accommodate multiple corporate entities each with their own virtually separate and independent routing domain.

I hope this has been helpful!

Laz

I understand that VRF would help in keeping the routes of each customer separated on the ISP router. But why do we need to separate it? What is the problem if the global routing table on ISP router contains all the customer route information?

Using the route-tag can we not make sure which routes are advertised to which customer?a

Hello Darshan

There are a couple of reasons why we would like to separate different customer subnets into VRFs. The first is that many customers will use the same IP address spaces, such as 192.168.1.0/24 for example. Any overlapping address spaces would not be able to be accommodated otherwise.

Additionally, the use of VRFs elegantly separates customer routing domains. This makes it much more scalable for an ISP to deliver connectivity to dozens, hundreds, or even thousands of customers. Imagine having 500 customers, each with an average of 10 remote sites. You can imagine how difficult it would be to maintain a global routing table within the ISP network to accommodate so many different networks. With VRFs, it is easier to keep track of each individual customer and to keep such customer traffic separate and distinct no matter how many customers an ISP serves.

I hope this has been helpful!

Laz

Thanks for your response, Lazaros.

Got it clearly about the primary purpose.

Regrading the second purpose, I have few doubts.
Do you mean to say the routing data would be stored and represented elegantly so that troubleshooting would be easy?

Furthermore, when you say “routing domain”, can you please explain about it a bit more?
Also, when you say - “keep suck customer traffic separate and distinct”, what traffic are you talking about? Control plane traffic? Doesn’t the customer traffic are seperated only the PE routers and it gets mixed again in the intermediate routes (P routers) in MPLS L3 VPN deployements?

Hello Darshan

The concept that I was trying to express in my previous post is similar to what is stated in the lesson itself: “VRFs are like VLANs for routers.” This means that instead of using a single global routing table, you can divide a network into VRFs, where each VRF has its own routing table. In my post, I called the whole VRF/routing table entity a “routing domain”. It’s not standard terminology, but I used it to refer to each VRF and its corresponding routing table. Now does this help in troubleshooting? Well, maybe, but this is not is purpose. It is the functionality it introduces that is important for VRFs.

Yes, I see that my explanation was confusing. VRFs help to keep the routing processes of each customer separate and distinct, and this is necessary especially if the same address space is being used for multiple sites. VRFs don’t keep customer traffic separate and distinct like VPNs do, but it does keep the routing processes separate so that traffic from specific customers is routed by the correct VRF.

Now keep in mind that this particular lesson does not include MPLS functionality. It only demonstrates the operation of VRFs, but when applied in an environment where MPLS is used, then yes, it is MPLS L3 VPN and the associated labels that keep customer traffic distinct.

I hope this has been helpful!

Laz

Hi all, we have a firewall at home that supports bgp and vrf, I tried to set up BGP via IPSec, I wanted to ask if it is possible to use vrf between the 2 remote offices, do we still need to activate MPLS on the IPsec interface? Can you give me a tip if it possible? thank you

Hello Valerio

I’m not quite clear as to what you want to achieve. Do you want to connect your firewall at your home office with your business office, and do you want to use BGP to route between the two over IPSec while using VRFs? I understand the technologies you want to use, but can you give us a clearer picture of what you want to achieve? It will help us to help you better.

Thanks, and looking forward to hearing from you!

Laz

Thanks for the request, what you say is correct, we have 2 offices where we have a network overlap problem, at the business office I would like to put an interface inside a vrf
and make it communicate with home office through bgp session via ipsec. Do I also have to create the same vrf on the home office side and apply it on a specific interface, is that correct?

Hello Valerio

The use of VRFs is a solution to this problem as it will allow you to have overlapping address spaces in both locations. Now where you will apply the VRFs depends upon your implementation.

If you take a look at this lesson on VRF Lite Configuration on Cisco IOS, you will see that the VRFs are only configured on one router. This one router performs the translation between one VRF to another.

Now in your scenario, I assume you’re not using MPLS, and even if you were, the MPLS infrastructure would not be under your control, but the ISP’s. So, to achieve what you need using VRFs, I would suggest you configure the VRFs on the office router, and create an IPSec tunnel/VPN to your home office. You can then use whatever routing protocol you like to enable routing in the topology, or even static routing if the topology is relatively simple.

In such a scenario, you would only need to configure VRFs on the office router, and not the firewall at your home.

Another solution to resolving overlapping address spaces is to use NAT. NAT may be a simpler solution. You can apply it to your local firewall to keep all addresses unique.

I hope this has been helpful!

Laz

@lagapidis Great, thank you for the good explanation.

Regards,

Valerio

1 Like

I was configuring some VRF lite and I had two VRFs that I was configuring on 4 Routers in my isp. I was trying to figure out how the other side would know how to separate traffic from the different VRFs. At first I thought well maybe if the other side gets traffic from a VRF it would know. Now that I think of it there would be nothing in the Ethernet/IP header to tell the router anything. The answer is 802.1q which is not obvious because when you think of routers you don’t think of 802.1q unless there is a switch on the other side(router on a stick). To be explicit, you 802.1q encapsulate traffic on sub interfaces on the neighboring routers to transport traffic in different vrfs between routers if you are only using one interface. Networking is awesome :smiley:

image

R1
interface GigabitEthernet0/2.1
 encapsulation dot1Q 10
 ip vrf forwarding Gandalf
 ip address 192.168.2.1 255.255.255.0
end

R2
interface GigabitEthernet0/0.1
 encapsulation dot1Q 10
 ip vrf forwarding Gandalf
 ip address 192.168.2.2 255.255.255.0
end

Hello Justin

Thanks so much for sharing your experience with us! And yes, networking is awesome!! :sunglasses:

When sharing VRFs across multiple routers, using 802.1q trunks to extend that VRF information is definitely a good way to do that. You can also use GRE tunnels or MPLS tags to extend and tie the VRFs together as well.

Thanks once again for sharing!

Laz

What if I wish to use VRFs on Nexus and IOS-XE to handle a seperate multicast type such as SSM? Do I need to configure the VRF with the address-family ipv4 multicast syntax?

Hello Chad

Take a look at this response:

I hope this has been helpful!

Laz

Thanks Laz, I appreciate the response!

1 Like