MPLS L3VPN – EIGRP PE-CE Routing

EIGRP PE-CE Routing

In an MPLS VPN environment, to achieve this, the original EIGRP metrics must be carried inside MP-BGP updates. This is achieved by using BGP extended community attributes to carry and preserve EIGRP metrics when crossing the MP-iBGP domain. These communities define the intrinsic characteristics associated with EIGRP, such as the AS number or EIGRP cost metric like bandwidth, delay, load, reliability, and MTU.

BGP Extended Communities for EIGRP PE-CE Routing

Example gives the details on the extended BGP community attribute that are attached to sample routes 192.168.20.0 and 192.168.99.0:

Scenario 1: Basic EIGRP PE-CE Routing Configuration

Route propagation in MPLS VPN networks using EIGRP PE-CE routing is based on EIGRP AS configured on the PE routers.

				
					!'[PE1-AS1]'
vrf definition Cust_A
 rd 1:100
 route-target export 1:100
 route-target import 1:100
 !
 address-family ipv4
 exit-address-family
vrf definition Cust_B
 rd 1:200
 route-target export 1:200
 route-target import 1:200
 !
 address-family ipv4
 exit-address-family
!
router eigrp A
 !
 address-family ipv4 unicast vrf Cust_A autonomous-system 101
  topology base
   redistribute bgp 1 metric 1000 10 100 1 1500
  exit-af-topology
  network 172.16.1.0 0.0.0.255
  network 172.16.3.0 0.0.0.255
 exit-address-family
 !
 address-family ipv4 unicast vrf Cust_B autonomous-system 201
  topology base
   redistribute bgp 1 metric 1000 100 255 1 1500
  exit-af-topology
  network 192.168.0.0 0.0.255.255
 exit-address-family
!
router bgp 1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.10.10.102 remote-as 1
 neighbor 10.10.10.102 update-source Loopback0
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.10.10.102 activate
  neighbor 10.10.10.102 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf Cust_A
  redistribute eigrp 101
 exit-address-family
 !
 address-family ipv4 vrf Cust_B
  redistribute eigrp 201
 exit-address-family
				
			
				
					!'[PE2-AS1]'
vrf definition Cust_A
 rd 1:100
 route-target export 1:100
 route-target import 1:100
 !
 address-family ipv4
 exit-address-family
vrf definition Cust_B
 rd 1:200
 route-target export 1:200
 route-target import 1:200
 !
 address-family ipv4
 exit-address-family
!
router eigrp A
 !
 address-family ipv4 unicast vrf Cust_A autonomous-system 101
  topology base
   redistribute bgp 1 metric 1000 100 255 1 1500
  exit-af-topology
  network 172.16.2.0 0.0.0.255
  network 172.16.4.0 0.0.0.255
 exit-address-family
 !
 address-family ipv4 unicast vrf Cust_B autonomous-system 202
  topology base
   redistribute bgp 1 metric 1000 100 255 1 1500
  exit-af-topology
  network 192.168.0.0 0.0.255.255
 exit-address-family
!
router bgp 1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.10.10.101 remote-as 1
 neighbor 10.10.10.101 update-source Loopback0
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.10.10.101 activate
  neighbor 10.10.10.101 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf Cust_A
  redistribute eigrp 101
 exit-address-family
 !
 address-family ipv4 vrf Cust_B
  redistribute eigrp 202
 exit-address-family
				
			

EIGRP AS Is Same on All PE Routers

The following sequence takes place when CE2-A is sending 172.16.20.0/24 and 172.16.99.0/24 to CE1-A:

  1. CE2-A redistributes OSPF network 172.16.99.0/24 as an EIGRP external route (D EX) and 172.16.20.0/24 as an internal route (D) to PE2-AS1.
  2. PE2-AS1 receives 172.16.20.0/24 as internal route with EIGRP metric 10880 and 172.16.99.0/24 as an external route with EIGRP metric 5176320.
  3. The EIGRP metrics for 172.16.20.0 and 172.16.99.0/24 are copied into extended BGP attributes as BGP MEDs, and extended communities containing EIGRP information such as AS, MTU, route type, and so on are attached when EIGRP routes are redistributed into MP-BGP. The routes 172.16.20.0 and 172.16.99.0/24 are then propagated to PE1-AS1 via MP-iBGP session.
  4. PE1-AS1 receives the BGP VPNv4 routes 172.16.20.0/24 and 172.16.99.0/24 from PE2-AS1. The EIGRP metric for the routes are not altered and remain the same when propagated though the MP-BGP backbone.
  5. PE2-AS1 checks the attributes received in the route, and, if route type is internal (if the MSB bit in the 0x8800 BGP extended community attribute is set) and the source AS matches what is configured on the receiving PE router, the route is advertised as EIGRP internal route. If the route type is external (MSB bit in 0x8800 is not set), the route is advertised as an external EIGRP route to the CE.
  6. CE1-A receives the 172.16.20.0 as an internal route and 172.16.99.0/24 as an external route.
				
					/*
Received from CE2-A:
    172.16.20.0/24 internal route
    172.16.99.0/24 external route
*/
PE2-AS1#show ip route vrf Cust_A eigrp 
Routing Table: Cust_A
/*omitted*/
Gateway of last resort is not set
      172.16.0.0/16 is variably subnetted, 6 subnets, 3 masks
