Duplicated PEER_INDEX_TABLE in rit mrt file
Hello, I am using bird-2.0.7 on Debian 10 to dump the RIBs tables. The tables generated for IPv4 are fine when parsed using mrt2bgpdump or bgpscanner. But when I parse the IPv6 table, mrt2bgpdump doesn't return anything and bgpscanner gives the following error: bgpscanner: master6.mrt: bad RIB dump, duplicated PEER_INDEX_TABLE, skipping rest of file. Can you help me? Thank you in advanced. Santiago.
On Sat, Oct 10, 2020 at 01:38:35PM -0300, Santiago Aggio wrote:
Hello, I am using bird-2.0.7 on Debian 10 to dump the RIBs tables.
The tables generated for IPv4 are fine when parsed using mrt2bgpdump or bgpscanner.
But when I parse the IPv6 table, mrt2bgpdump doesn't return anything and bgpscanner gives the following error: bgpscanner: master6.mrt: bad RIB dump, duplicated PEER_INDEX_TABLE, skipping rest of file.
Hello (Noticed while looking for some missed / forgotten e-mails) Thanks for the bugreport. For IPv6 tables (due to ugliness of how MP-BGP handles bgp_nexthop), we forgot to generate fake MP_REACH_NLRI attribute with bgp_nexthop. The resulting files worked with bgpdump (which i used for tests), just displayed some default bgp_nexthop. Fixed here (now it works with bgpdump, mrt2bgpdump and bgpscanner): https://gitlab.nic.cz/labs/bird/-/commit/d774f6d721b0e52ed800c4b9a3a482c8ce9... -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello Ondrej, On 14.01.2021, 04:03, "Ondrej Zajicek" <santiago@crfreenet.org> wrote:
Thanks for the bugreport. For IPv6 tables (due to ugliness of how MP-BGP handles bgp_nexthop), we forgot to generate fake MP_REACH_NLRI attribute with bgp_nexthop.
The resulting files worked with bgpdump (which i used for tests), just displayed some default bgp_nexthop.
Fixed here (now it works with bgpdump, mrt2bgpdump and bgpscanner):
https://gitlab.nic.cz/labs/bird/-/commit/d774f6d721b0e52ed800c4b9a3a482c8ce9...
I did some checks in my environment and it works only for small dumps. I checked both vanilla 2.0.7 + cherrypicked fix as well as vanilla master. After some* number of entries dumped, it stops encoding MP_REACH_NLRI until end of the dump. Next dump appended to the same file is exactly the same. It seems reproducible for me - for given set of routes, it stops encoding exactly on the same route. I'll send you the dumps off-list to not pollute archives. I did check with mrtparse/examples/print_all.py for two dumps and it stopped encoding somewhere below sequence number 2^14 (I saw last NLRI @ 0x3FF2 and 0x3FF0), FWIW. *some, e.g.: When I have 15687 ipv4 routes + 1465 ipv6 routes, 730 of them miss MP_REACH_NLRI When I have 15533 ipv4 routes + 1448 ipv6 routes, 557 of them miss MP_REACH_NLRI When I have 18010 ipv4 routes + 1801 ipv6 routes, all of them miss MP_REACH_NLRI Piotr
On Thu, Jan 21, 2021 at 06:25:08PM +0000, Wydrych, Piotr wrote:
I did some checks in my environment and it works only for small dumps. I checked both vanilla 2.0.7 + cherrypicked fix as well as vanilla master. After some* number of entries dumped, it stops encoding MP_REACH_NLRI until end of the dump. Next dump appended to the same file is exactly the same. It seems reproducible for me - for given set of routes, it stops encoding exactly on the same route. I'll send you the dumps off-list to not pollute archives.
Thanks, fixed: https://gitlab.nic.cz/labs/bird/-/commit/5d414309ec5a01024d4de4c4f9521f8daa5... -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (3)
-
Ondrej Zajicek -
Santiago Aggio -
Wydrych, Piotr