Inter-AS MPLS MVPN – Part 2 – Option C

with three labels and recursive FEC

January 23, 2016 lb45527inter-as option c, mdt, mpls, multicast, mvpn, recursive fec

In the previous post I described MPLS MVPN using inter-AS Option C, however I purposely
redistributed the loopbacks of the PE routers from BGP into the IGP in both AS’s so core P
routers were able perform a unicast route lookup on the root node for multipoint LSPs; because
of this, mLDP signaling was successful through both provider networks and a core tree could be
built. This is referred to as a non-segmented MVPN.

Another option for implementing option C is to use labelled IPv4 unicast sessions between the
PEs and the ASBRs (or most likely through a route reflector). In a BGP-free core, the P routers
have no knowledge of the PE routers in the other AS and so a three-label stack is used to forward
traffic across the Ingress PE’s AS based on the top label identifying the Egress ASBR.
This enables unicast VPNs but it does not overcome the problem of a P router performing a
unicast RIB lookup on a multipoint LSP root node address.

In this post I will show a feature known as recursive FEC as described in RFC 6512.

I will use the network shown in the previous post. I have also replaced R8 which was an IOS
router to XR8 running IOS-XR because IOS does not support recursive FECs. We create BGP
IPv4 labelled unicast sessions between the ASBRs an the PE routers within AS200 to enable
sending of labels with BGP routes.

 
 

The configuration in IOS-XR is as follows.

RP/0/0/CPU0:XR8(config)#router bgp 200

RP/0/0/CPU0:XR8(config-bgp)#address-family ipv4 unicast
RP/0/0/CPU0:XR8(config-bgp-af)#allocate-label all
RP/0/0/CPU0:XR8(config-bgp-af)#exit
RP/0/0/CPU0:XR8(config-bgp)#neighbor 9.9.9.9
RP/0/0/CPU0:XR8(config-bgp-nbr)#address-family ipv4 labeled-unicast
RP/0/0/CPU0:XR8(config-bgp-nbr)#neighbor 11.11.11.11
RP/0/0/CPU0:XR8(config-bgp-nbr)#address-family ipv4 labeled-unicast

In IOS-XR, the allocate-label command is used to control which BGP routes are assigned labels.
This can be controlled with an route policy or we can take the easy way and allocate labels to all
routes.

The configuration in IOS is as follows.

R9(config)#router bgp 200

R9(config-router)#address-family ipv4 unicast
R9(config-router-af)#neighbor 5.5.5.5 send-label
R9(config-router-af)#neighbor 7.7.7.7 send-label
R9(config-router-af)#neighbor 8.8.8.8 send-label

We can check the neighbors have come up as follows.

RP/0/0/CPU0:XR8#show bgp ipv4 labeled-unicast summary

Sat Jan 23 00:28:20.781 UTC
BGP router identifier 8.8.8.8, local AS number 200
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 9
BGP main routing table version 9
BGP NSR Initial initsync version 9 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer 
StandbyVer
Speaker               9          9          9          9           9         
0
Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down 
St/PfxRcd
9.9.9.9           0   200      62      49        9    0    0 00:46:20         
7
11.11.11.11       0   200      49      46        9    0    0 00:43:56         
6

Once this is established, we confirm that we are receiving BGP IPv4 routes with labels.

RP/0/0/CPU0:XR8#show bgp ipv4 labeled-unicast labels

Sat Jan 23 00:29:56.625 UTC
BGP router identifier 8.8.8.8, local AS number 200
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 9
BGP main routing table version 9
BGP NSR Initial initsync version 9 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop        Rcvd Label      Local Label
*>i1.1.1.1/32         9.9.9.9         30              24019
* i                   11.11.11.11     24017           24019
*>i2.2.2.2/32         9.9.9.9         31              24020
* i                   11.11.11.11     24018           24020
*>i4.4.4.4/32         9.9.9.9         33              24021
* i                   11.11.11.11     24019           24021
*>i5.5.5.5/32         9.9.9.9         17              24003
* i                   11.11.11.11     24000           24003
*>i7.7.7.7/32         9.9.9.9         18              24004
* i                   11.11.11.11     24001           24004
*>i8.8.8.8/32         9.9.9.9         37              24022
* i                   11.11.11.11     24002           24022
*>i9.9.9.9/32         9.9.9.9         3               24005
Processed 7 prefixes, 13 paths

Once we have the multihop EBGP VPNv4 sessions between the PE routers established and an
end-to-end LSP, we should see that a three-label stack is used for VPN traffic across the
providers.

