On Mon, Jan 04, 2010 at 01:30:39PM +0100, Erik Romijn wrote: > Hi Ondrej, > > Ondrej Zajicek wrote: > > I am implementing MRT dump feature in BIRD Internet Routing Daemon [1] > > I have done quite some of the work on implementing AS4 MRT support in > Quagga, and am one of the current maintainers of libbgpdump.
Thank you for the answer. > > - The most important question is whether difference in BGP4MP_MESSAGE > > and BGP4MP_MESSAGE_AS4 is just in MRT message header format, or if it > > is also semantic information whether these BGP messages were received > > in 'AS4-style' session or 'old' session (and therefore whether > > AS_PATH attribute in UPDATE messages contains 2B or 4B AS numbers). > > For the current implementation in Quagga there is semantic information. > The code checks whether the AS4 capability is present on the session > and, if so, uses BGP4MP_MESSAGE_AS4. If the AS4 capability is absent, it > will use BGP4MP_MESSAGE and write the AS_PATH and AS4_PATH attributes as > received from the peer. I examined the behavior of Quagga and found this behavior, but with one exception - first message (OPEN meesage) of the session is always logged as BGP4MP_MESSAGE, even if it contains AS4 capability. This seems a bit crazy to be, for example it does not allow to store real AS numbers. I tested Quagga version 0.99.6, so i don't know if it is not fixed in later releases, but latest bgpdump tool expects this behavior - it parses OPEN messages stored in BGP4MP_MESSAGE_AS4 incorrectly. > However, I am not entirely sure whether it should be an explicit > requirement to store this semantic information in this way. This has two sides - if it is not a requirement, it cannot be expected by tools processing stored MRT dumps. And current bgpudmp tool expects that. It fails to parse AS_PATHs in 'old-style' UPDATEs stored BGP4MP_MESSAGE_AS4. -- Ondrej 'SanTiago' Zajicek (email: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
