Redistributing EIGRP Load-Balanced Paths into BGP - Only One Imported?

[casanavep]

I am redistributing load-balanced equal metric dual-path EIGRP routes into a BGP process. Only the first listed route is being imported. BGP is seeing it as only one available path. What am I missing?

PE_PoP-01#sh ip route vrf GroupA 192.168.155.163

Routing Table: GroupA
Routing entry for 192.168.155.160/28
  Known via "eigrp 65500", distance 90, metric 490752, type internal
  Redistributing via bgp 65500, eigrp 65500
  Advertised by bgp 65500
  Last update from 172.25.77.12 on GigabitEthernet0/0/1.771, 05:42:57 ago
  Routing Descriptor Blocks:
  * 172.25.77.12, from 172.25.77.12, 05:42:57 ago, via GigabitEthernet0/0/1.771
      Route metric is 490752, traffic share count is 1
      Total delay is 20 microseconds, minimum bandwidth is 5221 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 36/255, Hops 1
    172.25.77.4, from 172.25.77.4, 05:42:57 ago, via GigabitEthernet0/0/1.770
      Route metric is 490752, traffic share count is 1
      Total delay is 20 microseconds, minimum bandwidth is 5221 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 47/255, Hops 1

PE_PoP-01#sh ip cef vrf GroupA 192.168.155.163
192.168.155.160/28
  nexthop 172.25.77.4 GigabitEthernet0/0/1.770
  nexthop 172.25.77.12 GigabitEthernet0/0/1.771
PE_PoP-01#

PE_PoP-01#sh ip bgp vpnv4 vrf GroupA 192.168.155.163
BGP routing table entry for 65500:1:192.168.155.160/28, version 461
Paths: (1 available, best #1, table GroupA)
Multipath: eiBGP
  Not advertised to any peer
  Refresh Epoch 1
  Local
    172.25.77.4 from 0.0.0.0 (172.25.77.255)
      Origin incomplete, metric 490752, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:65500:1 Cost:pre-bestpath:128:490752
        0x8800:32768:0 0x8801:65500:512 0x8802:65281:490240 0x8803:65327:1500
        0x8806:0:0
PE_PoP-01#

router bgp 65500

bgp log-neighbor-changes

maximum-paths 6

maximum-paths ibgp 6

!

address-family ipv4 vrf Group1

  bgp router-id auto-assign

  redistribute eigrp 65500

  maximum-paths eibgp 4

exit-address-family

[Kishore Chennupati]

Hello,

AFAIK ,the maximum-paths eibgp command is used to configure BGP multipath load  sharing in an MPLS L3VPN using eBGP and iBGP routes. Essentially saying that the PE-CE Routing protocol has to be BGP.

In your case, you are redistributing the prefixes from EIGRP into BGP hence the maximum-paths eibgp doesn't take affect.

Someone can provide more expert answer on this

HTH

[casanavep]

Yes, I beleive you are correct. What you don't see (removed), is that these routes are being shared with BGP peers. First, I have to get the importing of routes into the BGP process. Once I have the importing (redistrobution) working, I should be able to appropriately share dual path routes with peers. Since it is not seen locally in the BGP process and two feasable paths, I know I have no ablible to advertise it as so. Please let me know if this makes sence or if I am seeing this wrong.

This is begin used for VRF-lite route leaking which is dependant on BGP for the cross VRF import/export process.

-Pete

[casanavep]

This is occurng on an ASR1000 running 15.1(3)S0a

[Peter Paluch]

Hello Pete,

This is actually a very good question. Redistributing unequal cost paths is a special case, as these are supported only by EIGRP - no other routing protocol is able to insert such routes into the routing table. In addition, there is a problem with representing these routes in the destination routing protocol after the redistribution - in IGP protocols in general, there is no way of advertising two identical routes with two different metrics from a single router. It is also to be noted that the unequal-cost load balancing in EIGRP internally relies on the usage of feasible distance to avoid routing loops, and this concept does not exist in other routing protocols. I am not completely sure here but I have a feeling that redistributing worse-path routes could eventually lead to routing loops - I am not certain but I do have a generally bad feeling about it

Again, the BGP is a special case, as it theoretically could carry two identical routes, each differentiated by a different corresponding next hop and the  metric - but even then there would be problems with the best-path algorithm in BGP - each router receiving these two routes would eventually select and further advertise just one of those.

So I am afraid that it is not possible after all to redistribute worse-path routes from EIGRP to a different routing protocol, even if they may be present in the local routing table.

Anyone else having his/her own view on this interesting issue?

Best regards,

Peter

[milan.kulik]

Hi Peter,

bgp additional-paths install

http://www.cisco.com/en/US/customer/docs/ios/iproute_bgp/command/reference/irg_bgp1.html#wp1111704

might be an interesting option here.

AFAIK, this BGP feature is still in DRAFT status, no RFC yet.

But available in some Cisco IOSes.

I have never tested that yet.

Still I agree with you, redistributing multiple routes for the same prefix might be dangerous.

Even if equal metric paths do exist in EIGRP.

What if next-hop-self would be used for some neighbors? How would the router differenciate between particular paths then?

Or would it send just one prefix to some neighbors while two prefixes to other neighbors?

BR,

Milan

[casanavep]

Thanks Peter and Milan.

Both paths are equal metric, so I would "assume" importing would be fine. I tried the "additional-paths" command to no avail. The is a stub remote with two equal cost links to the PoP. The office needs both active for full access to bandwidth, so active active is desired. 99% of the branch office's bandwidth consumption is pull from a single network prefix, so manual traffic engineering would do little if this single network couldn't use both paths. This is my conundrum.....

[casanavep]

Just as an update, after working with TAC we determined this WAS not possible. Notice I said "was." Thank you Cisco for new features!

Cisco just added the "route-replicate" feature below the "VRF definition" area of the configuration. This allows for load-balanced IGP route sharing between VRFs. This definitely simplifies the route leaking experience. No more dependancy on BGP as a transport for VRF import and exports.

"The route replication feature in EVN (EVN deployment not required for this feature) removes the dependency on BGP and any additional BGP attributes such as route target and route distinguisher. Route replication allows each EVN to have direct access to the Routing Information Base (RIB), removing the need to duplicate routing tables or routes, and saving CPU and memory. Route redistribution is not required between VNs for the users and services connected to a local router. Where possible, to eliminate the need of redistributing routes, the recommendation is to implement route replication on a router that is directly connected to the server subnet as illustrated in Figure 4."

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6557/ps6604/whitepaper_c11-638769.html

[Peter Paluch]

Hello,

Thanks for letting us know - this is very interesting!

Best regards,

Peter