Jul
19

Can you solve this puzzle?

R2, R3 and R4 create the service provider network, with MPLS on all three routers, and iBGP at the PE routers.  R1 and R5 are the CE routers.

R2, prefers the BGP next hop of 4.4.4.4 for network 5.5.5.5 (R5 loopback). R4, at 4.4.4.4 is an iBGP neighbor.

R2#show ip route vrf v | inc 5.5.5.0
B       5.5.5.0 [200/409600] via 4.4.4.4, 00:06:47

Is R2 preferring an iBGP learned route, which has an AD of 200, over a EIGRP route, which would have an AD of 90?

Can you identify why the routing for 5.5.5.0 on the VRF of R2 is using BGP instead of EIGRP?

EIGRP PATH with MPLS

Below are the relevant portions of the configuration, which also can serve as a great review of how to configure MPLS VPNs.
R1, CE router:

R1#show run
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.1.12.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 ip address 10.1.215.1 255.255.255.0
!

router eigrp 1
 network 0.0.0.0
 no auto-summary

R2, PE Router:

R2#show run
!
ip vrf v
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip vrf forwarding v
 ip address 10.1.12.2 255.255.255.0
!
interface FastEthernet0/1
 ip address 10.1.23.2 255.255.255.0
 ip ospf 1 area 0
 mpls ip
!
router eigrp 1
 no auto-summary
 !
 address-family ipv4 vrf v
  redistribute bgp 234 metric 1 10000 1 1 1
  network 10.1.12.2 0.0.0.0
  auto-summary
  autonomous-system 1
 exit-address-family
!
router ospf 1
 log-adjacency-changes
!
router bgp 234
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 4.4.4.4 remote-as 234
 neighbor 4.4.4.4 update-source Loopback0
 !
 address-family vpnv4
  neighbor 4.4.4.4 activate
  neighbor 4.4.4.4 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf v
  redistribute eigrp 1
  no synchronization
 exit-address-family
!
ip forward-protocol nd
!

R3, P router:

R3#show run

interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.1.34.3 255.255.255.0
 mpls ip
!
interface FastEthernet0/1
 ip address 10.1.23.3 255.255.255.0
 mpls ip
!
router ospf 1
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!

R4: PE Router

R4#show run
!
ip vrf v
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 10.1.34.4 255.255.255.0
 ip ospf 1 area 0
 mpls ip
!
interface FastEthernet0/1
 ip vrf forwarding v
 ip address 10.1.45.4 255.255.255.0
!
router eigrp 1
 no auto-summary
 !
 address-family ipv4 vrf v
  redistribute bgp 234 metric 1 1 1 1 1
  network 10.1.45.4 0.0.0.0
  auto-summary
  autonomous-system 1
 exit-address-family
!
router ospf 1
 log-adjacency-changes
!
router bgp 234
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 234
 neighbor 2.2.2.2 update-source Loopback0
 !
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf v
  redistribute eigrp 1
  no synchronization
 exit-address-family

R5: CE Router

R5#show run
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.0
!
interface Serial0/0
 ip address 10.1.215.5 255.255.255.0
 clock rate 64000
!
interface FastEthernet0/1
 ip address 10.1.45.5 255.255.255.0
!
router eigrp 1
 network 0.0.0.0
 no auto-summary
!

Now for a couple show commands on R1:

R1#show ip route eigrp
     5.0.0.0/24 is subnetted, 1 subnets
D       5.5.5.0 [90/435200] via 10.1.12.2, 00:19:08, FastEthernet0/0
     10.0.0.0/24 is subnetted, 3 subnets
D       10.1.45.0 [90/307200] via 10.1.12.2, 00:19:08, FastEthernet0/0
R1#

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.1.215.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 1.1.1.0/24, 1 successors, FD is 128256
        via Connected, Loopback0
