# bgpctl show rib 203.10.62.0/24 flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *> 203.10.62.0/24 147.28.0.1 100 0 0.3130 0.1239 0.4637 0.4637 0.4637 0.4637 0.4637 0.4637 0.1221 1.202 i 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. (Patched versions of openbgpd to include 4-byte AS support can be found at http://www.potaroo.net/tools/bgpd/) cheers, Geoff
On 11.01.2007 10:14 Geoff Huston wrote
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.
Great news! Congratulations!
(Patched versions of openbgpd to include 4-byte AS support can be found at http://www.potaroo.net/tools/bgpd/)
A Quagga patch is available from http://quagga.ncc.eurodata.de/ Which vendor is already shipping ASN32 capable bgp code? Arnold -- Arnold Nipper, AN45
Arnold Nipper wrote:
On 11.01.2007 10:14 Geoff Huston wrote
George Michaelson, Randy Bush and myself have successfully tested the implementation of 4Byte AS BGP on a public Internet transit. ...
Great news! Congratulations!
(Patched versions of openbgpd to include 4-byte AS support can be found at http://www.potaroo.net/tools/bgpd/)
A Quagga patch is available from http://quagga.ncc.eurodata.de/
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.
On Thu, Jan 11, 2007 at 02:08:21PM +0100, Arnold Nipper wrote: [snip]
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. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
all, 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? t. On Thu, Jan 11, 2007 at 08:14:14PM +1100, Geoff Huston wrote:
# bgpctl show rib 203.10.62.0/24 flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin *> 203.10.62.0/24 147.28.0.1 100 0 0.3130 0.1239 0.4637 0.4637 0.4637 0.4637 0.4637 0.4637 0.1221 1.202 i
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.
(Patched versions of openbgpd to include 4-byte AS support can be found at http://www.potaroo.net/tools/bgpd/)
cheers,
Geoff
-- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation vp operations and professional svcs todd@renesys.com http://www.renesys.com/blog/todd.shtml
At 04:59 AM 12/01/2007, Todd Underwood wrote:
all,
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. regards, Geoff
At 04:59 AM 12/01/2007, Todd Underwood wrote:
all,
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
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. Geoff
Hi Geoff, 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? Regards, Akinori In message <7.0.0.16.2.20070111201044.041aca30@apnic.net> "4 Byte AS tested" "Geoff Huston <gih@apnic.net>" wrote: | | # bgpctl show rib 203.10.62.0/24 | flags: * = Valid, > = Selected, I = via IBGP, A = Announced | origin: i = IGP, e = EGP, ? = Incomplete | | flags destination gateway lpref med aspath origin | *> 203.10.62.0/24 147.28.0.1 100 0 0.3130 0.1239 | 0.4637 0.4637 0.4637 0.4637 0.4637 0.4637 0.1221 1.202 i | | | 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. | | (Patched versions of openbgpd to include 4-byte AS support can be | found at http://www.potaroo.net/tools/bgpd/) | | cheers, | | Geoff | | | |
MAEMURA Akinori wrote:
Hi Geoff,
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. :) randy
Hi Randy, 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? ) Regards, Akinori In message <45A6B100.3080202@psg.com> "Re: 4 Byte AS tested" "Randy Bush <randy@psg.com>" wrote: | MAEMURA Akinori wrote: | > Hi Geoff, | > | > 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. :) | | randy |
At 09:04 AM 12/01/2007, MAEMURA Akinori wrote:
Hi Randy,
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? )
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! regards, Geoff
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. cheers -george
in early feb, we will be announcing "B" root from an 32bit ASN. we expect this to be persistant. --bill On Fri, Jan 12, 2007 at 08:45:02AM +1000, George Michaelson wrote:
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.
cheers
-george
participants (9)
-
Antti Louko -
Arnold Nipper -
bmanning＠karoshi.com -
Geoff Huston -
George Michaelson -
Joe Provo -
MAEMURA Akinori -
Randy Bush -
Todd Underwood