01-27-2012 05:25 AM - edited 03-04-2019 03:02 PM
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
01-27-2012 07:11 AM
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
01-27-2012 07:30 AM
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
01-28-2012 05:04 PM
This is occurng on an ASR1000 running 15.1(3)S0a
01-30-2012 01:03 AM
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
01-30-2012 04:32 AM
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
01-30-2012 05:15 AM
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.....
02-27-2012 07:03 PM
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
02-28-2012 02:01 AM
Hello,
Thanks for letting us know - this is very interesting!
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide