Google Services Problems?
Is anyone else seeing intermittently down or very slow access to Google services like YouTube and Google Play Store? We have two upstream providers: one peers with XO and Level3, one with Qwest. When our Google traffic is preferring the route through XO, we see things like YouTube videos not loading, Android devices not able to download updates, Google Play Music not streaming, etc. The main source network we are seeing it from is 206.111.9.XXX which is owned by XO according to whois, but seems to be sourcing Google traffic. I assume they are caching or CDN servers of some type for Google that are hosted at XO. The problem started on Friday as far as we can tell. We had a similar problem a few weeks ago with Google Images searching. The search result page showed the same thumbnail (a car crash) for anything you searched for. It was again being sourced from the 206.111.9.XXX network. Clicking on the image showed you the proper image, just the thumbnails were wrong. It cleared up in a couple of hours in that case, but the current problem has been going on for a while. Thanks, Jason
Re: IPV6 Multicast Listener storm control?
Richard Holbo writes: > I am seeing issues with IPV6 multicast storms in my network that are fairly > low volume (1-2mbit), but that are causing service disruptions due to CPU > load on the switches and that the network is a Point to MultiPoint wireless > network. OK, well one comment in my previous email will sound stupid (not enough coffee yet) but the upshot remains: more subnetting. -r
Re: IPV6 Multicast Listener storm control?
Richard Holbo writes: > I have about 500 IPV4 clients on a vlan served by Cisco ME3400, Catalyst > 3750 and 3560 switches. These are switched back to a routed interface and > IP addresses are assigned by DHCP. We are not using IPV6 at all, and I > don't have control of the clients. This configuration is reminiscent of my back lawn. It probably grew organically, has been neglected for a period of time, and it's going to require a bit of effort to tame it and bring it under control. You probably don't have the option of blocking horizontal layer 2 traffic like the WISP guys do, and even if you were able to get away with that it brings its own set of downsides to it. The solution here is to chop things into separate broadcast domains, each one no bigger than a single switch. You might bring each to a routed interface on another device (or likely more than one other device depending on your network layout), but on no account should you have the broadcast domain span more than one port on that device. Hopefully you don't have any poorly behaved software that depends on being in the same broadcast domain. It can be difficult to inventory that and make sure it all works before taking the leap. It could be easier to just peel off one workgroup of people to configure them that way as a pilot and see if anyone squawks. Tell them that you're doing it and that you want feedback, since your current configuration is conditioning them to just suck it up when the network periodically flakes. Hope this helps, -r