HI Martin, Thanks. that is the case I had in mind.
There is no issue then. Andrew > -----Original Message----- > From: Martin Winter [mailto:[email protected]] > Sent: Tuesday, November 03, 2015 4:40 AM > To: Andrew Qu > Cc: Paul Jakma; J Yu; Jacqueline Yu; [email protected] > Subject: Re: [quagga-dev 13461] Kernel routes does not get updated when > neighbor remove the "next-hop-self" configuration > > 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 ************* Email Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