R40#traceroute 100.10.10.10 source 100.40.40.40 numeric

Type escape sequence to abort.
Tracing the route to 100.10.10.10
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.80.8 65 msec 136 msec 72 msec
  2 10.0.128.12 [MPLS: Labels 17/30/28 Exp 0] 91 msec 105 msec 103 msec
  3 10.0.129.9 [MPLS: Labels 30/28 Exp 0] 121 msec 10 msec 30 msec
  4 4.9.0.4 [MPLS: Labels 19/28 Exp 0] 14 msec 15 msec 43 msec
  5 192.168.110.1 [MPLS: Label 28 Exp 0] 149 msec 247 msec 102 msec
  6 192.168.110.10 66 msec *  98 msec

Note the three label stack:

1. The bottom of stack label identifies the VPN route at the Egress PE router. It is assigned
(in this case) by R1 over the EBGP VPNv4 session
2. The middle of stack label identifies the Egress PE router R1. It is assigned by R9 over the
labelled IPv4 unicast sessision
3. The top of stack label identifies the Egress ASBR router in AS200. It is assigned by LDP
using using label bindings for the unicast MP2P FEC.

 
Our MDT and BGP MVPN configurations have not changed from the previous posts, so lets
make sure that we are still receiving MVPN autodiscovery routes from R1.

RP/0/0/CPU0:XR8#show bgp ipv4 mvpn route-type 1

Sat Jan 23 00:45:22.131 UTC
BGP router identifier 8.8.8.8, local AS number 200
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0   RD version: 0
BGP main routing table version 5
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.1:1
*> [1][1.1.1.1]/40    1.1.1.1                  0             0 100 ?
Route Distinguisher: 8.8.8.8:1 (default for vrf AS200_A)
*> [1][1.1.1.1]/40    1.1.1.1                  0             0 100 ?
Processed 2 prefixes, 2 paths

As we did not configure R8/XR8 MVPN autodiscovery in the last post, we will configure XR8
to originate an Type 1 BGP autodiscovery for the MVPN that does not have the NO_EXPORT
community as follows.

RP/0/0/CPU0:XR8(config)#multicast-routing vrf AS200_A add ipv4

RP/0/0/CPU0:XR8(config-mcast-AS200_A-ipv4)#bgp auto-discovery mldp
RP/0/0/CPU0:XR8(config-mcast-AS200_A-ipv4-bgp-ad)#inter-as

We can see that R8 is originating a Type 1 MVPN autodiscovery route and that is received by R1
and imported into the VRF

R1#show bgp ipv4 mvpn vrf AS100_A route-type 1 8.8.8.8

BGP routing table entry for [1][1.1.1.1:1][8.8.8.8]/12, version 91
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  200, imported path from [1][8.8.8.8:1][8.8.8.8]/12 (global)
    8.8.8.8 (metric 1) from 8.8.8.8 (8.8.8.8)
      Origin IGP, localpref 100, valid, external, best
      Extended Community: RT:100:1
      PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 17, label: exp-null,
tunnel parameters: 0600 0104 0808 0808 0007 0100 0400 0000 01
      rx pathid: 0, tx pathid: 0x0

To reiterate, make sure you configure “inter-as” under the BGP autodiscovery features otherwise
the Type 1 will not be sent to R1 because of the NO_EXPORT community.

Going back to XR8 now, we see that mLDP state has been created in the LIB for the P2MP core
tree rooted at R1.

RP/0/0/CPU0:XR8#show mpls mldp database root 1.1.1.1

Sat Jan 23 01:29:23.330 UTC
mLDP database
LSM-ID: 0x00002  Type: P2MP  Uptime: 00:02:55
  FEC Root           : 1.1.1.1
  Opaque decoded     : [global-id 65536]
  Upstream neighbor(s) :
    12.12.12.12:0 [Active] Uptime: 00:02:55
      Local Label (D) : 24023
  Downstream  client(s):
    PIM MDT            Uptime: 00:02:55
      Egress intf     : LmdtAS200/A
      Table ID        : IPv4: 0xe0000011 IPv6: 0xe0800011
      RPF ID          : 3
      RD              : 257:16842753

The upstream neighbor here is R12, so the mLDP label bindings for this P2MP FEC will be sent
to R12, which we can see as follows.

R12#show mpls mldp database summary