P 5.5.5.0/24, 1 successors, FD is 435200
        via 10.1.12.2 (435200/409600), FastEthernet0/0
        via 10.1.215.5 (2297856/128256), Serial0/0
P 10.1.12.0/24, 1 successors, FD is 281600
        via Connected, FastEthernet0/0
P 10.1.45.0/24, 1 successors, FD is 307200
        via 10.1.12.2 (307200/281600), FastEthernet0/0
        via 10.1.215.5 (2195456/281600), Serial0/0
P 10.1.215.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0
R1#

And some on R2, the PE router:

R2#show ip route vrf v

Routing Table: v
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
D       1.1.1.0 [90/409600] via 10.1.12.1, 00:31:48, FastEthernet0/0
     5.0.0.0/24 is subnetted, 1 subnets
B       5.5.5.0 [200/409600] via 4.4.4.4, 00:02:34
     10.0.0.0/24 is subnetted, 3 subnets
C       10.1.12.0 is directly connected, FastEthernet0/0
B       10.1.45.0 [200/0] via 4.4.4.4, 00:31:48
D       10.1.215.0 [90/2195456] via 10.1.12.1, 00:31:21, FastEthernet0/0

R2#show ip eigrp vrf v topology
IP-EIGRP Topology Table for AS(1)/ID(10.1.12.2) Routing Table: v

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 1.1.1.0/24, 1 successors, FD is 409600
        via 10.1.12.1 (409600/128256), FastEthernet0/0
P 5.5.5.0/24, 1 successors, FD is 409600
        via VPNv4 Sourced (409600/0)
P 10.1.12.0/24, 1 successors, FD is 281600
        via Connected, FastEthernet0/0
P 10.1.45.0/24, 1 successors, FD is 281600
        via VPNv4 Sourced (281600/0)
P 10.1.215.0/24, 1 successors, FD is 2195456
        via 10.1.12.1 (2195456/2169856), FastEthernet0/0
R2#

Take a minute to post your thoughts, and as always, happy studies.

….

 

It has been a few days, and we have received lots of great ideas.   Thank you.

When R4 receives the routes in VRF v, the EIGRP metrics are copied into extended BGP attributes, and include the information for metric, AS, route-type and more.  The iBGP updates from R4 to R2 contain all those attributes.   When R2 receives the updates, if the route type is internal (from EIGRP attributes) and the source EIGRP AS matches the local EIGRP AS we are importing to, it will then be up to the  metric to determine the best path.

If we decreased the bandwidth statement on R4 Fa0/1, or used an offset list (2,000,000 more should do the trick) on R5 out Fa0/1 (towards R4), the increase in metric would cause R2 to prefer the path through R1 for 5.5.5.0/24 instead of using the MPLS backbone.

BGP updates that contain the cost community attribute will use the EIGRP AD instead of the iBGP AD of 200 to compare routes on metric alone. In that light, another option, would be to tell R2 to ignore cost-community, with the BGP router command:

bgp bestpath cost-community ignore

Let’s take a look at the results.

Here is the baseline for before any changes:

