Hello Aniket
First of all, it is important here to clarify what kind of scenario we are talking about when we speak about VRFs. This is described as follows in Cisco documentation:
Virtual Private Networks (VPNs) provide a secure way for customers to share bandwidth over an ISP backbone network. A VPN is a collection of sites sharing a common routing table. A customer site is connected to the service provider network by one or more interfaces, and the service provider associates each interface with a VPN routing table. A VPN routing table is called a VPN routing/forwarding (VRF) table.
When you have multiple VRFs, there is the possibility of having the same address space connected to multiple VPNs of a router. So you may have the 10.10.10.1 address exist in one network, which is routed using the routing table of VRF1, and you may have the same address in another network, which is also routed by this router, but in VRF2. That’s fine and it should work well.
But what if you want this same router to perform NAT on these particular IP addresses? They are both the same, so if you simply use the following command:
ip nat inside source static 10.10.10.1 172.16.131.1
…then both hosts with this IP address will be translated to the same outside address. This however will not work.
You can enable VRF awareness onNAT by adding the VRF to which each translation should be mapped. This way, internally identical IP addresses on different VRFs, when NATted, will obtain unique global addresses.
But, what happens when you want these two hosts connected to two different VPNs, with identical IP addresses, to communicate directly with each other? Or to communicate with a subnet on another VPN that may have the same IP address range? This is where the match-in-vrf keyword comes in. It extends the VRF awareness of NAT such that inter-VPN communication can take place. In other words, communication from one VPN to another VPN on the same router can take place, using NAT.
What the keyword does specifically is, for inter-VPN traffic, it allows the translation of 10.10.10.1 to the required address in the other VPN while keeping track of which VRF it originally came from. Otherwise, inter VPN communication would not function, because 10.10.10.1 belongs to multiple VPNs.
I hope this has been helpful!
Laz