Two-Customer Isolation on Huawei VPRN: Same IPs, Separate Worlds

In the previous post (Turkish) I built a single-customer VPRN. Here I ask the real question: what happens when two customers use exactly the same IPs? In real networks this is normal. Two companies can both use 172.16.10.0/24 or 10.100.1.1. The provider backbone must carry them without mixing them up.

The answer is RD and RT. They look similar at first, but they do different jobs. This post is about seeing that difference.

Note: the topology extends the lab from the previous post. The Nokia equivalent is in the Nokia VPRN post (Turkish), and there is a short mapping table at the end.

Roles: P, PE and CE

Every router in the lab plays one of three roles. Get these straight first; the packet’s path makes sense after that.

That is why adding a customer never touches the P routers: to them it is just “a labeled packet heading to 1.1.1.1”.

1. The logic: two flats, two customers

Think of an apartment building. Two families (customer A and B) live in two flats, both with “No: 1” on the door. Nobody gets confused, because the buzzer panel at the entrance tells the flats apart.

• VRF (VPN instance): the flat itself. A routing table dedicated to the customer.
• RD (Route Distinguisher): the “flat number” prepended to a route. 65000:100:10.200.2.1/32 and 65000:200:10.200.2.1/32 are two different routes to BGP. RD only provides uniqueness, it does not decide who receives what.
• RT (Route Target): “which flats should this route be delivered to?” The exporting PE stamps the RT on the route, and the importing PE only accepts routes whose RT matches its VRF.

In short: RD prevents collisions, RT controls distribution. The real guard of isolation is RT.

2. Topology and IP plan

The previous lab stays as is (R1 = PE1, R2/R3 = P, R4 = PE2, R5/R6 = customer A). On top of it I add two CEs: R7 and R8, customer B.

Everything is deliberately identical: loopbacks and link blocks. The only difference is which VRF they belong to.

The PEs now use three interfaces (backbone, customer A, customer B). The AR1220 has two GE ports, so use an AR2220 (GE0/0/2) or add an interface module for the third. I wrote GigabitEthernet0/0/2 below; adjust the name if you add a module.

3. Configuration

The backbone (OSPF, LDP) and customer A do not change at all. We only add the new customer.

Step 1: A second VPN instance on the PE

R1 (PE1):

system-view
ip vpn-instance VPRN_B
 ipv4-family
  route-distinguisher 65000:200
  vpn-target 65000:200 both
  quit
 quit
interface GigabitEthernet0/0/2
 ip binding vpn-instance VPRN_B
 ip address 172.16.10.1 24
 quit
ip route-static vpn-instance VPRN_B 10.100.1.1 32 172.16.10.2
return

Note that GigabitEthernet0/0/0 and GigabitEthernet0/0/2 got the same IP (172.16.10.1/24). Normally that would be an address conflict, but the interfaces live in different VRFs, so it is fine. ip binding must still come before the IP, otherwise the binding wipes the address.

R4 (PE2):

system-view
ip vpn-instance VPRN_B
 ipv4-family
  route-distinguisher 65000:200
  vpn-target 65000:200 both
  quit
 quit
interface GigabitEthernet0/0/2
 ip binding vpn-instance VPRN_B
 ip address 172.16.20.1 24
 quit
ip route-static vpn-instance VPRN_B 10.200.2.1 32 172.16.20.2
return

Step 2: Tell BGP about the new VRF

On both PEs (R1 and R4):

system-view
bgp 65000
 ipv4-family vpn-instance VPRN_B
  import-route static
  quit
 quit
return

The VPNv4 session is already up, so no new peer is needed. Each new VRF only needs this block.

Step 3: The CEs

R7 (CE3) and R8 (CE4) are plain routers. R7:

system-view
sysname R7
interface GigabitEthernet0/0/0
 ip address 172.16.10.2 24
 quit
interface LoopBack1
 ip address 10.100.1.1 32
 quit
ip route-static 0.0.0.0 0 172.16.10.1
return

R8 is the same idea: interface 172.16.20.2/24, loopback 10.200.2.1/32, default route 172.16.20.1.

4. Verification

Same prefix, two separate routes

On PE2, look at the BGP VPNv4 table:

<R4>display bgp vpnv4 all routing-table

Expected: you should see two separate blocks for 10.100.1.1/32. One under Route Distinguisher: 65000:100, the other under Route Distinguisher: 65000:200. Same prefix, different RD, so BGP carries them as two distinct routes. That is exactly what RD is for.

Each VRF sees its own table

<R4>display ip routing-table vpn-instance VPRN_SERVICE
<R4>display ip routing-table vpn-instance VPRN_B

Both should show 10.100.1.1/32 as IBGP with next hop 1.1.1.1. Same prefix, same next hop, two separate tables. They are unaware of each other.

End-to-end ping

<R5>ping -a 10.100.1.1 10.200.2.1
<R7>ping -a 10.100.1.1 10.200.2.1

Both should get replies. But how do we know each ping reached the right customer? The addresses are identical, so the ping alone cannot tell.