R2#show ip route vrf v | inc 5.5.5
B       5.5.5.0 [200/409600] via 4.4.4.4, 00:02:29
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 8
Paths: (1 available, best #1, table v)
Flag: 0x820
  Not advertised to any peer
  Local
    4.4.4.4 (metric 21) from 4.4.4.4 (4.4.4.4)
      Origin incomplete, metric 409600, localpref 100, valid, internal, best
      Extended Community: RT:1:1 Cost:pre-bestpath:128:409600 0x8800:32768:0
        0x8801:1:153600 0x8802:65281:256000 0x8803:65281:1500
      mpls labels in/out nolabel/19
R2#

Now we will remove the default behavior

R2(config)#router bgp 234
R2(config-router)#bgp bestpath cost-community ignore

Cleared BGP sessions and routing tables, and waited a minute before the following show commands:

R2#show ip route vrf v | inc 5.5.5
D       5.5.5.0 [90/2323456] via 10.1.12.1, 00:00:08, FastEthernet0/0
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 8
Paths: (2 available, best #2, table v)
Flag: 0x820
  Advertised to update-groups:
        1
  Local
    4.4.4.4 (metric 21) from 4.4.4.4 (4.4.4.4)
      Origin incomplete, metric 409600, localpref 100, valid, internal
      Extended Community: RT:1:1 Cost:pre-bestpath:128:409600 0x8800:32768:0
        0x8801:1:153600 0x8802:65281:256000 0x8803:65281:1500
      mpls labels in/out 20/19
  Local
    10.1.12.1 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 2323456, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:1
        Cost:pre-bestpath:128:2323456 (default-2145160191) 0x8800:32768:0
        0x8801:1:665600 0x8802:65282:1657856 0x8803:65281:1500
      mpls labels in/out 20/nolabel
R2#

After setting it back to defaults, we could then try an offset list on R5 advertising to R4:

R5(config)#router eigrp 1
R5(config-router)#offset-list 0 out 2000000 fastEthernet 0/1

Cleared BGP sessions and routing tables, and waited a minute before the following show commands:

R2#show ip route vrf v | inc 5.5.5
D       5.5.5.0 [90/2323456] via 10.1.12.1, 00:06:28, FastEthernet0/0
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 12
Paths: (1 available, best #1, table v)
Flag: 0x820
  Advertised to update-groups:
        1
  Local
    10.1.12.1 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 2323456, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:1
        Cost:pre-bestpath:128:2323456 (default-2145160191) 0x8800:32768:0
        0x8801:1:665600 0x8802:65282:1657856 0x8803:65281:1500
      mpls labels in/out 31/nolabel
R2#

After resetting all that, implementing the following on R4, and then clearing BGP and routing, we issue the show commands again.

R4(config)#int fa 0/1
R4(config-if)#bandwidth 100

R2#show ip route vrf v | inc 5.5.5
D       5.5.5.0 [90/2323456] via 10.1.12.1, 00:00:05, FastEthernet0/0
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 20
Paths: (1 available, best #1, table v)
Flag: 0x820
  Advertised to update-groups:
        1
  Local
    10.1.12.1 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 2323456, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:1
        Cost:pre-bestpath:128:2323456 (default-2145160191) 0x8800:32768:0
        0x8801:1:665600 0x8802:65282:1657856 0x8803:65281:1500
      mpls labels in/out 23/nolabel
R2#

Thanks again to all who contributed. I encourage all RS candidates to lab this up, as well as practice MPLS with OSPF at the CEs.

Marcel posted a comment, reminding us of an excellent document written by Petr, on this topic and more. The original post from Petr which includes the link to free .PDF for this document may be found by clicking here. Thanks Marcel!


You can leave a response, or trackback from your own site.

30 Responses to “MPLS and EIGRP, going the Distance, (Admin Distance).”

 
  1. Rich says:

    - The EIGRP routes are being redistributed into MPBGP on R4 and the EIGRP attributes are passed as extended communities. The EIGRP AS numbers are the same so R2 sees them as internal EIGRP routes, therefore they have an AD of 90 not 170 and are compared to the route advertised by R1.

    - The bandwidth metric for redistribution from MPBGP into EIGRP on R2 is set to 10000 which is better than the serial link between R1 and R5, so R1 –> R2 –> R4 –> R5 is the preferred path.

    As for why the 5.5.5.0/24 prefix is listed as iBGP on R2, I’m not sure… I’m guessing the ‘via VPNv4 Sourced’ EIGRP topology output on R2 is key to the answer. Maybe a loop prevention mechanism to stop EIGRP route feedback during redistribution?

  2. Haresh says:

    Reason for preferred path through BGP is when the EIGRP route is redistributed to MP-BGP, routes has a cost attribute value set to EIGRP composite metric and BGP process will consider cost value attribute before any best path selection attribute.

  3. Amit says:

    R2′s EIGRP topology table shows that it has only one route for 5.5.5.0/24 while R1′s EIGRP topology table shows two possible routes i.e. from R5 and R2. So, I believe, because of split-horizon, R2 does not receive the update from R1 and hence there is only path to 5.5.5.0/24 for R2 via iBGP.

  4. Ronnie_Hitman says:

    Its the magic of extended communities.

    The EIGRP metrics 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.

    R2 checks the attributes received in the route, and, if route type is internal (if the MSB bit in the 0×8800 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 0×8800 is not set), the route is advertised to the CE as an external EIGRP route.

    So the metric and AD are preserved, the route via MPLS ends up as internal and wins over the route learned via serial based on the Metric.

    Regards

    Ronnie

  5. Nendy says:

    The Cost Attribute in MBGP is honored before other best-path selection options.

  6. Gabor Ivanszky says:

    This is because R1 has two routes to 5.5.5.0/24, and the route through the MPLS VPN has lower cost. So R1 stops advertising the backdoor(EIGRP) route to R2.
    The root cause of the issue is that the VPNv4 sourced EIGRP route’s cost is too low at R2:
    P 5.5.5.0/24, 1 successors, FD is 409600
    via VPNv4 Sourced (409600/0)

  7. Terron Parks says:

    Hi,

    Looking at the configs it appears R4 and R2 have auto-summary configured under the vrf v which is causing the network 5.5.5.0/24 to be classified to the major network 5.0.0.0. I need to lab it up and verify though.

    tp

  8. Brad says:

    Your missing the Site of Origin on your EIGRP peers. This lets R1/R5 behave normally; but your BGP ‘prebest path’ is enabled so that BGP takes precedence on your BGP routers.

    http://www.cisco.com/en/US/docs/ios/iproute_eigrp/configuration/guide/ire_mpls_vpn_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1057067

  9. uri says:

    It’s because of BGP Cost Community is in effect (default behavior in modern images).

  10. Abid Nazeer says:

    Its because of the BGP cost community.R4 is advertising R5 loopback
    with better metric .

  11. Edward says:

    Here is my interpretion to the result:

    1. From R1 eigrp topology table, the path to 5.5.5.5 via R2 next hop (10.1.12.2) is preferred as it is the successor route with less composite metric.

    2. R1 puts the successor route into its routing table and does not advertise to R2 the alternative path via its S0/0

    3. At R2, iBGP is only involved in the routing update with R4 for vrf v but not in the routing decision of CE network, while the routing decision of CE network 5.5.5.5 in vrf v uses eigrp

    4. From R2 eigrp topology table for vrf v, it has only one sucessor route to 5.5.5.5 learned from iBGP from R4 (4.4.4.4), so R2 only takes this path towards 5.5.5.5

  12. Fragilemohi says:

    execute bgp bestpath cost-community ignore on PE router u ll no longer see the route from MPLS Domain….:))..acutally before this SOO bgp has cost-community attribute …bgp links will get preference if they are learned before IGP..that actually doesn’t happen normally… so later they introduced POI (point of insertion )..it says bgp will get preference before any other PRotocols..and it is by default now ….

    i think i might gave u the ans why bgp route are preferred in PE…

  13. Nic Bhasin says:

    MPBGP cost community preempts everything including AD so the decision is based on lowest cost.

  14. Nic says:

    ADDENDUM
    So once the LOWER EIGRP metric route makes it to R2 ACROSS MPLS CORE, Cost community on it is used to pre-empt bestpath selection process and route is selected for redistribution into EIGRP process, where the COST is copied to the EIGRP metric. when this route arrived at R1 CE router, it is now the path with LOWEST metric and hence is chosen for FIB installation.

  15. Iman Mansouri says:

    As i believe is due to Cost Community issue.

  16. Mike says:

    seems, that cost community and bad metric through R1 for 5.5.5.0/24 make it.

  17. Marcel Lammerse says:

    The “pre-bestpath” point of insertion (POI) has been introduced in the BGP Cost Community feature to support mixed EIGRP VPN network topologies that contain VPN and backdoor links. 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 configuring BGP to consider this POI before any other comparison step.

    http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsbgpcce.html

    The cost community is seen on R2:

    R2#sh ip bgp vpnv4 vrf vpnA 5.5.5.5 255.255.255.255
    BGP routing table entry for 1:1:5.5.5.5/32, version 8
    Paths: (1 available, best #1, table vpnA)
    Not advertised to any peer
    Local
    4.4.4.4 (metric 3) from 4.4.4.4 (4.4.4.4)
    Origin incomplete, metric 20, localpref 100, valid, internal, best
    Extended Community: RT:1:1 Cost:pre-bestpath:128:156160 0×8800:32768:0 <— 128:156160
    0×8801:1:130560 0×8802:65281:25600 0×8803:65281:1500
    mpls labels in/out nolabel/20
    R2#

    And propagated to R1 as part of the BGP-EIRGP redistribution:

    R1#sh ip eigrp topology
    IP-EIGRP Topology Table for AS(1)/ID(1.1.1.1)

    Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
    r – reply Status, s – sia Status

    P 5.5.5.5/32, 1 successors, FD is 158720
    via 10.1.12.2 (158720/156160), FastEthernet2/0 <—
    via 10.1.215.5 (2297856/128256), Serial1/0
    ..

    R1 chooses the one with the lowest cost, which is advertised by R2.

  18. Marcel Lammerse says:

    It seems that, because of this, administrative distance, is not a factor for consideration in the bestpath selection process.

  19. Larynx says:

    IMHO it’s a problem of route feedback: BGP on R2 receives 5.5.5.0/24 from R4′s bgp slightly before it receives it from R1 (the reason being the slow serial0/0 between R1 and R5, while the R2-R3-R4 is all fastethernet).

    R2 then advertises that route to R1 because it’s redistributing BGP into EIGRP’S “v” vrf.
    At this point R1′s eigrp does not advertise that same route out f0/0 because of split horizon’s rule of not advertising a route out the interface on which that route was learnt
    The output on R1 clearly says that R1 sees that route behind R2

    D 5.5.5.0 [90/435200] via 10.1.12.2, 00:19:08, FastEthernet0/0

    R2 therefore simply has no EIGRP route to 5.5.5.0/24 to choose from, the only one it has is from R4 via BGP, and it uses that one.

    A reboot of R3 or R4 would cause the BGP route to be lost on R2, which then would stop advertising it to R1, and R1′s EIGRP would be free to advertise it to R2. When R2 sees again a BGP route to 5.5.5.0/24 it’s “too late” because the EIGRP has already won: R2 would apply split horizon and would not advertise that same router back to R1.

  20. JL says:

    R2 preferred the BGP route over the eigrp route as a result of using pre-bestpath POI. R2 looks at the composite metirc advertised by R4 before going through the normal BGP selection process. This makes R2 to install the BGP route and redistribute into eigrp and advertise it out to R1.
    Please correct me if i am wrong
    Thanks

  21. GLB says:

    This was really good, i had only done this type of lab before with OSPF and sham links, it took me some digging but pretty sure this is the answer:

    BGP Cost Community Support for EIGRP MPLS VPN PE-CE with Backdoor Links The “pre-bestpath” point of insertion (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. No configuration is required. This feature is enabled automatically for EIGRP VPN sites when Cisco IOS Release 12.0(27)S is installed to a PE, CE, or back door router.

    http://www.cisco.com/en/US/docs/ios/iproute_bgp/configuration/guide/irg_cost_comm_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1054113

    I was also able to turn this ‘on/off’ with bgp bestpath cost-community ignore

    And also by making the metric extremly worse on R4 f0/1 ; R2 will choose the path through R1 to get to 5.5.5.0

    R2#sh ip route vrf v 5.5.5.0
    Routing entry for 5.5.5.0/24
    Known via “bgp 234″, distance 200, metric 409600, type internal
    Redistributing via eigrp 1
    Advertised by eigrp 1 metric 1 10000 1 1 1
    bgp 234 (self originated)
    Last update from 4.4.4.4 00:16:30 ago
    Routing Descriptor Blocks:
    * 4.4.4.4 (Default-IP-Routing-Table), from 4.4.4.4, 00:16:30 ago
    Route metric is 409600, traffic share count is 1
    AS Hops 0

    R4(config)#int f0/1
    R4(config-if)#delay 16777215

    R2#sh ip route vrf v 5.5.5.0
    Routing entry for 5.5.5.0/24
    Known via “eigrp 1″, distance 90, metric 2323456, type internal
    Redistributing via eigrp 1, bgp 234
    Advertised by bgp 234
    Last update from 10.1.12.1 on FastEthernet0/0, 00:00:01 ago
    Routing Descriptor Blocks:
    * 10.1.12.1, from 10.1.12.1, 00:00:01 ago, via FastEthernet0/0
    Route metric is 2323456, traffic share count is 1
    Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit
    Reliability 255/255, minimum MTU 1500 bytes
    Loading 1/255, Hops 2

  22. Ted says:

    I’m going to say it’s because of BGP POI and Cost Community.

  23. Lots of great ideas! Thank you all. I have added comments to the bottom of the original post, with a few examples of a solution as well.

    Thanks again everyone.

  24. Tammy – You are exactly right.

    Great eye. I had been adding and removing commands, then copying them to the blog. The output of the show commands are correct, and I had copied in the piece where I had negated the command. “no” has been removed from bgp bestpath in the post.

    Thanks.

  25. Tammy Burley says:

    Maybe I’m still confused, but I think there is some confusion in second command where you state “remove the default behavior” and issue the command “no bgp bestpath cost-community ignore.” This would actually be restoring the defualt behavior to allowing the router to use cost-community. Right?

    Using the “bgp bestpath cost-community ignore” would result in m-bgp routes and eigrp routes being compaired per Admin Distance instead of the values in the cost attribute. EIGRP original metrics are carried in the Cost attribute.

    Per the doc CD:

    bgp bestpath cost-community ignore

    To configure a router that is running the Border Gateway Protocol (BGP) to not evaluate the cost community attribute during the best path selection process, use the bgp bestpath cost-community ignore command in router configuration mode. To return the router to default operation, use the no form of this command.

    bgp bestpath cost-community ignore

    no bgp bestpath cost-community ignore

  26. Marcel Lammerse says:

    Awesome article! Someone pointed out an INE blog article that would have saved me a lot of time figuring this one out ;)

    http://blog.ine.com/2010/04/29/understanding-eigrp-soo-and-bgp-cost-community/

    Excellent stuff.

  27. Michal says:

    hello, thank you , good article and nice pedagogical insight.
    wishing you great summer holidays 2010 !
    Michal

  28. Eugene says:

    Increase delay on CE-PE links and decreased at CE-CE links or just via route-map which will increase metric at PE-PE links.

    The show ip eigrp vrf v topology is the command that assists in this scenario as to determine metrics/cost.

  29. Rav says:

    I am getting slightly different situation from above. My CE1 and CE2 are constantly flapping between routes learned within themselves and the routes learned from their respective vrf.

    CE1 — PE1—
    |
    |
    CE2—- PE2—-

    any idea how can i ask CEs to prefer routes from their respective vrfs?

    even though , i applied delay on their interfaces, it still constantly fights.

    even ran #sh ip eigrp events
    but getting some poisioned squashed…message

 

Leave a Reply

Categories

CCIE Bloggers