Hi John, Indeed, how a locally originated route gets into your BGP RIB is totally up to your config. I'm not trying to change any behaviour there. In our case, they don't come from the kernel at all (e.g. via zebrad) - we just run a standalone bgpd, without zebrad. We advertise routing beacons from our BGP collectors via:
router bgp 12654 network x.x.x.x/24 The issue is that when dumping out an MRT RIB, these BGP routes have no external peer to associate with, so they end up being associated with whatever is the first peer in the MRT peer_index_table (index 0). This looks very peculiar in the resulting MRT file. That's all this fixes (by creating a placeholder peer for them to be associated with). But this only ever comes up if you deliberately originate routes and then dump MRT RIBs from bgpd. Cheers Colin On 11/05/16 19:22, John Kemp wrote: > > 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 > -- Colin Petrie Systems Engineer RIPE NCC RIS Project _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
