Log of the as4 patch project
Released the bug fix from yesterday.
Bug report received. There is a setup in which the as-path synthesizing
(or do you call it reconciliation) dumps core. Found and reported by
Katsuyasu Toyama, who also supplied a correct patch for correcting
the problem which was found by his collegue Arifumi Matsumoto.
Will provide the patch shortly as an incremental
patch only because it contains just a few lines (and due to lack of time
for putting together a complete patch again).
Paul Jakma has begun to work on the integration into mainline,
his mail on quagga-dev.
Only as number format being supported will be asplain, and that will
be for input and output. Extended community syntax will change again,
too. For more details or a way to influence things to take another way
(or to enforce that this is as it should be), please read the thread
starting with the abovementioned mail.
I will look over the adapted patch ASAP, but due to lack of time
this will take a while. The good thing is that we *will* get this into
quagga mainline in the foreseeable future - and I will get rid of
maintaining the patch, though it was fun to do this ;-).
choose something else to do next, maybe bgp multipath.
The webcast of my quagga AS4 presentation at RIPE-54 is available
on the RIPE website.
Not that many changes in CVS up to now since I put out version 07.
Main change has been the memory saving patch by Paul.
Well, anyway, I'll rebase onto the then current CVS version again after
my summer holidays, i.e. somewhen in August.
has replaced draft-ietf-idr-as4bytes-13.txt. You could also say it
the other way round: the draft has been promoted to a RFC.
No semantical changes in the document, so no changes in the patch
Released v07. Further information is on the
main page. I should never
again give out ETAs for new patches, because I am always faster than
I plan ;-).
Wow, new record: Three minutes from posting a new version to the first
download. But I would guess there was just someone out there really lucky
not visiting the site 5 minutes earlier.
Back from RIPE-54, where I held my presentation
about quagga and the AS4 patch (296674 Bytes) (oups, had the link wrong for a day -
but never mind, the presentation is also available from the
I found an email telling me about
the quagga AS4 patch not following a SHOULD in RFC4271. Well, that is
not a MUST - but I will update the AS4 patch sortly to be in sync with
the SHOULD. In short, the order of the attributes in the update messages
are not as they SHOULD be. I am not violating the RFC, and by using
a wrong order some routers were detected which do violate a MUST in the
same RFC, namely that attributes MUST be accepted in any order. Thus,
quagga AS4 helped debugging the rest of the router world ;-).
Conclusion: if one of your peers has become unstable when you
started using quagga with AS4 support (up to v06), you may have a peer which relies
on the attribute order which is against RFC4271.
Released v06, based on quagga cvs 20070430, which is basically 0.99.7.
Version 06 is more or less just a re-base to be up-to-date again and
provide newcomers with an easy entry when they use a current cvs.
Reading current posts on quagga-users I guess the next release will become
when Paul commits the shrinkage of "struct attr" - and that is something
where I will have to go through the code again and will not be able to
"just apply the changes" because the AS4 stuff will have to stick to the
spirit of Pauls memory shrinkage and act accordingly...
My quagga presentation at RIPE-54 in Tallinn has been scheduled to be at
the Closing Plenary on Friday (changes in the schedule are still possible). I
hope there will still be people there and that not everybody has to
catch an early flight ;-). After the presentation the pdf will be made
available via the RIPE pages and here.
Quagga 0.99.7 is out. And v05 of the AS4 patch does not patch cleanly into
it. So you may expect v06 soon, based on 0.99.7.
The quagga AS4 project is being referenced all over the place nowadays -
I just stumbled over
an article on the "Swiss Internet Scene"
(in German) (posted on Friday, 13th April 2007)
which mentiones the AS4 patches for quagga and
openbgpd, and mentiones that neither the C, J nor F vendor has an
AS4 capable stable release available yet.
Again, it is
who gives news about an ipv6 advertisement with an AS4 origin.
Our AS4 activist Jac Kloots gave
another update regarding ipv6
announcements from 3.5, and tells us that he is working with
Erik at RIPE NCC on RIS peerings.
Jac Kloots found a bug, but it is only a cosmetical one -
a statistic output which contains an as number is not printed in
the chosen as number format, but always in asplain.
Made a small patch available for that. I hope things like this are
the only things which can be found in the AS4 patch...
Besides this bug I have a few other renamings pending for v06 (some
things I overlooked in the big renaming NEW_* to AS4_*), but this is
all syntactical sugar, nothing else.
If you have not seen it yet, the first overview of
plenary topics for RIPE-54
is now available.
I said I would not spend time on the web page... but it was time to clean
it up a bit.
All quiet on the quagga AS4 front ;-).
A lot of people read these pages, some
of them download the current patch; some people even do not download
the newest version but an older one (though I can not image why
anyone would like to
run an outdated version). There has been no more feedback coming in,
which also indicates that nobody finds any bugs, which is good.
Well.... not all is quiet. There is a place at the RIPE NCC, where
someone has been busy for quite some time, and right now he has reached
one of his goals: all of RIPE NCCs RIS RRC boxes have been switched
to Quagga 0.99.6 with AS4 patch v05. If this runs without problems
for some weeks we can all be sure that the AS4 patch is solid as a
rock - I hope so, of cause ;-).
Erik: thumbs up, well done, and lets
hope it runs until the (proverbial) cow comes home, and thanks again
for all the feedback.
I am thinking about implementing a per-peer option to
suppress advertising the AS4 capability in order to tell AS4 quagga
to "simulate" being only AS2 capable. That means some very special
fiddling with as paths to be a "real" AS2 when having all AS4 information
present. And raises a problem if the current host has an as number
above 65535 - then we can not simulate an AS2 to another AS4 capable
speaker because that one can cancel a connect from AS_TRANS without
the AS4 capability, because the draft says an AS2 speaker MUST NOT use
AS_TRANS, so an AS4 speaker can see that as an error (AS4 quagga does
this). Which means "tolerate an AS2 with AS number AS_TRANS" will be another
needed option as soon as "do not advertise AS4" is available.
This is still in the "think about stage"... reason for
providing it is providing more debugging possibilities, and giving
the user a knob to turn if an AS2 peer crashes when presented with
the AS4 capability in the bgp open message.
Cleaned up some wording on my
thoughts on as4. With patch v05
some extended community comments became superfluos there.
Documented what the debug commands do.
Finally, managed to put together v05. Had some other things which
intruded, and - as with any patch version - I try out applying the patch
to cvs native quagga sources and compiling it to be (reasonably) sure
the patch is complete. So this is what is costing time here.
came out, describing the format used by
the new mrt dumps, and there are a few things which have to be cleaned
up again. Erik thinks this is trivial, so I'll hold v05 to include the
newest version which follows the definitions of
Wow. Erik is fast: very new mrt patch is here already (after a
few hours!), so it is me
again burning time to patch, proofread, test, and finally build v05.
Erik's patch looks good, as far as I can tell without using the dumps
with some program. So, I'll wrap this up again now... v05 will be
there very shortly.
Erik has sent me a new mrt patch again (he withdrew the one
from Feb 14th, btw), based on the discussions on GROW.
I'll go through it, and it will be included in v05.
The new version
for the extcommunites also looks good, and I'll rebase the patch onto
cvs quagga-20070307 while I am at it. Don't hold your breath though,
this will take a day or two...
I am busy implementing a new version for the extended communities.
Looks definitly better than the old syntax, and gets rid of the
(broken) dependency on the input format of an AS2.
Erik sent me a new MRT patch, following the discussions on
the GROW mailing list. I'll proof-read his implementation,
i.e. cross-check it with the specifications which were on the GROW list,
and hopefully we get rid of the hacky stuff in the MRT dumps
real soon now ;-).
Regretfully, this will probably take some days as I will be occupied
with other activities until Feb 21t. So do not hold your breath.
OK, made version 04. There seem to be some people out there
downloading the patch, probably even using it although Erik is still
the only one giving feedback. But I hope I get no feedback because
"it simply works" ;-).
Put some new stuff into the todo paragraph. MRT stuff has to be
done again, as is the extcommunity handling. The first because we
now have the definitions needed for implementing this proper, and
the second because I chose a wrong way of doing it (at least I think
A new version of the draft the whole patch is based on appeared two days ago.
Surprise: all constants got renamed. In order for the code to be readable
I'll have to follow this new naming scheme and rename a bunch of things
in the patch. Tedious, but not mission critical, and no changes in semantics.
Erik found another bug - vtysh can not grok the 'router bgp ASNUMBER'
correctly. Hm, did not touch that when programming... di not think
there would be a dependency there, but a few commands are coded
not only in the corresponding daemons, but in vtysh, too - and this is
one of them. Good Thing (tm) to have someone trying out just
about everything and sending feedback.
Come on you folks, you are out there, you are using this! Tell me about bugs,
and send some success stories, too!
After a longish discussion with Paul Jakma on the mailing list two days
ago I decided to spell out
my thoughts about asn32 problems.
This got longer than I thought, so probably nobody will read it -
but at least I can say later that I mentioned the problems which arose
from an implementation point of view.
Released version 3 with cleaned up asn32 extcommunities.
After a few words about ecommunities with Erik I realized that 'ip extcommunity-list's of the standard type
still had the old description in the CLI. So I thought: oups, you can define asn32 extcommunity, but
not use them. But it was not that bad: I had only forgotten to update the CLI prompt. Then I saw
the problem with printing out / saving a configuration with an asn32 extcommunity when you have an asn16
as asn in there (probably noone would use something like that, but nevertheless... if you configure
something like that, you *expect* to be able to save this configuration): With the syntax
I chose and the (variable) output format you could not save such an asn32 extcommunity. So I have
to enforce asdot+ for asn32 extcommunities - something which does not fit in well with "freely choosable
input/output format". So I think the syntax I chose is bogus in the first place. I should not use
'rt <asn32, asdot+>:<nnn>' for asn32 extcommunites and 'rt <asn16>:<nnn>' for
asn16 communities but
use something like 'rt32 <asn32,anyformat>:<nnn>' for asn32 extcommunities. Then the syntax
is always unambigous regardless of the asnumber format used. Feedback anybody?
Does anybody know what particular syntax other router vendors have used?
Patch number 3 (enforcing asdot+ for asn32 extcommunity values) is forthcoming.
Released version 02 of the asn32 patch. This has working MRT dumps in it. Thanks and a virtual beer to
Erik Romijn (RIPE NCC) who has provided information, code, and testing for this. Though this is still
a very hacky implementation libbgpdump will be able to read it, and all the tools we love from RIPE NCC
will soon be asn32 aware.
Erik Romijn (RIPE NCC) found out that MRT dumps do not work yet. Because I did nothing at all in bgp_dump.c that is actually not very surprising. Some message types for 32 bit things in MRT dumps are already defined, so these have to be used. Others are not, so we will try to invent something sensible which will siffice until we get official numbers for this.
Without someone acually using MRT dumps and knowing about the newly defined and necessary things I have had no chance in putting this together. So the whole MRT stuff will be more Erik's work than mine.
I will update the patch as soon as we have put something together which works for the RIPE NCC.
Patch has been downloaded about 10 times now, from ip addresses located all around the world, however still no feedback whatsoever.
It still applies to current quagga cvs with only an ignorable
(very obvious) conflict in a changelog. There are already asn32s which have been assigned, but none of these have shown up in the global tables yet.
The more ancient time, i.e. the
log of 2006
is also available.