Searching for the status of 4-byte ASN support in quagga I couldn't see a word on this in the official mailing lists at http://lists.quagga.net/ But after a little googling I found Paul Jamka's weblog http://blogs.sun.com/roller/page/paulj?catname=%2FNetworking which (in the March 10 entry) says: The short answer is that Quagga is part-way towards 4-byte ASN support [...] That leaves the following (generally) as still to be implemented: 1. The 4-byte-supported BGP capability 2. Extending the unit tests with equivalent 4-byte forms and verifying the AS_PATH parser and transformational functions. 3. Using the appropriate encoding for AS_PATH according to the remote peer 4. Adding support for the 2<->4 byte transition mechanisms (unit tests implied) 1, 2 and 3 should be quite easy, 2 weeks about, including testing, and would get bgpd to the stage which the draft RFC calls a "NEW" speaker and interoperate fully with other "NEW" speakers. It would also be able to speak to "OLD" peers, provided no 4-byte wide ASNs are involved. Support for these items I hope to see in Quagga before the end of the year. That leaves 4, which isn't as easy, further I am not very optimistic on its chances of working. I suspect the internet would be in trouble if we end up relying on the 4-byte transition mechanism to work. I really hope all deployed speakers of significance end up being upgraded to "NEW" (ie corresponding to at least 1,2 and 3 above) well before the first 4-byte ASNs are issued, so that we never have to find out how well the transition mechanisms might work.. His hopes may prove faint, especially when (according to the proposed policy) RIRs start allocating/assigning 4-byte ASNs by default come 1/1/2009; it'll be interesting times. However, it is clear the issue has the quagga author(s) attention; there's no need for RIPE NCC to step in. -- Rene P.S. Interesting side fact: the last real Quagga died in Artis, Amsterdam's zoo, some 123 years ago. :)