Hmmm, well. Aren't the locally originated routes affected by external configuration? IE, you have a bunch of network interfaces, and they have some config, and your "kernal" gets some routes when you configure those...
My gut says I don't want that to pollute my routing process. I could give my specific case, but I think you could find a lot of cases where people don't want their local configuration leaking into their peering configuration. Or to put it another way, by default I don't think I want my OS configuration to affect my BGP configuration in my table dumps... again by default. John Kemp On 5/11/16 2:56 AM, Colin Petrie wrote: > Hello everyone, > > I've been working on a small patch to correct an issue in the BGP MRT > table dump code. It's a quick'n'easy fix initially, and I'd appreciate > any feedback on making it better :) > > Issue: > > When the BGP table dump code runs, it generates the peer_index_table. > This walks the list of peers, and dumps out their IP, ASN, address > family, etc. It also sets the peer index number in the peer struct. > > Then the code walks the RIB, and for each prefix, writes out RIB > entries, that refer to the peer index number. > > However, when it finds prefixes that are locally originated, the > associated peer is the 'self' peer, which wasn't in the list of peers, > never gets an index number assigned, but because it is calloc'd, the > index number is set to 0. > > End result: locally-originated routes are associated with whichever peer > happens to be first in the list of remote peers in the index table :) > > Example (from one of our route collectors) - these are two of our > originated prefixes (bgpdump output): > TABLE_DUMP2|1457568002|B|12.0.1.63|7018|84.205.80.0/24||IGP|193.0.4.28|0|0||NAG|64512 > 10.255.255.255| > TABLE_DUMP2|1457568006|B|12.0.1.63|7018|2001:7fb:ff00::/48||IGP|::|0|0||NAG|| > > The prefixes are announced by us (note it has an empty AS PATH (the > field after the prefix)) but also looks like it was received from AS7018 > (12.0.1.63). In fact, the AS7018 peer just happens to be the first peer > in the index table. > > Fix: > > The simplest fix (which is also the method adopted by both OpenBGPd and > the BIRD mrtdump branch) is to create an empty placeholder 'peer' at the > start of the peer index table, for all the routes which are locally > originated to refer to. > > I've attached a patch for this. > Here's a resulting bgpdump output after the patch: > TABLE_DUMP2|1458828539|B|0.0.0.0|0|93.175.150.0/24||IGP|0.0.0.0|0|0||NAG|| > Now it is more obvious that the prefix is locally originated. > > There are more complicated potential ways of fixing it > 1) skip the local routes when dumping the RIB. This leads to questions > about what an MRT table dump *should* contain :) > 2) include the 'self' peer in the list of peers used to generate the > index table. > etc etc. > > But I'm quite happy with my 'create a fake peer, and associate local > routes with it' method :) > > Your thoughts and feedback are welcome! > > Regards, > > Colin Petrie > Systems Engineer > RIPE NCC RIS Project > > > > > > > > > > > > _______________________________________________ > Quagga-dev mailing list > [email protected] > https://lists.quagga.net/mailman/listinfo/quagga-dev > _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
