Hi Colin, Thank you for your answer, I was also suspecting file corruption, although I have to admit that I was hoping that it would not be it :) I guess my next move is to understand why some of my files get corrupted. Thank you agin for the help! Cheers, Alexis

On 10 Oct 2015, at 04:22, Colin Petrie <cpetrie@ripe.net> wrote:

Hi Alexis,

I would suspect you have a corrupted dump file.

If I run 'bgpdump -v' over your provided dump file, I get the same output as you, but also on stderr:

[warn] ERROR attribute is truncated: expected=98 remaining=17 [warn] ERROR attribute is truncated: expected=129 remaining=16 [warn] ERROR attribute is truncated: expected=65535 remaining=29 [warn] ERROR attribute is truncated: expected=65535 remaining=18 [warn] ERROR attribute is truncated: expected=98 remaining=25 [warn] ERROR attribute is truncated: expected=65535 remaining=11 [warn] ERROR attribute is truncated: expected=65535 remaining=1 [warn] ERROR attribute is truncated: expected=65535 remaining=1 [warn] process_zebra_bgp_message: unsupported AFI 4096 [warn] process_zebra_bgp_message: unsupported AFI 4096 [warn] process_zebra_bgp_message: unsupported AFI 4096 [warn] process_zebra_bgp_message: unsupported AFI 4096 [warn] process_zebra_bgp_message: unsupported AFI 4096 [warn] process_zebra_bgp_message: unsupported AFI 4096 [error] bgpdump_read_next: incomplete dump record (0 bytes read, expecting -1)

So a length field somewhere is telling the parser to read an incorrect amount of data from the stream, which then throws off the field alignment.

You'd probably need to stare at your MRT file with a hex editor for a while if you want to find the problem :)

Of course, how bgpdump handles it (or doesn't!) might be better :) it could probably do a better job of trying to re-align on later messages.

Hope this helps,

Cheers, Colin

On 09/10/15 19:35, Alexis Fasquel wrote:

...

Hello everyone,

I’ve been using BGPDump to collect BGP data across multiple BGP server. Unfortunately, I’ve been having some issues parsing some MRT files.

So I have a file (provided in attachment) that has been created by a Quagga instance (quagga-0.99.22.1-2013051601). All the beginning of the file seems to be parsed correctly, but at some point, I get a message with unknown attributes. As you can see on the screenshot below, the strange part about it is that the attribute type is supposedly 0 —which is not a correct attribute type if I’m referring to the RFC. Different versions of bgpdump have been tested, without any changes.

And the actual issues come up right after: every announcement after this message seems to have something wrong (wrong prefix length/wrong AS path values…):

Does anyone already encountered such troubles? Could it be a bug from BGPDump somewhere?

Let me know if you have any idea or want some more detail about the issue.

-- Colin Petrie Systems Engineer RIPE NCC