LSM ID     Type    Root              Decoded Opaque Value          Client Cnt.
9          P2MP    3.3.3.3           [gid 1 (0x00000001)]          1
8          P2MP    8.8.8.8           [gid 1 (0x00000001)]          1
7          P2MP    1.1.1.1           [gid 65536 (0x00010000)]      1
R12#show mpls mldp database id 7
LSM ID : 7   Type: P2MP   Uptime : 00:05:37
  FEC Root           : 1.1.1.1
  Opaque decoded     : [gid 65536 (0x00010000)]
  Opaque length      : 4 bytes
  Opaque value       : 01 0004 00010000
  Upstream client(s) :
    None
      Expires        : N/A           Path Set ID  : B
  Replication client(s):
    8.8.8.8:0
      Uptime         : 00:05:37      Path Set ID  : None
      Out label (D)  : 24023         Interface    : GigabitEthernet1.128*
      Local label (U): None          Next Hop     : 10.0.128.8

Now this is where the problem is because R12 has no unicast route to the root node for this LSP.
We can see that because there is no entries in the upstream clients section of the LIB entry. If
there is no unicast route to the root node, then the mLDP signaling will not go any further
upstream.

The solution to this is outlined in RFC 6512 and referred to in IOS and IOS-XR as recursive
FEC. With recursive FEC, one FEC is encoded within the opaque value of another FEC. The
outer FEC contains the IP address of the ASBR as the root node so that the mLDP signaling
works even when the P router has no unicast route to the Ingress PE router. In the opaque value
of the outer FEC encoded is the inner FEC which contains the the Ingress PE router as the root
node. We enable recursive FEC under the mLDP process as follows. This configuration only
required on the Egress PE router; the ASBRs interpreting the recursive FECs do not need to have
this configuration.

RP/0/0/CPU0:XR8(config)#mpls ldp
RP/0/0/CPU0:XR8(config-ldp)#mldp
RP/0/0/CPU0:XR8(config-ldp-mldp)#address-family ipv4
RP/0/0/CPU0:XR8(config-ldp-mldp-af)#recursive-fec

Once this is enabled, XR8 will encode the recursive FEC such that the outer FEC has the root
address of XR11, the BGP next hop to the Ingress PE router 1.1.1.1. We can see the recursive
FEC as follows. Note that to ensure that traffic leaves AS200 through XR11 (which supports
recursive FEC), I have configured XR11 to set the LOCAL_PREF of all routes received from
AS100 to 500.
 

RP/0/0/CPU0:XR8#show mpls mldp database root 1.1.1.1

Sat Jan 23 03:36:38.017 UTC
mLDP database
LSM-ID: 0x00007 (LSP-ID: 0x80009)  Type: P2MP  Uptime: 00:03:07
  FEC Root           : 1.1.1.1
  Opaque decoded     : [global-id 65536]
  Features           : RFEC
  Upstream neighbor(s) :
    Recursive encode LSM-ID: 0x0000B
  Downstream  client(s):
    PIM MDT            Uptime: 00:03:07
      Egress intf     : LmdtAS200/A
      Table ID        : IPv4: 0xe0000011 IPv6: 0xe0800011
      RPF ID          : 1
      RD              : 257:16842753
RP/0/0/CPU0:XR8#show mpls mldp database 0x0000B
Sat Jan 23 03:36:45.586 UTC
mLDP database
LSM-ID: 0x0000B (LSP-ID: 0x80009)  Type: P2MP  Uptime: 00:03:15
  FEC Root           : 11.11.11.11
  Opaque decoded     : [recursive] 1.1.1.1:[global-id 65536]
  Features           : RFEC
  Upstream neighbor(s) :
    13.13.13.13:0 [Active] Uptime: 00:03:15
      Local Label (D) : 24025
  Downstream  client(s):
    Recursive 0x00007  Uptime: 00:03:15

The first entry in the mLDP LIB is the inner FEC which contains R1 as the root node for the
P2MP LSP. In the inner FEC is where the outer FEC recurses to because the outer FEC must be
used for mLDP signaling in the core towards the ASBR(s) in the local AS. In the outer FEC the
ASBR is listed as the root node, who must interpret the recursive FEC and keep it moving
towards the actual LSP root.

The mLDP signaling now travels towards XR11 through AS200 to R13. We can see the mLDP
LIB for R13 as follows.

R13#show mpls mldp database id 1

