How Can a Route Reflector Reflect L3VPN Routes Without a Local VRF?

BGPCiscoIOS XEIOS XRMPLS L3VPN

Marco Basso·September 1, 2026·11 min read

Introduction

This post is based on Cisco IOL running IOS XE 17.16.01a and Cisco IOS XRv 9000 running IOS XR 26.1.1.

The design and operation of MPLS L3VPN services are familiar to network engineers responsible for medium- and large-scale enterprise infrastructure. A closer look at their foundations and at the role of PE routers naturally leads to two key components: route distinguishers (RDs) and route targets (RTs). While RDs are prepended to IPv4 prefixes to form unique VPNv4 NLRI across different VRFs, RTs determine which MP-BGP routes can be imported into a specific VRF.

Another fundamental component, though not strictly required, is the route reflector, which is widely used in MPLS L3VPN designs. Because it operates exclusively within the provider backbone and has no customer-facing interfaces, it does not need to be aware of every customer context or have local VRFs configured.

With these elements in place, the central question of this post can now be presented. On Cisco platforms, a BGP UPDATE message is normally discarded when no local VRF has an import policy that matches its RT (SPOILER 🙂). How, then, can a route reflector with neither a local VRF nor an import policy still reflect VPN routes to both its clients and non-client peers?

The answer lies in the distinction between route reflection and local VRF import. A route reflector does not need to import a route into a local VRF RIB to re-advertise it to its clients. The following sections examine this behavior in detail.

What Are Route Targets?

Before digging into the post, let us briefly recap what route targets are. In an MPLS L3VPN service, PE routers use VRFs to maintain separate routing contexts for different customers. Each VRF has its own routing table, allowing multiple customers to use overlapping IP address spaces while keeping their routing information isolated.

Customer routes learned by a PE are exported into the MP-BGP VPNv4 address family and propagated across the provider backbone. When advertising a VPNv4 route, the PE attaches one or more RT extended communities whose values determine which remote VRFs may import it.

Each RT is carried as an 8-byte BGP Extended Community attribute and can be represented in two main formats:

ASN:GenericNumber
IPAddress:GenericNumber

The ASN:GenericNumber format combines a 2-byte Autonomous System Number (ASN) with a 4-byte Generic Number, while the IPAddress:GenericNumber format combines a 4-byte IPv4 address with a 2-byte Generic Number. The choice depends on the addressing and ASN scheme used in the provider network.

There is also an additional format that allows 4-byte ASNs to be used.

On the receiving PE, the extended communities attached to VPNv4 routes are compared with the import values configured on local VRFs. A route is imported when at least one value matches.

By configuring distinct import and export values, service providers control which VRFs exchange routes and, consequently, which customer sites can communicate. This makes RTs a key control-plane mechanism for distributing VPN routes across the MPLS backbone without requiring direct routing adjacency between customer sites.

What Happens When an Export RT Policy Is Not Configured on IOS XR?

Before examining how route reflectors behave without a local VRF, it is worthwhile to briefly explore the assumption that RT configuration is mandatory in L3VPN deployments. To test this premise, Daniel Dib published an insightful post on his blog. The following scenario extends Daniel's work with modifications to the topology:

Three PE routers (PE-A-1, PE-A-2, PE-B-1) and one route reflector (RR) are deployed, with each PE configured as a VPNv4 Unicast route reflector client of RR over an MP-iBGP session
PE-B-1 originates 2.2.2.2/32 from VRF TEST
PE-A-1 and PE-B-1 run IOS XR, while PE-A-2 and RR run IOS XE

The topology includes PE-A-1 (10.150.1.1), PE-A-2 (10.150.1.2), PE-B-1 (10.150.2.1) and RR (10.60.0.1). PE-B-1 is configured with VRF TEST and a Loopback999 interface assigned to that VRF, which is used to originate the 2.2.2.2/32 prefix. The following output shows the VRF configuration on PE-B-1.