Isolation proof: shut one down

Shut down R8’s loopback:

<R8>system-view
[R8]interface LoopBack1
[R8-LoopBack1]shutdown

Then try again:

<R7>ping -a 10.100.1.1 10.200.2.1     (should no longer get a reply)
<R5>ping -a 10.100.1.1 10.200.2.1     (should still reply)

Customer B’s target is down, customer A’s target is still up. If R5’s ping is unaffected by B going down, A’s traffic never leaks into B. This is the clearest proof that the same address leads to two different places. Don’t forget undo shutdown afterwards.

5. Deliberate failure experiments

Isolation depends on RT. Breaking it on purpose is a good way to make the logic stick.

Experiment 1: Wrong import RT

On R4, change VPRN_B’s import RT:

system-view
ip vpn-instance VPRN_B
 ipv4-family
  undo vpn-target 65000:200 import-extcommunity
  vpn-target 65000:300 import-extcommunity

Expected: PE2’s VRF B no longer imports the 10.100.1.1/32 route from PE1 (RT mismatch). Result: a packet from R7 to R8 reaches the target but has no return path, because R4’s VRF B table has no 10.100.1.1. The ping fails. Customer A is unaffected.

Lesson: the route exists in BGP but never entered the VRF. When troubleshooting, “I see it in BGP but not in the VRF” usually means an RT mismatch. Check: is the route in display bgp vpnv4 all routing-table but missing from display ip routing-table vpn-instance VPRN_B?

When done, restore the RT: undo vpn-target 65000:300 import-extcommunity and vpn-target 65000:200 import-extcommunity.

Experiment 2: The same RT for both customers

Now the dangerous one. Set VPRN_B’s RT to the same as A’s (vpn-target 65000:100 both on both PEs, removing the old one with undo). Keep the RD different (65000:200).

Expected: because the RD differs, BGP keeps the routes separate, but because the RT is the same, each VRF imports the other’s routes. A VRF now has two candidate routes for the same prefix, and BGP picks one by best path. So customer A’s traffic may end up at customer B’s CE.

Result: isolation is broken, with no error message. Even ping may work, which makes this the sneakiest mistake. Only do this in a lab; giving two customers the same RT in a real network is a serious data leak.

In both experiments, look at the output yourself: which route wins depends on tie-breaking and may differ in your lab.

Note: The outcomes of these two experiments are expectations derived from the logic; in Experiment 2 which route wins depends on the tie-break. Check the output on your own lab.

6. A packet’s journey: where do the labels change?

The story of a packet from R5 (customer A) to R6, left to right:

1. CE → PE (R5 → R1): A plain IP packet, no label. R1 looks at the VRF (VPRN_SERVICE) bound to the incoming interface.
2. PE ingress (R1): The VRF lookup gives next-hop 4.4.4.4 (R4). R1 pushes two labels: inner is the service (VPN) label advertised by R4 for this VRF, outer is the transport (LDP) label for the path to R4.
3. P routers (R2, R3): They look only at the outer label. R2 SWAPs it. The penultimate router (R3) POPs the outer label (PHP, penultimate hop popping). They never touch the inner service label.
4. PE egress (R4): Only the service label is left. R4 uses it to decide which VRF the packet belongs to, drops the label and forwards to the right customer (VPRN_SERVICE or VPRN_B).
5. PE → CE (R4 → R6): Plain IP again.

Because customers A and B use identical addresses, the service label is the only thing telling their packets apart. Same destination IP, two different inner labels, two different VRFs.

Seeing it with your own eyes

Instead of only reading label changes from command output, I built a browser Simulation page (UI currently in Turkish). Open Yeni (New) → Huawei → “MPLS L3VPN: 2 müşteri izolasyonu (VPRN)” (topology only, or with the full configuration). Then:

• ping from one CE to another; the packet moves over the cables and the PUSH / SWAP / POP labels show at every hop.
• Use the step-by-step mode to pause at each hop and read the label stack.
• Turn on both the VPRN and MPLS layers at once from the layer tabs.
• shutdown an interface and watch isolation hold.

Note: label numbers in the simulator are illustrative; a real device’s LDP hands out different values. The logic (PUSH/SWAP/POP, two-level stack) matches the real thing.

7. Comparison with Nokia

On Nokia, a second customer means a new customer and a new vprn:

On Nokia each customer is separated by its own vprn block and service ID; on Huawei by the VPN instance name. The logic is the same: one customer = one VRF = one RD = one RT pair.

8. Summary

• Two customers using the same IPs live happily on one backbone because each has its own VRF.
• RD makes a route unique in BGP (same prefix, two routes). RT decides which VRF a route enters.
• Adding a customer: a new VPN instance on the PE, bind the interface with ip binding (before the IP), and an ipv4-family vpn-instance block in BGP. No changes to the P routers or the VPNv4 session.
• The clearest isolation test: shut down one customer’s target and see that the other’s ping is unaffected.
• The sneakiest mistake is a wrong RT: either the route never enters the VRF (Experiment 1), or two customers see each other’s routes (Experiment 2).