This is hardly as serious as the last incident -- but, well, some people
do seem to have all the luck, eh?
Of course, there are measures one can take against this sort of thing; but
it's hard to deploy some of them effectively when the party stealing your
routes was in fact once authorized to offer them, and its own peers may
be explicitly allowing them in filter lists (which, I think, is the case
here). Sometimes "budget" network connectivity isn't -- even when you've
already realized that and turned off the tap!
The text below is what's currently in the MOTD on Panix's NetBSD hosts:
Can there be a confirmation of this? I see no such MOTD at
http://www.panix.com/panix/help/Announcements/
and my connection to panix is fine and route I see is 166.84.0.0/17
with origin in 2033. I also checked at routeviews.org and similarly
all their peers see origin in in 2033. Is there some other route
that has been hijacked then or has it now ben resolved?
BTW - Its interesting to note that its almost exactly one year after
their domain hijacking which happened on weekend of Jan 15 & 16, 2005 (friday jan 14th to be more precise).
Verio was just extremely helpful and filtered out the bogus Panix
routes ConED was sending them quite rapidly upon request from Panix's
staff. AFAICT ConED is still sending the bogus routes, and since they
evidently don't believe in staffing their NOC on the weekend, or
responding to reports of their own misconduct, heaven only knows if
they'll ever stop.
Thanks to Verio's quick intervention the problem, thank goodness,
seems to be solved. The current Panix MOTD is below:
Can there be a confirmation of this? I see no such MOTD at
Messages of the day -- panix.com
I don't know how realtime that is ... but Panix (including their web
site) was unreachable from several points earlier. It's back now.
and my connection to panix is fine and route I see is 166.84.0.0/17
with origin in 2033. I also checked at routeviews.org and similarly
all their peers see origin in in 2033. Is there some other route
that has been hijacked then or has it now ben resolved?
As noted in the MOTD posting, Panix is announcing more specifics.
166.84/16 is what they would normally accounce (and they are still
announcing that), 166.84.0/17 and 166.84.128/17 are there to overcome
the /16 Con Ed is advertising.
As of the now (according to Panix; I haven't independantly verified
it), Verio is (at Panix's request) rejecting the route from ConEd, and
Panix's upstreams are accepting the /17s, so connectivity should be
OK from everywhere except possibly ConEd.
-- Brett
Folx,
This is hardly as serious as the last incident -- but, well, some people
do seem to have all the luck, eh?
From where I'm standing this situation looks much more serious than
the last one. It looks like Con Edison (AS27506) hijacked several
prefixes other than just Panix's, and I'm not sure that they're done
announcing them yet. I see ~70 new prefixes, many of whom are
customers of Con Edison, but about 25 of these appear to have no
previous relationship to 27506).
I won't bore people with to many details here (unless there is great
interest) but a quick, rough-n-ready analysis is up at
http://www.renesys.com/blog/2006/01/coned_steals_the_net.shtml
for those that are curious. (For those that don't want to read it, I
think one main punchline is that Con Edison spewed a bunch of routes
they didn't own and UUNet and Verio believed them).
Please let me know if you see errors in there.
t.
As of the now (according to Panix; I haven't independantly verified
it), Verio is (at Panix's request) rejecting the route from ConEd, and
Panix's upstreams are accepting the /17s, so connectivity should be
OK from everywhere except possibly ConEd.
are the following two statements true?
o verio did have irr filter applied
o con ed seems to have registered others' prefixes in irr
randy