1RP/0/RP0/CPU0:PE-B-1#show running-config
2Fri Aug 28 18:36:37.442 UTC
3[OUTPUT OMITTED]
4!
5interface Loopback999
6 vrf TEST
7 ipv4 address 2.2.2.2 255.255.255.255
8!
9vrf TEST
10 address-family ipv4 unicast
11 !
12!
13[OUTPUT OMITTED]

As shown, neither a local import policy nor an export policy is configured. The following configuration from PE-B-1 shows the advertisement of 2.2.2.2/32 from VRF TEST.

1RP/0/RP0/CPU0:PE-B-1#show running-config router bgp   
2Fri Aug 28 18:38:55.921 UTC
3router bgp 65100
4 [OUTPUT OMITTED]
5 !
6 vrf TEST
7  rd 65100:999
8  address-family ipv4 unicast
9   network 2.2.2.2/32
10  !
11 !
12 [OUTPUT OMITTED]

PE-A-1 and PE-A-2 are configured with the same VRF TEST, including an import policy for routes carrying RT 65100:999.

The following output verifies that the route is valid and advertised by PE-B-1 through the MP-iBGP session to RR.

1RP/0/RP0/CPU0:PE-B-1#show bgp vpnv4 unicast rd 65100:999 2.2.2.2/32
2Fri Aug 28 18:41:21.583 UTC
3BGP routing table entry for 2.2.2.2/32, Route Distinguisher: 65100:999
4Versions:
5  Process           bRIB/RIB   SendTblVer
6  Speaker               1063         1063
7    Local Label: 24010
8Last Modified: Aug 28 18:35:19.023 for 00:06:02
9Paths: (1 available, best #1)
10  Advertised to peers (in unique update groups):
11    10.60.0.1       
12  Path #1: Received by speaker 0
13  Advertised to peers (in unique update groups):
14    10.60.0.1       
15  Local
16    0.0.0.0 from 0.0.0.0 (10.150.2.1)
17      Origin IGP, metric 0, localpref 100, weight 32768, valid, local, best, group-best, import-candidate
18      Received Path ID 0, Local Path ID 1, version 1063

As in Daniel's test with IOS XE, the route is injected into the VPNv4 Unicast address family and advertised to the route reflector without an RT extended community. The following capture confirms that the first UPDATE message containing the relevant prefix does not include any extended community attributes.

BGP_Update_Message.pcap

LIVE

Filter:

tcp.port == 179 && ip.addr == 10.60.0.1

✓ Applied

No.

Time

Source

Destination

Protocol

Length

Info

Select a packet to inspect protocol layers

1 packets displayed

BGP · TCP/179 · 10.60.0.1 ↔ 10.150.1.1

The behavior of the receiving PEs is examined next. After the route reflector reflects the BGP UPDATE message, it reaches PE-A-1 with the debug bgp update 10.60.0.1 afi vpnv4 unicast in command enabled.

1RP/0/RP0/CPU0:Aug 28 19:00:39.421 UTC: bgp[1089]: [default-rtr] (vpn4u): nexthop 10.150.2.1/32, origin i, localpref 100, metric 0, originator 10.150.2.1, clusterlist 1.0.60.10
2RP/0/RP0/CPU0:Aug 28 19:00:39.421 UTC: bgp[1089]: [default-rtr] (vpn4u): Received prefix 2ASN:65100:999:2.2.2.2/32 (path ID: none) with MPLS label 24010  from neighbor 10.60.0.1
3RP/0/RP0/CPU0:Aug 28 19:00:39.421 UTC: bgp[1089]: [default-rtr] (vpn4u): Prefix 2ASN:65100:999:2.2.2.2/32 (path ID: none) received from 10.60.0.1 DENIED RT extended community is not imported locally
4RP/0/RP0/CPU0:Aug 28 19:00:39.421 UTC: bgp[1089]: [default-rtr]: Received UPDATE from 10.60.0.1 (length incl. header = 94)

The debug output confirms that PE-A-1 rejects the BGP UPDATE because it does not carry an RT extended community.

1RP/0/RP0/CPU0:PE-A-1#show bgp vpnv4 unicast rd 65100:999
2Fri Aug 28 19:05:39.373 UTC
3RP/0/RP0/CPU0:PE-A-1#

PE-A-2 exhibits the same behavior. The debug bgp vpnv4 unicast updates 10.60.0.1 in command output confirms that the route is not accepted.

1*Aug 28 19:08:57.941: BGP(4): 10.60.0.1 rcvd UPDATE w/ attr: nexthop 10.150.2.1, origin i, localpref 100, metric 0, originator 10.150.2.1, clusterlist 10.60.0.1
2*Aug 28 19:08:57.941: BGP(4): 10.60.0.1 rcvd 65100:999:2.2.2.2/32, label 24010 (0x5DCA) -- DENIED due to:  extended community not supported;

The behavior observed in Daniel's IOS XE test mirrors what occurs with PE-B-1 running IOS XR: the route advertisement without an RT is propagated through the MP-iBGP session to the route reflector but is rejected by both PE-A-1 and PE-A-2. This scenario will be revisited later to examine the key difference between the two platforms. The focus now shifts to the main topic of this post: understanding how the default RT filtering mechanism operates.

Default VPNv4 Unicast Route Target Behavior on a Route Reflector

In general, a peer without a VRF configured with local RT import policies discards received route advertisements through a default filtering mechanism. In Cisco implementations on both IOS XE and IOS XR, this behavior changes when a router is configured as a route reflector with VPNv4 Unicast peers designated as route reflector clients. Routes received through MP-iBGP sessions are reflected even when the route reflector has no locally configured VRF.

To demonstrate this behavior, the same topology introduced earlier is used. An export RT policy is applied to the 2.2.2.2/32 route originated by PE-B-1, using RT 65100:999.

1RP/0/RP0/CPU0:PE-B-1#show running-config vrf TEST
2Fri Aug 28 19:15:44.419 UTC
3vrf TEST
4 address-family ipv4 unicast
5  export route-target
6   65100:999
7  !
8 !
9!

The following output shows that RR retains the route in its VPNv4 Unicast RIB table without requiring any additional configuration.

1RR#show bgp vpnv4 unicast rd 65100:999
2BGP table version is 156, local router ID is 10.60.0.1
3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
4              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
5              x best-external, a additional-path, c RIB-compressed, 
6              t secondary path, L long-lived-stale,
7Origin codes: i - IGP, e - EGP, ? - incomplete
8RPKI validation codes: V valid, I invalid, N Not found
9
10     Network          Next Hop            Metric LocPrf Weight Path
11Route Distinguisher: 65100:999
12 *>i  2.2.2.2/32       10.150.2.1               0    100      0 i

This behavior confirms the expected outcome. To examine the filtering mechanism in a broader context, PE-A-1 and PE-A-2 are now considered, where neither router acts as a route reflector.

RT Filter Mechanism

As shown at the beginning, PE-A-1 and PE-A-2 are not route reflectors and therefore do not benefit from the specific behavior and capabilities associated with RR nodes. As a result, the RT-based filtering mechanism is active, unlike in the scenario described in the previous section.

Consider, for example, an Inter-AS L3VPN Option B deployment, where the PEs at the boundary of two Autonomous Systems, known as PE-ASBRs, establish an MP-eBGP session between them. If a PE-ASBR does not retain a received VPNv4 route because none of its local import policies matches the route’s RT, the route cannot be re-advertised to the remote AS.

To ensure that such routes can be retained and propagated across the AS boundary, the RT-based filtering mechanism must therefore be disabled. This raises the question of whether the default RT filtering can also be disabled on a node that is not a route reflector. The Inter-AS MPLS Option B scenario provides clear evidence that the answer is yes.

The following sections show how this default filtering can be disabled both on IOS XE and IOS XR. First, the import configuration entries are removed from PE-A-1 and PE-A-2. This allows verification of whether the routes are discarded without specific import policies and how the VPNv4 Unicast RIB behaves after the new commands are applied.

1RP/0/RP0/CPU0:PE-A-1#show running-config vrf TEST
2Fri Aug 28 19:24:45.517 UTC
3vrf TEST
4 rd 65100:999
5 address-family ipv4 unicast
6 !
7!

1PE-A-2#show running-config | section vrf
2vrf definition TEST
3 rd 65100:999
4 !
5!
6[OUTPUT OMITTED]

An export RT must then be applied to the BGP update originated from the TEST VRF on PE-B-1. In this example, the configured RT is 65100:999.

1RP/0/RP0/CPU0:PE-B-1#show running-config vrf TEST
2Fri Aug 28 19:32:44.419 UTC
3vrf TEST
4 address-family ipv4 unicast
5  export route-target
6   65100:999
7  !
8 !
9!

Using the same command employed earlier, the RT 65100:999 extended community is visible in the route advertisement, as shown in the last line of the output from PE-B-1.

1RP/0/RP0/CPU0:PE-B-1#show bgp vpnv4 unicast rd 65100:999 2.2.2.2/32
2Fri Aug 28 19:35:41.200 UTC
3BGP routing table entry for 2.2.2.2/32, Route Distinguisher: 65100:999
4Versions:
5  Process           bRIB/RIB   SendTblVer
6  Speaker               1309         1309
7    Local Label: 24010
8Last Modified: Aug 28 19:31:37.023 for 00:04:04
9Paths: (1 available, best #1)
10  Advertised to peers (in unique update groups):
11    10.60.0.1       
12  Path #1: Received by speaker 0
13  Advertised to peers (in unique update groups):
14    10.60.0.1       
15  Local
16    0.0.0.0 from 0.0.0.0 (10.150.2.1)
17      Origin IGP, metric 0, localpref 100, weight 32768, valid, local, best, group-best, import-candidate
18      Received Path ID 0, Local Path ID 1, version 1309
19      Extended community: RT:65100:999

RT Filter on IOS XE

Beginning with the IOS XE node (PE-A-2), the VPNv4 Unicast RIB is examined.

1PE-A-2#show bgp vpnv4 unicast rd 65100:999
2PE-A-2#

At this stage, PE-A-2 does not accept any route originated by PE-B-1.

The no bgp default route-target filter command is applied, and the MP-iBGP session to the RR is reset with clear bgp vpnv4 unicast *. This triggers a new route advertisement from the remote peer RR, including 2.2.2.2/32 originated by PE-B-1.

1PE-A-2(config)#router bgp 65100
2PE-A-2(config-router)#no bgp default route-target filter 
3PE-A-2(config-router)#do clear bgp vpnv4 unicast *
4PE-A-2#
5PE-A-2#
6PE-A-2#show bgp vpnv4 unicast rd 65100:999
7BGP table version is 24, local router ID is 10.150.1.2
8Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
9              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
10              x best-external, a additional-path, c RIB-compressed, 
11              t secondary path, L long-lived-stale,
12Origin codes: i - IGP, e - EGP, ? - incomplete
13RPKI validation codes: V valid, I invalid, N Not found
14
15     Network          Next Hop            Metric LocPrf Weight Path
16Route Distinguisher: 65100:999 (default for vrf TEST)
17 *>i  2.2.2.2/32       10.150.2.1               0    100      0 i

1*Aug 28 19:48:32.583: BGP(4): 10.60.0.1 rcvd UPDATE w/ attr: nexthop 10.150.2.1, origin i, localpref 100, metric 0, originator 10.150.2.1, clusterlist 10.60.0.1, extended community RT:65100:999
2*Aug 28 19:48:32.583: BGP(4): 10.60.0.1 rcvd 65100:999:2.2.2.2/32, label 24010 (0x5DCA)

1PE-A-2#show bgp vpnv4 unicast rd 65100:999 2.2.2.2/32
2BGP routing table entry for 65100:999:2.2.2.2/32, version 15
3Paths: (1 available, best #1, no table)
4  Advertise-best-external
5  Flag: 0x8100
6  Not advertised to any peer
7  Refresh Epoch 2
8  Local
9    10.150.2.1 (metric 31) (via default) from 10.60.0.1 (10.60.0.1)
10      Origin IGP, metric 0, localpref 100, valid, internal, best
11      Extended Community: RT:65100:999
12      Originator: 10.150.2.1, Cluster list: 10.60.0.1 , recursive-via-host
13      mpls labels in/out nolabel/24010
14      rx pathid: 0, tx pathid: 0x0
15      Updated on Aug 28 2026 19:48:32 UTC

As shown in the preceding outputs, the route appears in the VPNv4 Unicast RIB (along with its RT 65100:999) after the command is applied and is selected as the best path. The route is retained in the VPNv4 Unicast RIB but is not imported into any local VRF because no matching local import policy exists, as shown in the following output.

1PE-A-2#show ip route vrf TEST
2
3Routing Table: TEST
4Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
5       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
6       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
7       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
8       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
9       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
10       ia - IS-IS inter area, * - candidate default, U - per-user static route
11       H - NHRP, G - NHRP registered, g - NHRP registration summary
12       o - ODR, P - periodic downloaded static route, l - LISP
13       a - application route
14       + - replicated route, % - next hop override, p - overrides from PfR
15       & - replicated local route overrides by connected
16
17Gateway of last resort is not set
18
19PE-A-2#

This command is not added automatically when VPNv4 Unicast route reflector clients are configured. The show running-config all | include route-target filter command on a route reflector would still show the command without the no keyword.

RT Filter on IOS XR

Having examined the IOS XE node, the analysis now moves to the IOS XR node, PE-A-1.

1RP/0/RP0/CPU0:PE-A-1#show bgp vpnv4 unicast rd 65100:999
2Fri Aug 28 19:55:17.014 UTC
3RP/0/RP0/CPU0:PE-A-1#

Like PE-A-2 before the command was applied, PE-A-1 has not accepted the 2.2.2.2/32 route originated by PE-B-1. The application of the retain route-target all command (the IOS XR equivalent of the IOS XE no bgp default route-target filter command) under the VPNv4 Unicast address family modifies the default behavior.

1RP/0/RP0/CPU0:PE-A-1#conf t
2Fri Aug 28 19:59:36.371 UTC
3RP/0/RP0/CPU0:PE-A-1(config)#router bgp 65100
4RP/0/RP0/CPU0:PE-A-1(config-bgp)#address-family vpnv4 unicast 
5RP/0/RP0/CPU0:PE-A-1(config-bgp-af)#retain route-target all 
6RP/0/RP0/CPU0:PE-A-1(config-bgp-af)#commit
7Fri Aug 28 20:00:54.732 UTC
8RP/0/RP0/CPU0:Aug 28 20:00:54.732 UTC: config[67735]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'admin'. Use 'show configuration commit changes 1000000072' to view the changes. 
9RP/0/RP0/CPU0:Aug 28 20:00:55.885 UTC: bgp[1089]: [default-rtr]: --bgp4_rcv_attributes--: END: nbr=10.60.0.1:: msg=0x0x7f93d74aaf14/105, updlen=86, attrbl=0x0x7f93d74aaf2b/82, ipv4reachlen=0, msginpath=0x0x7f93a23291e0, asloopcheck=1, attrwdrfl=0x00000000:: samecluster=0, local_as_prepended=0, attr_wdr_flags 0x00000000, myascount=0:: myconfedascount=0::rcvdata=0x0x7f93d74aaf7d/0, errptr=0x0x7f93d74aaf76/7
10RP/0/RP0/CPU0:Aug 28 20:00:55.885 UTC: bgp[1089]: [default-rtr] (vpn4u): Received UPDATE from 10.60.0.1 with attributes: 
11RP/0/RP0/CPU0:Aug 28 20:00:55.885 UTC: bgp[1089]: [default-rtr] (vpn4u): nexthop 10.150.2.1/32, origin i, localpref 100, metric 0, originator 10.150.2.1, clusterlist 1.0.60.10, extended community RT:65100:999 
12RP/0/RP0/CPU0:Aug 28 20:00:55.885 UTC: bgp[1089]: [default-rtr] (vpn4u): Received prefix 2ASN:65100:999:2.2.2.2/32 (path ID: none) with MPLS label 24010  from neighbor 10.60.0.1
13RP/0/RP0/CPU0:Aug 28 20:00:55.885 UTC: bgp[1089]: [default-rtr]: Received UPDATE from 10.60.0.1 (length incl. header = 105)
14[OUTPUT OMITTED]

A difference from the IOS XE behavior is that IOS XR automatically triggers a soft route refresh request toward the remote BGP peer (in this example RR). As in the previous case, after the command is applied, the 2.2.2.2/32 route advertisement is accepted and the DENIED RT extended community is not imported locally message no longer appears.

1RP/0/RP0/CPU0:PE-A-1#show bgp vpnv4 unicast rd 65100:999
2Fri Aug 28 20:10:19.783 UTC
3BGP router identifier 10.150.1.1, local AS number 65100
4BGP generic scan interval 60 secs
5Non-stop routing is enabled
6BGP table state: Active
7Table ID: 0x0
8BGP main routing table version 1361
9BGP NSR Initial initsync version 1 (Reached)
10BGP NSR/ISSU Sync-Group versions 0/0
11BGP scan interval 60 secs
12
13Status codes: s suppressed, d damped, h history, * valid, > best
14              i - internal, r RIB-failure, S stale, N Nexthop-discard
15Origin codes: i - IGP, e - EGP, ? - incomplete
16   Network            Next Hop            Metric LocPrf Weight Path
17Route Distinguisher: 65100:999 (default for vrf TEST)
18Route Distinguisher Version: 1360
19*>i2.2.2.2/32         10.150.2.1               0    100      0 i
20
21Processed 1 prefixes, 1 paths

1RP/0/RP0/CPU0:PE-A-1#show bgp vpnv4 unicast rd 65100:999 2.2.2.2/32
2Fri Aug 28 20:11:06.407 UTC
3BGP routing table entry for 2.2.2.2/32, Route Distinguisher: 65100:999
4Versions:
5  Process           bRIB/RIB   SendTblVer
6  Speaker               1360         1360
7Last Modified: Aug 28 20:00:55.465 for 00:10:11
8Paths: (1 available, best #1)
9  Not advertised to any peer
10  Path #1: Received by speaker 0
11  Not advertised to any peer
12  Local
13    10.150.2.1 (metric 22) from 10.60.0.1 (10.150.2.1)
14      Received Label 24010 
15      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, not-in-vrf
16      Received Path ID 0, Local Path ID 1, version 1360
17      Extended community: RT:65100:999 
18      Originator: 10.150.2.1, Cluster list: 10.60.0.1

IOS XR therefore behaves in the same way as IOS XE in this scenario. When no local import policy matches the RT attached to the route advertisement, retain route-target all prevents the route from being discarded by the default filter.

Different RT-Less VPNv4 Unicast Route Retention on IOS XE and IOS XR

Returning to the initial scenario where the route advertisement carries no RT, the export command is removed from PE-B-1 to restore its original configuration. The 2.2.2.2/32 route continues to originate from PE-B-1, and the commands that disable RT filtering on PE-A-1 and PE-A-2 remain in effect.

1RP/0/RP0/CPU0:PE-B-1#show running-config vrf TEST
2Fri Aug 28 20:20:57.938 UTC
3vrf TEST
4 address-family ipv4 unicast
5 !
6!

Case 1: IOS XR

On PE-A-1, a soft route refresh is triggered toward RR to receive the route advertisements again, including the route originated by PE-B-1 without an RT extended community.

1RP/0/RP0/CPU0:PE-A-1#
2RP/0/RP0/CPU0:PE-A-1#clear bgp vpnv4 unicast * soft 
3Fri Aug 28 20:24:59.787 UTC
4RP/0/RP0/CPU0:Aug 28 20:24:59.899 UTC: bgp[1089]: [default-rtr]: --bgp4_rcv_attributes--: END: nbr=10.60.0.1:: msg=0x0x7f93d74ab928/94, updlen=75, attrbl=0x0x7f93d74ab93f/71, ipv4reachlen=0, msginpath=0x0x7f93a23291e0, asloopcheck=1, attrwdrfl=0x00000000:: samecluster=0, local_as_prepended=0, attr_wdr_flags 0x00000000, myascount=0:: myconfedascount=0::rcvdata=0x0x7f93d74ab986/0, errptr=0x0x7f93d74ab97f/7
5RP/0/RP0/CPU0:Aug 28 20:24:59.915 UTC: bgp[1089]: [default-rtr] (vpn4u): Received UPDATE from 10.60.0.1 with attributes: 
6RP/0/RP0/CPU0:Aug 28 20:24:59.916 UTC: bgp[1089]: [default-rtr] (vpn4u): nexthop 10.150.2.1/32, origin i, localpref 100, metric 0, originator 10.150.2.1, clusterlist 1.0.60.10
7RP/0/RP0/CPU0:Aug 28 20:24:59.916 UTC: bgp[1089]: [default-rtr] (vpn4u): Received prefix 2ASN:65100:999:2.2.2.2/32 (path ID: none) with MPLS label 24010  from neighbor 10.60.0.1
8RP/0/RP0/CPU0:Aug 28 20:24:59.917 UTC: bgp[1089]: [default-rtr] (vpn4u): Prefix 2ASN:65100:999:2.2.2.2/32 (path ID: none) received from 10.60.0.1 DENIED RT extended community is not imported locally
9RP/0/RP0/CPU0:Aug 28 20:24:59.917 UTC: bgp[1089]: [default-rtr]: Received UPDATE from 10.60.0.1 (length incl. header = 94)

Note that the debug output does not display the RT extended community attribute, confirming the absence of the RT in this advertisement.

The VPNv4 Unicast RIB is checked again for confirmation.

1RP/0/RP0/CPU0:PE-A-1#show bgp vpnv4 unicast rd 65100:999
2Fri Aug 28 20:29:42.256 UTC
3RP/0/RP0/CPU0:PE-A-1#

As in the initial case, IOS XR discards advertisements that do not carry an RT, even though the retain route-target all command remains configured.

Case 2: IOS XE

A hard reset of the MP-iBGP session is triggered on PE-A-2 toward the route reflector.

1PE-A-2#clear bgp vpnv4 unicast *
2PE-A-2#
3*Aug 28 21:12:28.976: BGP(4): 10.60.0.1 rcvd UPDATE w/ attr: nexthop 10.150.2.1, origin i, localpref 100, metric 0, originator 10.150.2.1, clusterlist 10.60.0.1
4*Aug 28 21:12:28.976: BGP(4): 10.60.0.1 rcvd 65100:999:2.2.2.2/32, label 24010 (0x5DCA)

Note that the debug output does not display the RT extended community attribute, confirming the absence of the RT in this advertisement.

1PE-A-2#show bgp vpnv4 unicast rd 65100:999
2BGP table version is 24, local router ID is 10.150.1.2
3Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
4              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
5              x best-external, a additional-path, c RIB-compressed, 
6              t secondary path, L long-lived-stale,
7Origin codes: i - IGP, e - EGP, ? - incomplete
8RPKI validation codes: V valid, I invalid, N Not found
9
10     Network          Next Hop            Metric LocPrf Weight Path
11Route Distinguisher: 65100:999 (default for vrf TEST)
12 *>i  2.2.2.2/32       10.150.2.1               0    100      0 i

As shown in the preceding outputs, IOS XE accepts the route originated by PE-B-1, unlike IOS XR. However, because the route advertisement does not carry an RT extended community, it cannot be imported into any VRF.

Final Takeaway

A route reflector can reflect VPN routes without a local VRF import policy because route reflection requires BGP path retention, not local VRF import.

There are also scenarios in which this filtering mechanism must be disabled on nodes that do not act as route reflectors, and both platforms require a dedicated command to override the default behavior.

I hope this post has been helpful. Feel free to reach out via social media if you have any additional information to share or if you need any clarification. See you in the next one! 🙂