Dear Tom, In one of production routers I have two providers with BGP sessions to both. For BGP I'm using Quagga. In Shorewall 4.4.17 all worked well. But when I try to upgrade to 4.4.22.3, BGP is stopping working properly. After debugging zebra/bgpd, studying my context and Quagga sources I determined, as follows:
Before upgrade on providers interfaces (eth2 and eth3) I had this route's: > default via 195.187.251.225 dev eth3 (above is from interface setup) > 85.128.60.176/30 dev eth2 proto kernel scope link src 85.128.60.178 > 195.187.251.224/30 dev eth3 proto kernel scope link src 195.187.251.226 But after upgrade Shorewall adds extra one route for every provider interface: > 85.128.60.177 dev eth2 scope link src 85.128.60.178 > 195.187.251.225 dev eth3 scope link src 195.187.251.226 There is nothing wrong with direct route to the gateways based on interface source address, although it looks like the redundancy of roads /30. But for unknown reasons by the end, zebra explores the interface activity by looking for routes to him in the RIB. If hits the road /30, is considered interface to be active, but if it is the road /32, will match it likely and then considered interface to be inactive and BGP routes coming for him are not injected. It is interesting that at the beginning, zebra removes route /32, but only one. > 2011/10/31 23:25:23 debugging: ZEBRA: rib_delnode: 0.0.0.0/0: rn 0x1656eb80, > rib 0x1656ff30, removing > 2011/10/31 23:25:23 debugging: ZEBRA: rib_delnode: 195.187.251.225/32: rn > 0x1656fe58, rib 0x1656ffb8, removing > 2011/10/31 23:25:23 notifications: ZEBRA: Zebra 0.99.17-realms starting: > vty@2601 Hence, with the new version of Shorewall, BGP routes are injected to the only one providers interface (this, for which zebra deleted route). Workaround is simple. It is sufficient to insert into /etc/shorewall/started script: > ip route del 85.128.60.177 dev eth2 scope link src 85.128.60.178 table main > ip route del 195.187.251.225 dev eth3 scope link src 195.187.251.226 table > main and started after this quagga/bgpd/zebra injects routes to all providers interfaces. I read the code bgpd/zebra and quagga mailing lists. So far, it is too difficult for me, to determine what is happening in the code of a zebra, the more that I'm working on a fairly new kernel 3.0.8 and can do tests only in service time between 2:00 and 3:00 am. So I'm not able to improve the code. Perhaps after a few days studying the code I can improve it. Or or maybe someone else does. However, I have a question: for what are these additional /32 routes to the gates, which You are adding to the table main? This may result from some mine shorewall setup, which I should not to do (or those who did not and I should)? BTW, Shorewall is great job. Thanks. Best regards -- Andrzej Odyniec ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
