0

I have this vpn mpls l3 scenario:

enter image description here

Let's say that the host (10.1.1.2) of customer 1 wants to communicate with host (10.1.2.2) of customer 2. My question is: how R2 knows that it has to forward packets to CE1 instead of communicate directly with the host (10.1.2.2) of customer 1? I know that PE uses VRF and CE communicate with PE but what about routers on the middle?

2

Hi an welcome to network engineering!

TL;DR

Customer1's 1.1.1.2 cannot communicate with Customer2's 10.1.2.2, and Customer1's R2 is not supposed to know about Customer2's 10.1.2.x subnet.

Longer:

It appears that both customers use the same addressing for their end subnets (10.1.[1-4].x). That would imply that they are not using the same L3-VPN (sometimes just called "VRF"), else that would be a pretty bad job of network adressing.

However, different customers being in separated VRFs is the actual purpose of L3-VPNs: to keep customers separated. So anyhow, in any case, R2 is not supposed to know a path to Customer2's 10.1.2.2 (which is somewhere beyond CE2 and R4).

Only if somewhere "upstream" in the network (i.e. one one of the PEs), either..

  • routing information were leaked from one customer's VRF into the other's
  • or a link connecting the two VRFs were set up on a PE or a multi-VRF CE, with suitable routing information being disseminated into both customer's VRFs, as in redistribute static or default-information originate)
  • (added later) or - at a suitable place in the MPLS infrastructure - a device (most probably a firewall) is added, which has "legs" into more than one L3-VPN/VRF, and suitable routing information.. (see above). This device will then act as the well-defined gateway between Customer1 and Customer2 (and may perform the required NAT sorcery if addresses of C1 and C2 overlap)

... communication from one VRF to the other might become possible. But then, Customer1 and Customer2 would still not be able to communicate because of the address overlap, unless they were to resort to some dreadful NAT magic.

However, since Customer1's 10.1.2.x subnet is directly attached to Customer1's R2, R2 will always forward traffic towards 10.1.2.x through that interface, whatever routing information from whatever routing protocol is being disseminated into Customer1's VRF/MPLS-VPN and further down into Customer1's own routing domain, where it might be picked up by R2 by some IGP routing protocol such as OSPF, EIGRP or RIPv2. In terms of route preference, nothing - not even a static route - is better than a connected route/a directly attached subnet (yes, we'll keep the can of worms called "PBR" closed for today).

  • ok I think that now it's more clear to me, so we use VRF and route distinguisher to fix the overlap problem, but anyway an host of customer 1 can only communicate with anoter host of the same VPN. So this solution cannot be used in a site-to-site VPN like a company VPN that has to communicate with the VPN (extranet) of its suppliers is it correct? – GJCode Jan 17 at 14:39
  • @GJCode: site-to-site (IPSec-)VPN is quite a different game than L3-VPN on MPLS (althogh you can run a site-to-site IPSec tunnel over a (single) underlaying L3-VPN service just as well as over the open Internet - quite an expensive way to carry IPsec, but definitely possible. – Marc 'netztier' Luethi Jan 17 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.