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: Looking for Netflow analysis package
ManageEngine's NetFlow Analyzer will do most of that (not sure about AS Path Analysis.) It is priced per monitored interface, but is pretty reasonable for what it does. They have a 30-day demo available. We use their full OpManager+NetFlow suite to monitor several hundred devices with thousands of interfaces. We only license NetFlow for the interfaces that connect to external providers. E-mail me privately if you want to see the reports. Jason On Tue, May 14, 2013 at 6:59 PM, Erik Sundberg wrote: > Does anyone know of a netflow collector that will do the following. > *Graph/List Destination Networks By Top AS > *Graph/List Destination Networks By Top IP Address > *AS Path Analysis > *Traffic Type (ICMP, TCP, UDP, IPSEC, HTTP, SSH, SMTP, etc..) > > We will be using this to help us decide who to Peer with and what transit > Providers to look at. > > I am familiar with Arbor Network's Peak Flow utility but it's a little too > pricy. > I also found AS-Stats https://neon1.net/as-stats/ look promising from the > power point on their page. > > Thanks > Erik > > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. >
Re: Per Site QOS policy with Cisco IOS-XE
We had a similar problem years ago with a frame-relay <---> IMA setup. The hub end was a multiplexed ATM circuit with PVC's to each site's frame-relay circuit. The IMA speed was equal to the aggregate speed of each site's CIR. It worked great until all the sites were bursting above CIR. VoIP call quality would go really bad when that happened (early mornings mainly.) QoS policies could not be maintained between the frame and ATM sides. Sprint (support contract on the CPE) and MCI (circuits) engineers finally decided to run PPP over the native protocols on each end and then apply QoS to the PPP sessions. That fixed the problem. I am not sure if something like that is possible in your case or not though as I am not familiar with MPLS. I tried to find the config, but I no longer have it. I remember it used virtual templates, but don't remember the specifics. Jason On Thu, May 9, 2013 at 10:40 AM, Wes Tribble wrote: > Tyler, > > Tyler, > > I already had a case open with TAC on this issue. This is what the CCIE > assigned to the case is saying about that type of policy: > > > Hi Wesley, > > > Yes, I’m afraid that configuration is not possible. We can only mark or > police traffic on this child policy. > > > > You will see the following message when trying to attach the service-policy > to the interface: > > > > --- > > ASR10004(config-if)#service-policy output parent_shaper > Cannot attach queuing-based child policy to a non-queuing based class > > *This is what I sent to her:* > > So this configuration is not possible? > > policy-map parent_shaper > class class-default > shape average 1 < --- 100Mbps parent shaper. > service-policy site_shaper > > policy-map site_shaper > class t1_site > shape average 1536000 > service-policy qos_global > class multilink_site > shape average 3072000 > service-policy qos_global > class class-default > service-policy qos_global > > policy-map qos_global > class VOICE > priority percent 25 > set dscp ef > class AF41 > bandwidth percent 40 > set dscp af41 > queue-limit 1024 packets > class class-default > fair-queue > set dscp af21 > queue-limit 1024 packets > > On Thu, May 9, 2013 at 8:33 AM, Tyler Haske wrote: > > > Wes, > > > > The earlier policy doesn't use bandwidth commands, hence, it doesn't > > *subscribe* anything. The only thing it does is ensures that individual > > sites do not exceed their shaped rate. You could add bandwidth statements > > if you wanted to ensure a certain site always is guaranteed a certain > > amount of bandwidth from the parent shaper. You can't oversubscribe with > > the bandwidth command. > > > > > > policy-map parent_shaper > > class class-default > > shape average 1 > >service-policy site_shaper > > > > policy-map site_shaper > > class t1_site > > shape average 1536000 > > bandwidth percent 1 > > > >service-policy qos_global > > class multilink_site > > shape average 3072000 > > bandwidth percent 2 > >service-policy qos_global > > class class-default > > bandwidth percent 97 > >service-policy qos_global > > > > policy-map qos_global > > ! ... whatever you want here. > > > > This would make sure that large sites don't stare out small spoke sites > > for bandwidth. > > > > On Thu, May 9, 2013 at 8:58 AM, Wes Tribble > wrote: > > > >> Thanks for the information Tyler, I will have to play around with that > >> kind of policy in my lab. What would you suggest if you are > >> oversubscribing the interface? With the child policy inheriting the > >> bandwith of the parent shaper, wouldn't I run out of bandwidth > allocation > >> before I built all the shapers for all of my 29 sites? > >> > > > -- Jason Lester Administrator for Instructional Technology Washington County Public Schools Tel: 276-739-3060 Fax: 276-628-1893 http://www.wcs.k12.va.us
Re: CenturyLink Outage?
Thanks, I did not know about that list. Jason On Tue, May 7, 2013 at 1:18 PM, John Neiberger wrote: > There is an ongoing discussion about this on the outages list. > > https://puck.nether.net/mailman/listinfo/outages > > John > > > On Tue, May 7, 2013 at 10:54 AM, Jason Lester wrote: > >> Does anyone know what is going on with the nationwide CenturyLink outage? >> Their NOC recording says it is a BGP routing issue with their upstream >> peers affecting Internet traffic and traffic between regions. Our outside >> connectivity with them has basically been down since about 4:00AM (EDT) >> this morning. The prefixes we were receiving from them were fluctuating >> between a few hundred and a few thousand all morning. We are getting the >> full BGP table from them now (for about the last hour), but still not >> seeing any incoming traffic. Seems like a major issue since it has been >> almost 9 hours now. >> >> Thanks, >> Jason >> -- >> >> Jason Lester >> Administrator for Instructional Technology >> Washington County Public Schools >> Tel: 276-739-3060 >> Fax: 276-628-1893 >> http://www.wcs.k12.va.us >> > > -- Jason Lester Administrator for Instructional Technology Washington County Public Schools Tel: 276-739-3060 Fax: 276-628-1893 http://www.wcs.k12.va.us
CenturyLink Outage?
Does anyone know what is going on with the nationwide CenturyLink outage? Their NOC recording says it is a BGP routing issue with their upstream peers affecting Internet traffic and traffic between regions. Our outside connectivity with them has basically been down since about 4:00AM (EDT) this morning. The prefixes we were receiving from them were fluctuating between a few hundred and a few thousand all morning. We are getting the full BGP table from them now (for about the last hour), but still not seeing any incoming traffic. Seems like a major issue since it has been almost 9 hours now. Thanks, Jason -- Jason Lester Administrator for Instructional Technology Washington County Public Schools Tel: 276-739-3060 Fax: 276-628-1893 http://www.wcs.k12.va.us