D        172.16.20.0/24 
           [90/'10880'] via 172.16.2.2, 00:42:06, GigabitEthernet0/2
D EX     172.16.99.0/24 
           [170/'5176320'] via 172.16.2.2, 00:40:39, GigabitEthernet0/2
PE2-AS1#

/*
- Routes advertised as VPNv4 prefixes to PE1-AS1
- Routes received by PE1-AS1
- EIGRP Metric is not altered, remain the same
*/
PE1-AS1#show bgp vpnv4 unicast all 
/*BGP table version is 9, local router ID is 10.10.10.101
omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:100 (default for vrf Cust_A)
 *>   172.16.1.0/30    0.0.0.0                  0         32768 ?
 *>i  172.16.2.0/30    10.10.10.102             0    100      0 ?
 *>   172.16.10.0/24   172.16.1.2           10880         32768 ?
 *>i  172.16.20.0/24   10.10.10.102         '10880'    100      0 ?
 *>i  172.16.99.0/24   10.10.10.102       '5176320'    100      0 ?
PE1-AS1#

/*
If 0x8800 set = Internal Route
If 0x8800 not set = External Route
If AS matches:
- Internal routes are advertised as Internal
- External routes are advertised as External
*/
PE1-AS1#show bgp vpnv4 unicast all 172.16.20.0
BGP routing table entry for 1:100:172.16.20.0/24, version 6
Paths: (1 available, best #1, table Cust_A)
Flag: 0x100
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.10.10.102 (metric 3) (via default) from 10.10.10.102 (10.10.10.102)
      Origin incomplete, 'metric 10880', localpref 100, valid, internal, best
      Extended Community: RT:1:100 Cost:pre-bestpath:128:10880 '0x8800:32768:0' 
        0x8801:101:288 0x8802:65281:2560 0x8803:65281:1500 0x8806:0:2886755171
      mpls labels in/out nolabel/20
      rx pathid: 0, tx pathid: 0x0

PE1-AS1#show bgp vpnv4 unicast all 172.16.99.0
BGP routing table entry for 1:100:172.16.99.0/24, version 7
Paths: (1 available, best #1, table Cust_A)
Flag: 0x100
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.10.10.102 (metric 3) (via default) from 10.10.10.102 (10.10.10.102)
      Origin incomplete, 'metric 5176320', localpref 100, valid, internal, best
      Extended Community: RT:1:100 
        Cost:pre-bestpath:129:5176320 (default-2142307327) '0x8800:0:0' 
        0x8801:101:2816 0x8802:2561:2560000 0x8803:2570:1500 
        0x8804:1:2886755171 0x8805:6:0 0x8806:0:2886755171
      mpls labels in/out nolabel/21
      rx pathid: 0, tx pathid: 0x0
PE1-AS1#

/*
CE1-A received the routes.
AS number matches so routes are propagated as:
- 172.16.20.0 as Internal
- 172.16.99.0/24 as External
Metrics are updated accordingly to the PE1-AS1 outgoing interface
*/
CE1-A#show ip route eigrp 
/*omitted*/
Gateway of last resort is not set
      172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks
D        172.16.2.0/30 [90/15360] via 172.16.1.1, 00:38:44, GigabitEthernet0/0
D        172.16.20.0/24 
           [90/'16000'] via 172.16.1.1, 00:38:44, GigabitEthernet0/0
D EX     172.16.99.0/24 
           [170/'5181440'] via 172.16.1.1, 00:38:44, GigabitEthernet0/0
CE1-A#
				
			

EIGRP AS Is Different on All PE Routers

If the two EIGRP AS numbers are different, the normal redistribution rules apply; that is, external EIGRP routes are created when the customer routes are redistributed into EIGRP from MP-BGP updates.

The sequence shown in 1 through 4 in the section “Route Propagation When EIGRP AS Is Same on All PE Routers” remains the same except for networks 192.168.199.0 and 192.168.20.0 and the metric:

  1. PE2-AS1 checks the attributes received in the route, and, if the route type is internal and the source AS does not match or if the route type is external, the route is advertised to the CE as an external EIGRP route. The route will not use the extended community information because it did not originate from the same AS.
    • Route type for 192.168.20.0 is internal and source AS, which is 202, does not match the configured AS on PE1-AS1 (201). Therefore, PE1-AS1 propagates that as an external route to CE1-A. The route type for 192.168.199.0 is external, and, therefore, both routes are propagated to CE1-A as external routes.
  2. CE1-A receives 192.168.20.0/24 and 192.168.99.0/24 as external routes.
				
					/*
PE2-AS1 received the routes from CE router:
    192.168.20.0/24 as an Internal
    192.168.199.0/24 as an External
*/
PE2-AS1#show ip route vrf Cust_B eigrp 
Routing Table: Cust_B
/*omitted*/
Gateway of last resort is not set

D     192.168.20.0/24 [90/10880] via 192.168.2.2, 00:01:57, GigabitEthernet0/3
D EX  192.168.199.0/24 
           [170/5176320] via 192.168.2.2, 00:00:15, GigabitEthernet0/3
PE2-AS1#

/*
PE1-AS1 received the routes
Metric is not altered
0x8800 is set = Internal (192.168.20.0/24)
0x8800 is not set = External (192.168.199.0/24)
*/
PE1-AS1#show bgp vpnv4 unicast vrf Cust_B       
BGP table version is 23, local router ID is 10.10.10.101
/*omitted*/
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:200 (default for vrf Cust_B)
 *>   192.168.1.0/30   0.0.0.0                  0         32768 ?
 *>i  192.168.2.0/30   10.10.10.102             0    100      0 ?
 *>   192.168.10.0     192.168.1.2          10880         32768 ?
 *>i  192.168.20.0     10.10.10.102         '10880'    100      0 ?
 *>i  192.168.199.0    10.10.10.102       '5176320'    100      0 ?
PE1-AS1#

PE1-AS1#show bgp vpnv4 unicast all 192.168.20.0 
BGP routing table entry for 1:200:192.168.20.0/24, version 21
Paths: (1 available, best #1, table Cust_B)
  Not advertised to any peer
  Refresh Epoch 2
  Local
    10.10.10.102 (metric 3) (via default) from 10.10.10.102 (10.10.10.102)
      Origin incomplete, metric 10880, localpref 100, valid, internal, best
      Extended Community: RT:1:200 Cost:pre-bestpath:128:10880 '0x8800:32768:0' 
        0x8801:202:288 0x8802:65281:2560 0x8803:65281:1500 0x8806:0:3232286663
      mpls labels in/out nolabel/25
      rx pathid: 0, tx pathid: 0x0

PE1-AS1#show bgp vpnv4 unicast all 192.168.199.0
BGP routing table entry for 1:200:192.168.199.0/24, version 23
Paths: (1 available, best #1, table Cust_B)
  Not advertised to any peer
  Refresh Epoch 2
  Local
    10.10.10.102 (metric 3) (via default) from 10.10.10.102 (10.10.10.102)
      Origin incomplete, metric 5176320, localpref 100, valid, internal, best
      Extended Community: RT:1:200 
        Cost:pre-bestpath:129:5176320 (default-2142307327) '0x8800:0:0' 
        0x8801:202:2816 0x8802:65281:2560000 0x8803:65281:1500 
        0x8804:1:3232286663 0x8805:6:0 0x8806:0:3232286663
      mpls labels in/out nolabel/26
      rx pathid: 0, tx pathid: 0x0
PE1-AS1#

/*
CE1-B router received the routes.
Since the AS number doesn't match, routes are propagated as External routes.
Metrics updated.
*/
CE1-B#show ip route eigrp
/*omitted*/
Gateway of last resort is not set
      192.168.2.0/30 is subnetted, 1 subnets
D EX     192.168.2.0 
           [170/5637120] via 192.168.1.1, 02:46:24, GigabitEthernet0/1
D EX  192.168.20.0/24 
           [170/'5637120'] via 192.168.1.1, 00:07:15, GigabitEthernet0/1
D EX  192.168.199.0/24 
           [170/'5637120'] via 192.168.1.1, 00:05:32, GigabitEthernet0/1
CE1-B#
				
			

Routing Loops and Suboptimal Routing

Routing loop and suboptimal routing generally occur because of mutual redistribution taking place between EIGRP PE-CE and MP-BGP in an MPLS VPN environment.

Routing loops can occur in the following scenarios:

  • A route received by a multihomed site from the backbone through one link can be forwarded back to the backbone via the other link.
  • A route originated in a multihomed site and sent to the backbone through one link can come back through the other link.

Multihomed Site Reinjecting Routes into the Backbone

The following sequence takes place when reinjecting an EIGRP route into the backbone:

  1. 172.16.20.0/24 is advertised as EIGRP internal route to PE2-AS1.
  2. PE2-AS1 propagates 172.16.20.0/24 to CE4-A via EIGRP and sends 172.16.20.0/24 via the MP-iBGP session to PE1-AS1.
  3. CE4-A propagates 172.16.20.0/24 as an EIGRP internal route to CE3-A.
  4. CE3-A propagates 172.16.20.0/24 as an EIGRP internal route to PE1-AS1.

PE1-AS1 has to make the decision of which route to choose:

  • If the BGP update for 172.16.20.0/24 arrives first, it will be redistributed into EIGRP and sent to CE3-A. Because of the better composite metric, it will be preferred over the other EIGRP update because MPLS VPN does not add any delay or bandwidth limitation. This means that PE1-AS1 will never receive a second update and will, therefore, have only one possible path.
  • If the EIGRP update arrives first, it will be redistributed into BGP and sent back to PE2-AS1. PE2-AS1 will still prefer the original EIGRP update, but PE1-AS1 will never select the BGP derived path because it always prefers locally originated routes.

Overall, in this network, even if the administrative distance for EIGRP and BGP are the same, the routing table prefers the route with the lowest administrative distance (EIGRP is 90 or 170; iBGP is 200) by default.

Suboptimal Routing

Suboptimal routing often occurs because EIGRP (90 for internal and 170 for external routes) has a better administrative distance than iBGP (200). A routing table will always prefer an IGP-learned route because all IGPs have a better administrative distance (5 to 170) than internal BGP (200). As shown, PE1-AS1 receives two updates for 172.16.20.0/24: one via EIGRP from CE3-A and one via MP-iBGP from PE2. PE1-AS1 will use the EIGRP-learned route because it has a better administrative distance (90 or 170) than an internal BGP route (200).

BGP Cost Community Feature and EIGRP Site of Origin

Routing loops and suboptimal routing can be avoided by using:

  • The BGP cost community feature, which can be used to force BGP to compare locally originated EIGRP routes and MP-iBGP routes based on the EIGRP metric.
  • The EIGRP site of origin (SoO) feature on PE and CE routers that can be used to prevent routing loops.

BGP Cost Community Feature

The BGP cost community feature introduces a new BGP extended community attribute called the cost community.

  • The cost community is a non-transitive extended community attribute that is passed to internal BGP and confederation peers but not external BGP peers.
  • The cost community feature allows you to customize the local route preference and influence the best path selection process by assigning cost values to specific routes.
  • The feature allows the PE router to compare routes coming from different protocols using different administrative distance values based on their metric.
  • BGP routes carrying the BGP cost community attribute will use EIGRP administrative distance instead of iBGP administrative distance to enable this comparison without the need to statically modify the administrative distance of either protocol.
  • The point of insertion (POI) value makes sure that the BGP route selection uses the BGP cost community before evaluating whether the route is locally originated or not. This allows the comparison of iBGP routes with EIGRP routes.
  • The BGP cost community will also be able to distinguish between internal and external EIGRP routes using the ID field: internal routes will be encoded using ID 128, external routes will be encoded using ID 129.

The route selection process, when using BGP cost communities, prefers the lowest BGP Cost Community ID, which in turn behaves like a normal EIGRP route selection in which internal routes are preferred over external routes. Internal EIGRP routes have a lower BGP Cost Community ID than external EIGRP routes. The route selection will typically depend on the value in the BGP cost community’s Cost field, which carries the composite EIGRP metric.

  • The pre-best path POI was introduced in the BGP cost community feature to support mixed EIGRP-based MPLS VPN network topologies that contain backdoor links.
  • It was integrated in Cisco IOS Release 12.0(27)S, 12.3(8)T, and 12.2(25)S.
  • This POI is applied automatically to EIGRP routes that are redistributed into BGP.
  • The pre-best path POI carries the EIGRP route type and metric.
  • This POI influences the best path calculation process by influencing BGP to consider this POI before any other comparison step.
  • There is no configuration required for inducing POI.
BGP Cost Community Operation

The following sequence takes place in which PE1-AS1 is able to select the best route based on the EIGRP metric and not based on administrative distance between EIGRP and iBGP:

  1. CE2-A originates 172.16.20.0/24 to PE2-AS1.
  2. PE2-AS1 forwards the route to CE4-A via EIGRP and to PE1-AS1 via MP-iBGP.
  3. PE1-AS1 receives two updates for 172.16.20.0/24, one via EIGRP from CE3-A and one via MP-iBGP from PE2-AS1. PE1-AS1 will use the MP-iBGP learned route because it is now capable of comparing the EIGRP composite metric between the real EIGRP route (from CE3-A) and the MP-iBGP route (from PE2-AS1) that is using the BGP cost community attribute to carry the original EIGRP composite metric.
  4. Packets from CE1-A to CE2-A will be forwarded by PE1-AS1 to PE2-AS1 because the routing table of VRF A contains the MP-iBGP route, which carried a lower composite EIGRP metric.
				
					/*
Traceroute from CE1-A to CE4-A's network 172.16.40.0/24
Traffic going thru the MPLS network.
Not using the backdoor link between CE3-A and CE4-A.
*/
CE1-A#traceroute 172.16.40.40
Type escape sequence to abort.
Tracing the route to 172.16.40.40
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.1.1 3 msec 2 msec 4 msec
  2 10.10.10.2 [MPLS: Labels 16/27 Exp 0] 6 msec 5 msec 6 msec
  3 172.16.4.1 [MPLS: Label 27 Exp 0] 5 msec 5 msec 4 msec
  4 172.16.4.2 6 msec *  6 msec
CE1-A#

/*
Since BGP CC is enabled, we are now able to choose the best path
between two different protocols based on metric.
Paths:
1- EIGRP route via CE3-A
2- MP-iBGP route via PE2-AS1
*/
PE1-AS1#show bgp vpnv4 unicast all 172.16.40.0 
BGP routing table entry for 1:100:172.16.40.0/24, version 67
Paths: (1 available, best #1, table Cust_A)
Flag: 0x100
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.10.10.102 (metric 3) (via default) from 10.10.10.102 (10.10.10.102)
      Origin incomplete, metric 10880, localpref 100, valid, internal, best
      Extended Community: RT:1:100 'Cost:pre-bestpath:128:10880' 0x8800:32768:0 
        0x8801:101:288 0x8802:65281:2560 0x8803:65281:1500 0x8806:0:2886731010
      mpls labels in/out nolabel/27
      rx pathid: 0, tx pathid: 0x0
PE1-AS1#

PE1-AS1#show ip eigrp vrf Cust_A topology all-links 
/*omitted*/
..
P 172.16.40.0/24, 1 successors, FD is 1392640, serno 10
        via VPNv4 Sourced (1392640/0)
        via 172.16.3.2 (2048000/1392640), GigabitEthernet0/2
..
PE1-AS1#

/*
via CE3-A --> metric 16000 [EIGRP route]
via PE2-AS1 --> metric 10880 [MP-iBGP route]
Lower metric wins!
*/
PE1-AS1#show ip route vrf Cust_A 172.16.40.0
Routing Table: Cust_A
Routing entry for 172.16.40.0/24
  Known via "bgp 1", distance 200, metric 10880, type internal
  Redistributing via eigrp 101
  Advertised by eigrp 101 metric 1000 10 100 1 1500
  Last update from 10.10.10.102 01:22:12 ago
  Routing Descriptor Blocks:
  * 10.10.10.102 (default), from 10.10.10.102, 01:22:12 ago
      Route metric is 10880, traffic share count is 1
      AS Hops 0
      MPLS label: 24
      MPLS Flags: MPLS Required
PE1-AS1#
				
			

EIGRP SoO Attribute

  • To prevent routing loops, the EIGRP SoO attribute has been added to enable the tagging of internal and external EIGRP routes.
  • This attribute is automatically exchanged between routing protocols (SoO-enabled EIGRP and MP-BGP) to prevent routing loops in multihomed environments where two-way redistribution is used.
  • All CE routers must support this feature to enable the propagation of this attribute throughout the VPN, or at the minimum, the multihomed sites.
  • The EIGRP SoO feature is used on PE and CE routers for the most effective loop prevention.
  • Backdoor links are configured with EIGRP SoO for fastest convergence upon route loss.

Multihomed Sites and EIGRP SoO

Illustrates how routes that are injected into a multihomed site get tagged with an EIGRP SoO value 1:101. The receiving PE router will check all updates against the SoO value configured on the interface through which the update was received. If the values are equal, the update will be rejected, preventing routing loops as well as ensuring optimal routing.

Multihomed Site and EIGRP SoO

The following sequence takes place when 172.16.20.0/24 is propagated to CE1-A:

  1. CE2-A originates a route 172.16.20.0/24.
  2. PE2-AS1 forwards the route to CE4-A via EIGRP and to PE1-AS1 via MP-iBGP. The EIGRP route will be tagged with the new EIGRP attribute called SoO, here 1:101 to indicate that the route came from the MPLS backbone.
  3. CE4-A forwards that 172.16.20.0/24 update to CE3-A.
  4. PE1-AS1 receives two updates for 172.16.20.0/24, one via EIGRP from CE3-A and one via MP-iBGP from PE2-AS1. PE1-AS1 will use the BGP-learned route; the EIGRP route from CE3-A is filtered out because it contains the same SoO value as the interface through which the route was received.

Backdoor Link and EIGRP SoO

The following sequence describes the process of route selection in this scenario:

  1. CE2-A propagates 172.16.20.0/24 to PE2-AS1.
  2. PE2-AS1 forwards 172.16.20.0/24, the route to CE4-A via EIGRP and to PE1-AS1 via MP-iBGP. The EIGRP route will be tagged with the EIGRP SoO value 1:20 to indicate that the route came from the MPLS backbone and was injected into Site 4 with 1:20.
  3. PE1-AS1 receives two updates for 172.16.20.0, one via EIGRP from CE2 and one via MP-iBGP from PE2. Also note that the update, when traveling via the backdoor link, will carry EIGRP SoO value 1:20 when propagated to CE3-A, and CE3-A uses 1:10 to propagate this route to PE1-AS1.
  4. PE1-AS1 receives two updates for 172.16.20.0/24, one via EIGRP from CE3-A with SoO 1:10, which it filters because it contains the same SoO value as the interface through which the route was received and only considers the one via MP-iBGP from PE2-AS1.
Backdoor Link and EIGRP SoO

Scenario 2: BGP CC Feature and EIGRP SoO in MPLS VPN Network with Backdoor Link

To demonstrate EIGRP PE-CE routing in an MPLS VPN environment when there is:

  • No BGP cost community or EIGRP SoO
  • BGP cost community and EIGRP SoO involved

No BGP Cost Community or EIGRP SoO

With no BGP cost community (CC) or EIGRP SoO, the data path:

  • For traffic originating from CE1-A (172.16.10.0) to CE2-A (172.16.20.0) is from CE1-A-CE3-A-CE4-A-PE2-AS1 to destination network on CE2-A, and vice versa.
  • For traffic originating from CE3-A (172.16.30.0) to CE4-A (172.16.40.0) is from CE3-A-CE4-A via the backdoor link and vice versa.
  • For traffic originating from CE3-A (172.16.30.0) to CE2-A (172.16.20.0) is from CE3-A-CE4-A-PE2-AS1 (via the backdoor link), and then to destination network on CE2-A, and vice versa.
  • For traffic originating from CE4-A (172.16.40.0) to CE1-A (172.16.10.0) is from CE4-A-CE3-A-PE1-AS1 (via the backdoor link), and then to the destination network on CE1-A, and vice versa.

In other words, all these traffic paths are forwarded through the backdoor link connecting CE3-A and CE4-A.

Using BGP CC or EIGRP SoO

There is no configuration required for BGP CC. Check Cisco.com for Cisco IOS using the BGP CC for EIGRP-based MPLS VPN networks with backdoor links. EIGRP SoO is configured on PE1-AS1 and PE2-AS1 and on the backdoor links connecting CE3-A and CE4-A.

Tags:

Leave a Reply

Related Post