LSM ID : 1   Type: P2MP   Uptime : 00:11:17
  FEC Root           : 11.11.11.11
  Opaque decoded     : Unknown Unknown
  Opaque length      : 17 bytes
  Opaque value       : 07 0011 0600010401010101000701000400010000
  Upstream client(s) :
    11.11.11.11:0    [Active]
      Expires        : Never         Path Set ID  : 1
      Out Label (U)  : None          Interface    : GigabitEthernet1.1113*
      Local Label (D): 21            Next Hop     : 10.0.113.11
  Replication client(s):
    8.8.8.8:0
      Uptime         : 00:11:17      Path Set ID  : None
      Out label (D)  : 24025         Interface    : GigabitEthernet1.138*
      Local label (U): None          Next Hop     : 10.0.138.8

Note that the opaque value cant be decoded on an IOS router because it doesn’t support recursive
FEC and the RFC states that P routers must not attempt to interpret recursive FECs. This is fine
as long as the root node listed in the outer FEC supports the recursive FEC feature and can
intepret the opaque value. Because R13 can perform a unicast route lookup on the root node
address in the outer FEC, the mLDP signaling can continue and the mLDP LIB entry can be
populated with the correct upstream and downstream interface and labels.

Now moving to XR11 who is the preferred AS200 ASBR for traffic going to AS100, we can see
the mLDP bindings for this recursive FEC.

RP/0/0/CPU0:XR11#show mpls mldp database

Sat Jan 23 03:50:41.229 UTC
mLDP database
LSM-ID: 0x00003 (LSP-ID: 0x80001)   Type: P2MP   Uptime: 00:17:10
  FEC Root           : 6.11.0.6
  Opaque decoded     : [recursive] 1.1.1.1:[global-id 65536]
  Upstream neighbor(s) :
    6.6.6.6:0 [Active] Uptime: 00:17:10
      Local Label (D) : 24020
  Downstream  client(s):
    Recursive 0x00001  Uptime: 00:17:10
LSM-ID: 0x00001 (LSP-ID: 0x80001)   Type: P2MP   Uptime: 00:17:10
  FEC Root           : 11.11.11.11 (we are the root)
  Opaque decoded     : [recursive] 1.1.1.1:[global-id 65536]
  Upstream neighbor(s) :
    Recursive encode LSM-ID: 0x00003
  Downstream  client(s):
    LDP 13.13.13.13:0  Uptime: 00:17:10
      Next Hop         : 10.0.113.13
      Interface        : GigabitEthernet0/0/0/0.1113
      Remote label (D) : 21

 
XR11 interprets the outer FEC (the one in the LIB with the FEC root set to the 11.11.11.11) as
recursive for the root node R1. It installs downstream state for the LSP going down to R13, and
then performs a unicast route lookup on R1 (1.1.1.1) to identify the BGP next hop, which is R6
(6.11.0.6). It creates another recursive FEC with the outer FEC listing XR6 as the temporary root
node and encodes the inner FEC within opaque value (which has 1.1.1.1 set as the root address).
No additional configuration was required here to enable recursive FEC; the LDP configuration
on XR11 looks like this.

RP/0/0/CPU0:XR11#show run mpls ldp

Sat Jan 23 21:22:24.957 UTC
mpls ldp
 mldp
 !
 router-id 11.11.11.11
 interface GigabitEthernet0/0/0/0.119
  address-family ipv4
  !
 !
 interface GigabitEthernet0/0/0/0.611
  address-family ipv4
  !
 !
 interface GigabitEthernet0/0/0/0.1113
  address-family ipv4
  !
 !
!

XR11 signals to XR6 the label mapping now. The outer FEC lists XR6 as the root node, so it
must interpret the recursive FEC to identify the root node address in the inner FEC, which is
1.1.1.1. XR6 performs a unicast route lookup on 1.1.1.1 and can see that the address is known
via IGP so no recursion is necessary (as the assumption here is that the P routers have a unicast
route to R1). We can see that in the mLDP LIB as follows.

RP/0/0/CPU0:XR6#show mpls mldp database

Sat Jan 23 10:09:42.512 UTC
mLDP database
LSM-ID: 0x00008 (LSP-ID: 0x80009)   Type: P2MP   Uptime: 05:16:05
  FEC Root           : 1.1.1.1
  Opaque decoded     : [global-id 65536]
  Upstream neighbor(s) :
    1.1.1.1:0 [Active] Uptime: 05:16:05
      Local Label (D) : 24015
  Downstream  client(s):
    Recursive 0x00007  Uptime: 05:16:05
LSM-ID: 0x00007 (LSP-ID: 0x80009)   Type: P2MP   Uptime: 05:16:05
  FEC Root           : 6.11.0.6 (we are the root)
  Opaque decoded     : [recursive] 1.1.1.1:[global-id 65536]
  Upstream neighbor(s) :
    Recursive decode LSM-ID: 0x00008
  Downstream  client(s):
    LDP 11.11.11.11:0  Uptime: 05:16:05
      Next Hop         : 6.11.0.11
      Interface        : GigabitEthernet0/0/0/0.611
      Remote label (D) : 24023

