George Michaelson, Randy Bush and myself have successfully tested the implementation of 4Byte AS BGP on a public Internet transit. The above BGP RIB snapshot was taken at a 4Byte BGP speaker in North America, showing a transit path across AS 1221, AS 4637, AS 1239 and AS 3130 , with correct reconstruction of the originating AS at the other (4Byte AS) end.
The code base used was OpenBGPD, with 4 byte patches that I've added to the code in the past couple of weeks.
George Michaelson, Randy Bush and myself have successfully tested the
implementation of 4Byte AS BGP on a public Internet transit. The
above BGP RIB snapshot was taken at a 4Byte BGP speaker in North
America, showing a transit path across AS 1221, AS 4637, AS 1239 and
AS 3130 , with correct reconstruction of the originating AS at the
other (4Byte AS) end.
This is especially good news as there are two independent open source
BPG implementations supporting this!
My question:
How robust these BGP programs are? are they used and how widely in
production use? I am askint this because I may be asked to provide
alternatives to commercial routers in certain sites which should be
doable in BW sense, at least. Normal PC can handle several 1G ethernet
connections without a problem.
Which vendor is already shipping ASN32 capable bgp code?
When I last posed this question to folks in December, Vendor
C had it live in 3.4 IOX now and had no timing details for
'vanilla' IOS, but committed to it getting done RSN. Vendor
J indicated in 2007, but I had no dates.
we (renesys) saw as23456 adjacent to both 1221 (expected) and 65001
(not), originating two prefixes:
203.10.62.0/24
and
203.10.63.0/24
paths looked like:
<peer> 7474 1221 65001 23456 23456 23456
and many similar
but also
<peer> ... 4637 1221 23456
and many similar
was the leak of the 65001 as intentional and part of the experiment, a
simple, error, or is there something useful to learn about the
difficulties of building filter lists with 4 byte ases?
we (renesys) saw as23456 adjacent to both 1221 (expected) and 65001
(not), originating two prefixes:
that was me, yes
I apologise for the 65001 leak . In mitigation I can only add that it did not last very long!
203.10.62.0/24
and
203.10.63.0/24
paths looked like:
<peer> 7474 1221 65001 23456 23456 23456
and many similar
but also
<peer> ... 4637 1221 23456
and many similar
was the leak of the 65001 as intentional and part of the experiment, a
simple, error, or is there something useful to learn about the
difficulties of building filter lists with 4 byte ases?
At the time I needed a 2 byte AS between the OpenBDPD tester and AS1221 and I thought it was perhaps less silly to leak a private use AS than it was to steal a non-private use AS.
Building filter lists in the 2 byte world to filter out 4 byte paths is an issue, as all the 4 byte entries in the path are translated into AS23456 when you are in the 2 byte world. This could get tricky if you have a complex routing policy that you want to implement and some of your policy targets are using 4 byte AS numbers.
This particular path illustrates the point - in actual fact the trailing 3 entries were NOT instances of AS path prepending, but were in fact 2 byte AS translations of AS 1.101, AS1.102 and AS 1.103.
Do you have any plan for another trial longer and notified
so that everyone with various implementations of OLD SPEAKER
can observe this and check if they normally handle a 4-byte
ASN?
Do you have any plan for another trial longer and notified
so that everyone with various implementations of OLD SPEAKER
can observe this and check if they normally handle a 4-byte
ASN?
the test is known to have gone through juniper, cisco, and procket
routers.
though, of course, we have no idea if there would be proof of
termination testing all permutations of cisco hardware and images.
Yes. We can never have the knowledge of *all* BGP speakers
in the world, then keeping a 4-byte ASN announced to let
everyone observe it looks a good strategy to see what would
be happening.
The test you did has already proven that the current Internet
routing system has no serious problem with 4-byte ASN.
( Did it have any? )
If I can answer, yes, APNIC expects to deploy a node in Japan in the
near future for more persistent testing of this kind of thing. -The
equipment is just being commissioned.
Other experiments may be done before then of course.
No, there were no problems with this particular exercise. What this test confirmed (for this path) is that opaque path attributes marked as optional and transitive do indeed pass through the deployed BGP fabric without alteration. This is a reassuring confirmation!
I've done a number of small scale permutations with BGP configurations, but larger tests of the form you describe here will need some more willing participants, particularly if we are interested in doing this in the context of the Internet itself rather than in a collection of small scale ebgp peerings.
