Re: [afnog] ARIN to allocate from 74/8 & 75/8
route-views and ris provide pretty good views of route propagation.
but, as you seem to understand, that's only half the story. luckily, the other, more useful, half is easily testable if arin/cymru would just follow the long-discussed path.
yep, that's clear. routing and firewalling may be orthogonal. obviously, without routing there is no forwarding and *many* people filtered announcements within 69/8. i acknowledge that many people also accepted the route and filtered traffic. my point was (as should have been clear) that the right place to *start* is routing. the other point i was making, about which i should have been clearer, is that willy-nilly pinging from random places won't really help much, as is probably obvious. it can identify gross unreachability problems but it cannot give a clear picture of unreachability across all of routed space (unless your willy-nilly sample happens to evenly cover all of routed address space--a neat trick!). an announcement to some mailing list asking whoever happens to be a member (and paying attention, with free time on her hands) to ping some addresses (or http or whtever) will also not give a complete picture. this has probably already been thought-out, but outbound reachability testing *from* the address block to a representative spread of addressing makes much more sense and would be much more indicative of forwarding (versus routing) problems, and would do so with some method and statistical reliability. presumably that is coming and just hasn't been discussed or carried out yet. for what it's worth, these three /20s appear to have no systematic unreachability problems across renesys's peerset. the first announcement we saw were quite some time ago: 22:37:43 UTC 22 Aug 2005 with paths ending 174 23028 36666 all three /20s showed up for *one* peer with a path that looked like that for almost 5 days while 23028 worked on allowing their upstreams to accept the announcement (reasonable speculation, not observed fact). 3561 starts accepting the announcements on 05:47 UTC 27 Aug 2005. a couple of other major networks on the 30th, and 31st August. lots of people follow suit the 2nd november, and then slow propagation throughout renesys's peerset. the most recent peer of renesys's peers to finally accept those /20s did so on at 00:08 UTC 21 Sep 2005 (today or tomorrow, depending on where and when you read this). i'm guessing that routeviews and ripe ris data have similar findings, although i have not checked them (left as an exercise to the reader? :-) i'd be happy to provide more detail if it seems useful. t. -- _____________________________________________________________________ todd underwood director of operations & security renesys - interdomain intelligence todd@renesys.com www.renesys.com
that willy-nilly pinging from random places won't really help much, as is probably obvious. it can identify gross unreachability problems but it cannot give a clear picture of unreachability across all of routed space
yep. but, for each operator who wants to be responsible, it lets us easily test that our configs are clear. and that was the specific goal. randy
In message <20050921014346.GS5285@renesys.com>, Todd Underwood writes:
this has probably already been thought-out, but outbound reachability testing *from* the address block to a representative spread of addressing makes much more sense and would be much more indicative of forwarding (versus routing) problems, and would do so with some method and statistical reliability. presumably that is coming and just hasn't been discussed or carried out yet.
It's a good idea, but of course that requires someone in the allocated block to have a list of addresses to ping, all over the net. Furthermore, the pinging really should be done from an actual use of the net, and not just from, say, the RIR that allocated the block. (Pinging a single address in new blocks would have that requirement, too, of course.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
this has probably already been thought-out, but outbound reachability testing *from* the address block to a representative spread of addressing makes much more sense and would be much more indicative of forwarding (versus routing) problems, and would do so with some method and statistical reliability. presumably that is coming and just hasn't been discussed or carried out yet. It's a good idea, but of course that requires someone in the allocated block to have a list of addresses to ping, all over the net.
as i said privately to someone, a few problems o the scale of destinations is far to large. o how are you to know what is an important host inside of a complex enterprise? the granularity of routing/filtering within sites is not externally visible. o many of a large complex enterprise's sources from which it may be desirable to test may be in 1918 space. o the pingees may not like being pinged. the goal here was for isps and enterprises who want to be good citizens to be able to test. randy
On Tue, 20 Sep 2005, Randy Bush wrote:
as i said privately to someone, a few problems o many of a large complex enterprise's sources from which it may be desirable to test may be in 1918 space.
Don't forget the enterprises that number themselves out of 'unallocated' space :) which might very well be the space that was just recently released. It's a really fun conversation when your customer (or some enterprise) realizes that RFC1918 is there for a reason, and that their 10k person network is going to need a really complicated renumber out of the 72.x.x.x/8 and into 10.x.x.x :( Suffice it to say that there are a myriad of reasons these new allocations could seem 'broken' to folks. Testing real-world applications seems like a reasonable first step. Having an org (cymru in this case) able to provide http/icmp targets on these prior to RIR allocations going bananas seems like that first step. Those that wish to test can, those that don't don't... simple?
Suffice it to say that there are a myriad of reasons these new allocations could seem 'broken' to folks.
tell me about it. i am having fun testing from various (we believe to be) *unfiltered* places, and some work and some don't. e.g. we can ping from the westin (a class B going out to sprint and verio stm1s) but not from my hawai`i dsl (an island provider where i know and trust the very clued systems staff, and they say it's not filtered). i can ping from univ of oregon but not from the linx, blah blah blah. the suspicion is that cymru has filters! [0]
Testing real-world applications seems like a reasonable first step. Having an org (cymru in this case) able to provide http/icmp targets on these prior to RIR allocations going bananas seems like that first step. Those that wish to test can, those that don't don't... simple?
agree. this is the way to go, but it needs some work. but this is the first try, so cut 'em a bit of slack. if it's not working flawlessly in the morning, and i am at gmt-10, we can demand a full refund and flame 'em to death :-). randy --- [0] - i contend that the target(s) should not be behind any but the most basic (1918 and 127) filters. folk want to test from exchange meshes, ... we should only be debugging one set of filters at a time.
Hi, NANOGers. ] the suspicion is that cymru has filters! [0] Au contraire! The device is completely unfiltered. How crazy of me. ;) Randy, I'm debugging the legitimate issues you share with me now. Stay tuned! Folks who trip across anomolies and the like should contact us at team-cymru@cymru.com. Thanks, Rob. -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999.
On Tue, 20 Sep 2005, Steven M. Bellovin wrote:
testing *from* the address block to a representative spread of addressing makes much more sense and would be much more indicative of forwarding (versus routing) problems, and would do so with some method
It's a good idea, but of course that requires someone in the allocated block to have a list of addresses to ping, all over the net.
Such lists aren't _that_ hard to come by. It's been done. If anyone from cymru wants to talk to me about what I did with 69/8 (69box), or get some data, they know how to reach me. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
In message <Pine.LNX.4.61.0509210006491.10349@soloth.lewis.org>, Jon Lewis writ es:
On Tue, 20 Sep 2005, Steven M. Bellovin wrote:
testing *from* the address block to a representative spread of addressing makes much more sense and would be much more indicative of forwarding (versus routing) problems, and would do so with some method
It's a good idea, but of course that requires someone in the allocated block to have a list of addresses to ping, all over the net.
Such lists aren't _that_ hard to come by. It's been done.
Sure -- but if you want a *representative spread*, it takes considerably more work. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Hi, NANOGers. ] this has probably already been thought-out, but outbound reachability ] testing *from* the address block to a representative spread of ] addressing makes much more sense and would be much more indicative of ] forwarding (versus routing) problems, and would do so with some method ] and statistical reliability. presumably that is coming and just ] hasn't been discussed or carried out yet. Yep, that's being done since we announced the prefixes. More details to come shortly. :) Todd, thanks for checking on these prefixes and sharing what you see! Thanks, Rob. -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999.
participants (6)
-
Christopher L. Morrow -
Jon Lewis -
Randy Bush -
Rob Thomas -
Steven M. Bellovin -
Todd Underwood