The bottom LSP (LSM-ID 0x00007) is the recursive one, listing XR6 as the root node in the
outer FEC and R1 in the inner FEC. This LSP also lists the interprovider link in the downstream
clients so that multicast traffic for this LSP will flow down this link. XR6 also creates a normal
FEC (i.e. non-recursive) which lists R1 as the root node, and has the recursive FEC listed in the
downstream clients because that is where the downstream replication information is contained.

Now on R1 we can see the that we are the root of the P2MP LSP so there are no upstream
clients; only replication clients.

R1#show mpls mldp database id 3

LSM ID : 3   Type: P2MP   Uptime : 16:57:27
  FEC Root           : 1.1.1.1 (we are the root)
  Opaque decoded     : [gid 65536 (0x00010000)]
  Opaque length      : 4 bytes
  Opaque value       : 01 0004 00010000
  Upstream client(s) :
    None
      Expires        : N/A           Path Set ID  : 3
  Replication client(s):
    MDT  (VRF AS100_A)
      Uptime         : 16:57:27      Path Set ID  : None
      Interface      : Lspvif0
    4.4.4.4:0
      Uptime         : 02:56:21      Path Set ID  : None
      Out label (D)  : 28            Interface    : GigabitEthernet1.14*
      Local label (U): None          Next Hop     : 10.0.14.4
    6.6.6.6:0
      Uptime         : 00:26:14      Path Set ID  : None
      Out label (D)  : 24013         Interface    : GigabitEthernet1.16*
      Local label (U): None          Next Hop     : 10.0.16.6

 
The mLDP signaling has gone from XR8 to R1 as follows.

Now that the signaling has completed and label switching can occur from the P2MP LSP root to
the Egress PE routers, we should be able to multicast traffic over it.

On the CE router attached to XR8, we configure it to join the (100.10.10.10,232.10.10.10) pair.

R40(config)#interface GigabitEthernet1.1240
R40(config-subif)#ip igmp join-group 232.10.10.10 source 100.10.10.10

This creates state on MRIB state XR8 and and because we are using a BGP overlay, XR8
originates a Type 7 route to signal the join (see my previous posts for C-multicast signaling)

RP/0/0/CPU0:XR8#show bgp ipv4 mvpn

Sat Jan 23 10:18:36.415 UTC
BGP router identifier 8.8.8.8, local AS number 200
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0   RD version: 0
BGP main routing table version 45
BGP NSR Initial initsync version 8 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.1:1
*> [1][1.1.1.1]/40    1.1.1.1                  0             0 100 ?
Route Distinguisher: 8.8.8.8:1 (default for vrf AS200_A)

*> [1][1.1.1.1]/40    1.1.1.1                  0             0 100 ?

*> [1][8.8.8.8]/40    0.0.0.0                                0 i

*> [7][1.1.1.1:1][16843009][32][100.10.10.10][32][232.10.10.10]/184
                      0.0.0.0                                0 i
Processed 4 prefixes, 4 paths

R1 will receive the MVPN route, import it into the MVPN VRF, and then creates MRIB state for
the (S,G), listing the PE-CE interface (going towards the source) as the incoming interface and
the MDT virtual interface in the OIL

R1#show ip mroute vrf AS100_A 232.10.10.10 100.10.10.10

IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM
Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(100.10.10.10, 232.10.10.10), 00:01:17/00:01:42, flags: sTG
  Incoming interface: GigabitEthernet2.1110, RPF nbr 192.168.110.10
  Outgoing interface list:
    Lspvif0, Forward/Sparse, 00:01:17/00:01:42

Now we should be able to send traffic from the source to the receivers.

R1#ping 232.10.10.10 source loop0

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 232.10.10.10, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
Reply to request 0 from 192.168.80.50, 9 ms
Reply to request 0 from 192.168.80.50, 67 ms

Traffic flows down the tree as follows.

 
 

Which works as expected. Some last notes on this setup:

1. Recursive FEC is only required when the core routers do not have unicast route to the
root node, which is true in our case because we did not redistribute the BGP routes into
IGP in AS200.
2. Classis IOS does not support recursive FECs, so the Egress PE router and the ASBRs
must be IOS-XR to interpret them
3. The “recursive-fec” command only needs to be configured on the Egress PE route