New VPRN Site: AFI/SAFI, Route Targets and a Policy Nobody Read
AS 64500 runs VPRN 100 for a retail customer. PE-A (site 1) and PE-B (site 2) are in service and exchange VPN-IPv4 routes through the RR pair; both sites reach each other. PE-C is added for site 3, with VPRN 100 configured as vrf-target target:64500:100 plus an explicit vrf-export policy that stamps community target:64500:100. PE-C's iBGP session to RR-1 is Established with only the ipv4 family enabled, carrying PE-C's system address.
After cutover, 10.99.0.0/16 (site 3) is in PE-C's VPRN 100 route table and in PE-C's BGP RIB, but no other PE has it. show router bgp routes vpn-ipv4 on RR-1 lists nothing from PE-C. PE-A and PE-B are unaffected.
The family is later corrected. 10.99.0.0/16 then appears in PE-A's BGP RIB as a vpn-ipv4 route with the expected route targets, but it never appears in PE-A's VPRN 100 route table.
The account team wants the route reflectors replaced. Later, PE-C must also add an EVPN VPLS (EVI 200) for the same customer.
1. Diagnose the first failure. Why does enabling only the ipv4 family make VPRN 100 look healthy on PE-C while advertising nothing to the rest of the network?
Read the worked answer
The ipv4 family carries plain IPv4 unicast - the global table. VPRN 100 is carried by VPN-IPv4 (AFI 1, SAFI 128), a completely separate address family on a separate RIB. A session can be Established and healthy while negotiating only the unicast family, and nothing in the session state or in the VPRN configuration flags that the service has no transport. The service is locally complete: the CE adjacency is up, the prefix is in the VRF table, and the PE has exported it into the VPN-IPv4 RIB. It simply has no peer to send it to.
This also explains the clean PE-A / PE-B behaviour: their sessions negotiate VPN-IPv4 correctly, so sites 1 and 2 are unaffected. The failure is exactly one missing capability between PE-C and the RR.
Diagnostically, the ordering is instructive. First check the session's negotiated families (show router bgp neighbor <ip> and the capabilities/detail output) rather than the VPRN config - the most common instinct is to look at route targets, which is the wrong layer here. Then check the RR's view: show router bgp routes vpn-ipv4 listing nothing from PE-C confirms the advertisement was never made, as opposed to made and rejected. If the routes had arrived at the RR and been dropped, you would see them (or their absence) for a policy reason, and the fix would be in the RR's import/export policy rather than in the family negotiation.
The fix is to enable the VPN-IPv4 family on both sides - the negotiation is mutual, so enabling it on PE-C alone is not enough - and then to audit every other PE/RR session in the AS for the same gap.
2. After the fix, 10.99.0.0/16 is in PE-A's BGP RIB with the expected route targets but not in PE-A's VPRN 100 route table. Where do you look, and what is the most likely cause?
Read the worked answer
If the route is in PE-A's BGP RIB but not in the VRF, the transport worked. The route reached PE-A, and the remaining question is why the VRF did not accept it. That is route-target import, evaluated at the VRF boundary, and it is evaluated against the RTs carried in the route together with any vrf-import policy.
The most likely cause is a vrf-import policy on PE-A that matches on more than the route target - typically a prefix list, a community list or a protocol match - and whose prefix list does not include 10.99.0.0/16. This is a common hardening pattern: someone wanted to prevent the VRF importing another site's prefixes, wrote a policy that matched the RT and the known site prefixes, and forgot that a new site introduces a new prefix. Site 1 and site 2 keep working, which is why nothing looked wrong.
Procedure: dump the route's communities and extended communities on PE-A, confirm the RT is 64500:100 as expected. Then look at the VRF's import side - both the vrf-target and any vrf-import policy attached to the VPRN - and read the policy entry by entry. In SR OS, show router 100 route-table plus the policy match counters is faster than guessing; a policy entry with a zero hit count while the route is present in BGP is the tell.
Second candidate, less likely but worth eliminating: an export policy on PE-C that overwrites the RT. A vrf-export policy can stamp communities that override or supplement what vrf-target would generate, and if PE-C's policy adds a second RT without removing the first, the route may reach PE-A but not match. The described symptom (expected RTs present) argues against this, but verify rather than assume.
Do not accept the suggestion to replace the route reflectors: the route is on PE-A with the right RTs. The reflectors did their job.
3. PE-C must now add an EVPN VPLS (EVI 200) for the same customer. What has to be enabled on the PE-C/RR session and on the reflectors, and which EVPN route types will the service actually use?
Read the worked answer
EVPN is a separate AFI/SAFI (AFI 25, SAFI 70) and will not ride on the VPN-IPv4 or ipv4 families. The family must be negotiated on every session in the path - PE-C to RR-1, the RRs to each other, and the RRs to every PE that will host the VPLS. On the RRs this means the family must be enabled on the peer group, not only on individual neighbors, or the next PE added to the group will silently lack it. Enabling it on PE-C alone reproduces exactly the first failure in this case study with a different family.
On the service side, the VPLS needs a bgp-evpn context with an EVI (200 here) and a route target - typically auto-derived from the EVI as target:64500:200 unless a policy overrides it - and an EVPN tunnel/next hop that resolves, which means the MPLS transport to the remote PEs must already work.
Route types to expect:
- Type 2 (MAC/IP advertisement) for customer MAC learning, and for IP-to-MAC binding where proxy-ARP/ND or a routed service is in play. This is the bulk of the operational traffic.
- Type 3 (Inclusive Multicast Ethernet Tag) to build the flood list for BUM traffic - without it, broadcast and unknown unicast have nowhere to go.
- Type 1 (Ethernet Auto-Discovery) and type 4 (Ethernet Segment) only if the customer wants multi-homing to PE-C and another PE. If all-active or single-active multi-homing is required, these must be designed at the same time; retrofitting them later changes the forwarding model.
- Type 5 (IP Prefix) only for a routed EVPN service, not for a plain VPLS.
Treat the VPLS as a new service, not an extension of VPRN 100: separate family, separate RT space, separate tunnel requirement. Test with show router bgp routes evpn on the RR and on both PEs before commissioning.