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