Parsing issues with bgpdump (unknown attribute 0)

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