Yesterday morning, I noticed mail-abuse.org appeared to be down
(unreachable). I checked again, and it's still unreachable. In fact, I
can't even reach its name server.
I did some more looking last night, and it seems it's not down, it's just
unreachable from my network. Even stranger, it's only unreachable from
Atlantic.Net's primary ARIN block of 209.208.0.0/17. Traceroutes die at
so-1-1-0.mpr1.sql1.us.mfnx.net (209.249.203.58).
Router interfaces (using provider IPs) and a smaller IP block from an ISP
we acquired are able to reach mail-abuse.org, as are other networks I have
access to. We don't appear to be listed in the MAPS RBL+. I've tried
clearing BGP sessions, forcing packets out through alternate paths, with
no affect.
Is this some weird routing glitch somewhere between me and MAPS or has
someone at MAPS or vix.com decided they don't like me?
Also, though it seems to be on a totally different network, I've just
noticed I have the same problem reaching f.root-servers.net only from
209.208.0.0/17. Here traceroutes die at 189.ATM11-0-0.BR1.PAO1.ALTER.NET
(146.188.148.105).
I certainly hope this isn't yet another case of someone confusing
Atlantic.Net/Internet Connect Company, Inc. with
ATLANTIC INTERNET (NETBLK-Q0417-65-124-104-0)
621 NW 53RD ST. SUIT E135
BOCA RATON, FL 33487
US
Netname: Q0417-65-124-104-0
Netblock: 65.124.104.0 - 65.124.111.255
Atlantic Internet is full of commercial spammers and has just recently
resulted in several providers blacklisting our primary ARIN block thinking
we were the same company.
It may not be related, but there have been several strange route
inconsistencies wondering around the network yesterday and today
affecting a variety of sites for a few hours at a time. Even stranger
it seems to only be affecting routes in parts of the net, so the
site is sometimes reachable from one place but not another. One person
monitoring BGP picked up lots of inconsistent routes from his peers last
night, but they've cleared up now. Either there is a odd bug in vendor's
routing software, a network engineer has goofed, or someone is playing
games.
MFN have a history of dropping in blackholes for unsolicited relay tests...
are you sure your njabl experiment hasn't pissed off someone at MFN enough
to drop you in?
traceroute to 209.208.0.0 (209.208.0.0), 30 hops max, 40 byte packets
1 999.ge1-0.er1a.iad2.us.mfnx.net (208.185.51.2) 0.257 ms 0.177 ms 0.142 ms
2 pos8-0.mpr2.iad2.us.mfnx.net (208.185.0.13) 0.256 ms 0.182 ms 0.167 ms
3 so-2-1-0.cr2.iad1.us.mfnx.net (209.249.0.133) 0.515 ms 0.532 ms 0.516 ms
4 so-2-0-0.cr2.lga1.us.mfnx.net (208.184.233.66) 4.711 ms 4.697 ms 4.699 ms
5 so-2-1-0.cr2.ord2.us.mfnx.net (208.185.156.157) 25.015 ms 25.012 ms 25.015 ms
6 pos1-0.pr1.ord2.us.mfnx.net (208.185.0.194) 24.919 ms 24.891 ms 24.882 ms
7 uunet-abovenet-oc12.ord2.above.net (208.184.231.50) 26.255 ms 26.290 ms 26.220 ms
8 0.so-5-3-0.XL2.CHI2.ALTER.NET (152.63.68.178) 26.573 ms 26.562 ms 26.594 ms
9 0.so-1-0-0.TL2.CHI2.ALTER.NET (152.63.67.121) 26.614 ms 26.539 ms 26.570 ms
10 0.so-3-0-0.TL2.ATL5.ALTER.NET (152.63.101.50) 41.368 ms 41.412 ms 41.447 ms
11 0.so-7-0-0.CL2.ORL1.ALTER.NET (152.63.86.165) 53.946 ms 53.962 ms 54.038 ms
12 194.ATM7-0.GW7.ORL1.ALTER.NET (152.63.84.221) 54.343 ms 54.545 ms 54.220 ms
13 atlanticnet-gw.customer.ALTER.NET (157.130.65.130) 231.598 ms 68.260 ms 44.103 ms
14 gsvlflma-br-1-s4-0.atlantic.net (209.208.90.30) 49.813 ms 49.180 ms 49.879 ms
15 gsvlfl-br-1-s2-0.atlantic.net (209.208.6.126) 50.244 ms 49.778 ms 49.695 ms
16 *^C
Guess not.
I'm not so naieve as to not have tested before I posted (from somewhere
in iad1), and I was seeing drops at the border, so it must be a transitive
failure, eh?
Difficult to comment on some transient phenomenon that I don't know much about, but drop me private mail if you like and I'll help if I can.
Joe
> I did some more looking last night, and it seems it's not down, it's just
> unreachable from my network. Even stranger, it's only unreachable from
> Atlantic.Net's primary ARIN block of 209.208.0.0/17. Traceroutes die at
> so-1-1-0.mpr1.sql1.us.mfnx.net (209.249.203.58).
It may not be related, but there have been several strange route
inconsistencies wondering around the network yesterday and today
affecting a variety of sites for a few hours at a time. Even stranger
it seems to only be affecting routes in parts of the net, so the
site is sometimes reachable from one place but not another. One person
monitoring BGP picked up lots of inconsistent routes from his peers last
night, but they've cleared up now. Either there is a odd bug in vendor's
Define "lots". I see about 500 inconsistent routes in BGP, have seen them
since last June (when I started looking), made inquiries, and was told that this
was due to policies at exchange points. (I.e., it's not a bug, it's a feature.)
Regards
Marshall Eubanks
Hi, all.
] Define "lots". I see about 500 inconsistent routes in BGP, have seen them
I see a few more than that:
http://www.cymru.com/BGP/incon01.html
Thanks,
Rob.
Hi, all.
Aside from the restaurants, how's Toronto? 
] http://www.cymru.com/BGP/incon01.html
The list can be found here:
http://www.cymru.com/BGP/incon01-list.txt
This is the output of a very beta script. Comments welcome!
Thanks,
Rob.
I'm seeing about 150 such routes - I'm not collecting routing tables hence
my lower number. But, these routes on the whole dont match up with the
ones you've just posted Rob.. (being in the UK I guess I see a very
different view of the routing table..?)
I dont keep track of inconsistent announcements as I've never really seen
many in the past altho maybe I should start graphing!
Anyhow, I looked into a few and they all seem unrelated - some have both
sets of routes registered some dont, theres no correlation of transit AS's
Theres also a large variation in sizes from /14 to /24 so it appears not
just to be just small providers..
Steve
Hi, all.
] Define "lots". I see about 500 inconsistent routes in BGP, have seen them
I see a few more than that:
http://www.cymru.com/BGP/incon01.html
Dear Rob;
My lists are at
http://www.multicasttech.com/status/bgp.inconsistent
and
http://www.multicasttech.com/status/mbgp.inconsistent
I am not sure that the difference between 500 and 800 is
that significant.
Regards
Marshall
[snip]
I am not sure that the difference between 500 and 800 is
that significant.
A recent snapshot at oregon-ix showed >1500 prefixes with such munged
origins. That's quite a few more than just everyone announcing EPs as
from their own AS.
Cheers,
Joe
[snip]
> I am not sure that the difference between 500 and 800 is
> that significant.
A recent snapshot at oregon-ix showed >1500 prefixes with such munged
origins. That's quite a few more than just everyone announcing EPs as
from their own AS.
Well, you may be right, but it is (at least here) - pretty stable
This sure does look someone's policy to me.
Marshall
This plot of # of consistent routes from AS 16517 (together with a link to the most recent BGP list of said routes) is now part of
http://www.multicasttech.com/status/cidr.html
(Figure 6) and will be updated automatically.
Values are weekly from April - May, and 4 times daily since the beginning of June.
Questions, comments, etc., welcomed.
Reards
Marshall Eubanks
Marshall Eubanks wrote: