Andrew,
On 2 Nov 2015, at 12:47, Andrew Qu wrote:
Hi Paul,
I have a concern about your fix.
In the case of ECMP, your fix will completely remove the FIB entry
which will
cause the complete removal of the FIB entry in hardware and cause the
traffic dropped
if there is no default network till the new update of the same FIB
entry arries.
I think you speak about the case with iBGP ECMP.
I did a quick check of Paul’s version of the fix with a ECMP config
(3 iBGP neighbors, initially all good next hops, then change the route
on the 2nd nexthop)
Short answer: it works in my test scenario (tested IPv4 only so far).
Long answer:
BGP config would be like this (with the ecmp enabled):
router bgp 500
bgp router-id 192.168.1.101
neighbor 192.168.1.1 remote-as 500
neighbor 192.168.2.1 remote-as 500
neighbor 192.168.3.1 remote-as 500
maximum-paths ibgp 4
So here is the initial view (with all good routes):
quagga# sh ip bgp
BGP table version is 0, local router ID is 192.168.1.101
Status codes: s suppressed, d damped, h history, * valid, > best, =
multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*=i172.16.1.0/24 192.168.3.1 100 1000 0 65001
65100 i
*=i 192.168.2.1 100 1000 0 65001
65100 i
*>i 192.168.1.1 100 1000 0 65001
65100 i
Total number of prefixes 1
quagga# sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, A - Babel,
> - selected route, * - FIB route
C>* 127.0.0.0/8 is directly connected, lo
B>* 172.16.1.0/24 [200/100] via 192.168.1.1, eth1, 00:00:29
* via 192.168.2.1, eth2, 00:00:29
* via 192.168.3.1, eth3, 00:00:29
C>* 192.168.1.0/24 is directly connected, eth1
C>* 192.168.2.0/24 is directly connected, eth2
C>* 192.168.3.0/24 is directly connected, eth3
And after the 2nd peer updates the route:
quagga# sh ip bgp
BGP table version is 0, local router ID is 192.168.1.101
Status codes: s suppressed, d damped, h history, * valid, > best, =
multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*=i172.16.1.0/24 192.168.3.1 100 1000 0 65001
65100 i
* i 1.1.1.1 100 1000 0 65001
65100 i
*>i 192.168.1.1 100 1000 0 65001
65100 i
Total number of prefixes 1
quagga# sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, A - Babel,
> - selected route, * - FIB route
C>* 10.211.55.0/24 is directly connected, eth0
C>* 127.0.0.0/8 is directly connected, lo
B>* 172.16.1.0/24 [200/100] via 192.168.1.1, eth1, 00:00:02
* via 192.168.3.1, eth3, 00:00:02
C>* 192.168.1.0/24 is directly connected, eth1
C>* 192.168.2.0/24 is directly connected, eth2
C>* 192.168.3.0/24 is directly connected, eth3
And from the bgpd log, here is the update processing:
[…]
2015/11/03 04:24:23 BGP: 192.168.2.1 rcvd UPDATE w/ attr: nexthop
1.1.1.1, origin i, localpref 1000, metric 100, path 65001 65100
2015/11/03 04:24:23 BGP: 192.168.2.1 rcvd 172.16.1.0/24
2015/11/03 04:24:23 BGP: 172.16.1.0/24 remove mpath nexthop 1.1.1.1
peer 192.168.2.1
2015/11/03 04:24:23 BGP: Zebra send: IPv4 route add 172.16.1.0/24
nexthop 192.168.1.1 metric 100 count 2
2015/11/03 04:24:23 BGP: Zebra send: IPv4 route add [nexthop 1]
192.168.3.1
[…]
If I get it right, the difference is that there is no “delete route”
from bhp sent to zebra in the case of ECMP - it’s
a different math removal instead.
- Martin Winter
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
