I'm not able to ssh into any of my boxes or access any of the sites, yet my status monitor isn't showing downtime. Spotify is also down for me, which is another GCP customer.
I'm in Los Angeles but the servers are hosted on us-central1
Hi all - Seth from Google here. Our team is aware and we are working on mitigation. In short, a third party telco provider is advertising on one of our IP blocks. Unfortunately that's all the information I can share at this time.
EDIT: This is a general statement, I am not complaining to google here.
This kind of thing should not be possible. Are there any protocol proposals or other kind of upgrades to the routing protocols that would prevent these kind of mistakes/attacks?
Google IPs seem to be being routed to China for us.
We have servers in San Jose that cannot access Google services. Trace route shows everything going to China when leaving the San Jose data center. We can access the same services from Vancouver just fine.
How many times does this have to happen before China's privileges to do things like this get revoked? At this point, it can't be just a mistake and must be some state-sponsored hacking. Seems like a great way to find out where a particular Spotify user's IP address is.
Despite the subdomain, the IP for ChinaTelecom-gw.transtelecom.net (217.150.59.249) seems to be based in Russia, as does the carrier: https://en.wikipedia.org/wiki/TransTelekom
Seems likely to be TT's gateway to CT. New theory: TransTelecom brought up a new gateway to ChinaTelecom, which incorrectly gossiped all advertisements from ChinaTelecom. This caused a leak, since CT has bgp highjacking of Google IP ranges for the GFW within China, but ordinarily doesn't leak them outside the country. TransTelecom misconfigured the gateway to broadcast everything advertised by ChinaTelecom, bringing external traffic into the GFW.
Reading through the comments here I'm recognizing "China Telecom" from an article on a BGP hijack that was published about a week ago, I still had the article open in my browser:
I am on the East Coast, in Florida and seeing the same thing with traffic heading to China, lots of "chinatelecom-gw.transtelecom.net" in traceroutes I have never seen prior.
I'm not familiar with BGP routing attacks; the article above seems to imply the attacker needs to compromise certs in order to glean useful data from the attack.
If that's accurate, is this Google-oriented traffic vulnerable to this type of attack?
we manage services deployed in every GCE region, and our monitoring in London is reporting every GCE region having intermittent connectivity. no problems with our services in the other major clouds (we use basically all of them)
I hate to break it to everyone, but the technology to filter this sorta thing has existed for a very long time, but people often don't use it.
Most of the time this sort of thing is accidental (IE: operator error)so a lot of operators kinda ignore it.
Check out "IRR Power Tools" if you're interested.
Same thing here in San Diego. Traceroute to spotify.com going through LA, San Jose, NY, London, Amsterdam, Frankfurk, "mskn17ra-lo1.transtelecom.net", then ChinaTelecom-gw.transtelecom.net.
[+] [-] sethvargo|7 years ago|reply
[+] [-] sethvargo|7 years ago|reply
Our teams are continuing to work with upstream and downstream service providers to remedy the issue.
[+] [-] konschubert|7 years ago|reply
This kind of thing should not be possible. Are there any protocol proposals or other kind of upgrades to the routing protocols that would prevent these kind of mistakes/attacks?
[+] [-] amingilani|7 years ago|reply
Edit: Didn't someone recently share a tool to monitor BGP hijack attempts?
[0]: https://www.cnet.com/news/how-pakistan-knocked-youtube-offli...
[+] [-] garysahota93|7 years ago|reply
[+] [-] fxdoublecute|7 years ago|reply
[+] [-] regnerba|7 years ago|reply
We have servers in San Jose that cannot access Google services. Trace route shows everything going to China when leaving the San Jose data center. We can access the same services from Vancouver just fine.
[+] [-] docker_up|7 years ago|reply
[+] [-] gred|7 years ago|reply
[+] [-] lostmsu|7 years ago|reply
[+] [-] uji|7 years ago|reply
[+] [-] jamalex|7 years ago|reply
[+] [-] sterlind|7 years ago|reply
[+] [-] xolox|7 years ago|reply
https://arstechnica.com/information-technology/2018/11/stran...
In another comment in this thread I read:
> Seems like its time to start or accelerate a working group on secure BGP.
Indeed things can't go on like this for much longer...
[+] [-] faissaloo|7 years ago|reply
[+] [-] davismwfl|7 years ago|reply
[+] [-] scrollbar|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] CydeWeys|7 years ago|reply
[+] [-] dasm|7 years ago|reply
I'm not familiar with BGP routing attacks; the article above seems to imply the attacker needs to compromise certs in order to glean useful data from the attack.
If that's accurate, is this Google-oriented traffic vulnerable to this type of attack?
[+] [-] raesene9|7 years ago|reply
[+] [-] aviv|7 years ago|reply
https://news.ycombinator.com/item?id=18429099
Is our first time actually rolling over the entire stack to AWS - and it worked!
GCP outage currently is massive, can't even use other regions.
Edit: This also affected AWS Oregon region earlier. I do not know how yet, but they too were unreachable briefly. Seems to be okay now.
[+] [-] infogulch|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] TodayIsTheDay|7 years ago|reply
[+] [-] kacy|7 years ago|reply
[+] [-] leesalminen|7 years ago|reply
[+] [-] dickfickling|7 years ago|reply
Edit: We're also in Los Angeles, connecting to us-central1. Seems to be a pattern?
[+] [-] hellcow|7 years ago|reply
[+] [-] syogi|7 years ago|reply
EDIT: Some services are intermittently responsive. I had ~5 minutes of no access to anything. Some are slowly coming back.
[+] [-] fxdoublecute|7 years ago|reply
[+] [-] vamos_davai|7 years ago|reply
[+] [-] gsibble|7 years ago|reply
[+] [-] crunchlibrarian|7 years ago|reply
[+] [-] cobookman|7 years ago|reply
[+] [-] bifrost|7 years ago|reply
[+] [-] jamalex|7 years ago|reply
[+] [-] RayHawk|7 years ago|reply
[+] [-] xstephen95x|7 years ago|reply