Hi
We blocked some prefixes belonging to AS14037 (rackvibe llc) due to
their hosting spammers.
Rackvibe decided to nullroute us back in reply - thats up to them I guess
Only they're dumb enough to inject these blackhole announcements into
the cloud, and various other networks are picking up on these
announcements
TIA for filtering these out at your end
Our IPs are below - at least 208.36.123/24 seems to be announced as a
blackhole route by rackvibe -
205.158.62.0/24
208.36.123.0/24
203.86.166.0/24
65.49.50.0/24
65.49.50.0/24
64.71.166.192/27
64.62.181.80/28
srs
Paths: (7 available, best #7, table Default-IP-Routing-Table)
Not advertised to any peer
16150 6939 19318 14037
217.75.96.60 from 217.75.96.60 (217.75.96.60)
Origin IGP, metric 0, localpref 100, valid, external
Community: 16150:63392 16150:65320 16150:65426
3333 1103 1273 19318 14037
193.0.0.56 from 193.0.0.56 (193.0.0.56)
Origin IGP, localpref 100, valid, external
Community: 1103:1000 1273:21000 1273:21971 14037:6855 19318:999
19318:4000 19318:6855 19318:40012 21698:999 21698:4000 21698:6855
3277 3216 1273 19318 14037
194.85.4.55 from 194.85.4.55 (194.85.4.16)
Origin IGP, localpref 100, valid, external
Community: 1273:21000 1273:21971 3216:3000 3216:3001 3277:3216
14037:6855 19318:999 19318:4000 19318:6855 19318:40012 21698:999
21698:4000 21698:6855
812 19318 14037
These routes are also being injected by another AS belonging to
Rackvibe - AS19318
This is the guy from rackvibe who said he'd blackhole us because we
blocked him for hosting spammers.
RNOCHandle: GC373-ARIN
RNOCName: Czupryna, Gregg
RNOCPhone: +1-201-605-1425
RNOCEmail: gregg@njiix.net
RTechHandle: GC373-ARIN
RTechName: Czupryna, Gregg
RTechPhone: +1-201-605-1425
RTechEmail: gregg@njiix.net
Network Next Hop Metric LocPrf Weight Path
*>i 208.36.123.0 209.123.44.153 100 0 8001 19318
14037 i
telnet route-server.quagga.net port 2605 shows various ASNs
exclusively getting blackhole routes from AS19318
If you see 208.36.123.0/24 being announced from any other prefix than
XO (2828 I guess) please ignore it. Especially if you see it
announced from 19318 or 14037.
You're unlikely to get any reasonable response or action here. The best course of action is to work through XO. You are their customer, and it is their address space, right?
For what it's worth 208.36.123.0/24 was advertised recently but as a community we have no way of knowing the validity of it, or the operational impact.
Kris
(not speaking as MLC)
Hi
Yes we are on the phone with xo - but meanwhile several other
operators have been picking it up.
As for operational impact - we're Outblaze.com - thats mail.com,
register.com hosted domains etc, email for 40 million users or so.
That makes us, lemme see, quite a bit larger than people like Comcast,
in terms of userbase for email.
I hope that helps the community decide whether or not to accept these
bogus blackhole prefixes
thanks
srs
And the guy who is doing this is also an XO downstream as I see.. and
I have a feeling he wont like the consequences of what he did .. but
meanwhile, operationally speaking, my 40 million ++ users would be
glad if these fake announcements could get cut off at the knees
srs
Head, Antispam Operations
Outblaze Limited
http://www.outblaze.com
We lost a DS3 out of our downtown SF office around 4 hours ago. The Level 3 master ticket for OC-12 outage is #3020259 and is out of Hayworth. Anyone know anything more about this? Getting any info out of level 3 let alone an ETR has been challenging.
Keep waiting. I've been yet unsuccessful on getting a call back from anyone. They keep saying the same thing "it's part of a oc12 issue, field techs have been dispatch, please wait, no etr". Since that's now over 12 hours, I don't find it acceptable (not the down part, if it's part of a large cut, outage etc, I understand that), but rather their lack of information. I've escalated it to a "level 4 escalation" and they promised a callback within 15 minutes (which was 30 minutes ago).
By any chance, were you originally a Broadwing customer? I have a feeling that the oc-12 that was disconnected was a mistake in their db caused by the acquisition, and since they may have lost the original info, they may have no choice but to re-engineer the circuits.