Qwest Support

Fri Apr 5 19:46:00 UTC 2002

And here we go, down the rabbit hole... (see below)

> Steve Naslund Said...
>
>
>
> I would have to disagree on a lot of these points.  See below.
>
> Steven Naslund
>
> > Daniel Golding Said...
> >
> >
> >
> >
> > I suppose. Except it's not even certain you were having a problem of any
> > kind at all.
> >
> > Qwest's presence or absence from public IX's really has nothing
> to do with
> > your routes being announced. In fact, Qwest privately peers with all the
> > other large networks. While there are many peering sessions at
> the public
> > NAPs, most traffic is carried over private network
> interconnects, at least
> > domestically. Certain peering points in Europe (Linx), tend to
> > run the other
> > way.
> >
>
> If the routes cannot be seen at the public IXs then a lot of
> people who are
> connected to the public IXs will not see it either.  Depends if
> you are only
> talking to the "big networks".
>

How is this so? There are plenty of routes that are not announced at public
exchance points, that are floating around in the global routing table.
That's because almost all of the folks who are at public peering points, are
also buying transit from the "big networks", in one way or another. Needless
to say, this is how the internet works.

> > In fact, if Qwest were publically peering with other networks, it
> > might be a
> > reason why your routes through UUNet were being prefered - private peer
> > originated routes are almost always assigned higher local preferences in
> > carrier networks, then public peer originated routes.
> >
>
> Local prefs are just that LOCAL.  They will not matter to other networks,
> they
> merely show the routes I prefer in and out of my network.  This
> should have
> no
> impact on AS path hop counts which is the primary method of selecting BGP
> routes.
>

I think you are missing the point. Almost all large networks have similar
sorts of routing policies, where routes recieved through private
interconnect, get pref-ed higher than routes through public exchanges.
Because of this confluence of routing policies, private peer-originated
routes tend to be prefered. Look at the NANOG presentation archives for good
examples of how this works.

>
>
> > I'm not sure your annoyance with Qwest has any basis in their lack of
> > performance, as far as IP routing. BGP decision rules and other
> networks'
> > routing policies will govern which paths are used for your
> routes. Here is
> > an example...
> >
> > - Network X peers with UUNet in 8 locations. Network X also peers with
> > Qwest, lets say in 6 locations. For whatever reason, network X chooses
> > UUNet's routes to you over, Qwest's. This could be due to local routing
> > policy, dictating that 701 routes get a higher local pref. Or AS path
> > lengths could be the same, and the decision could be falling to
> something
> > like router ID. Whatever.
>
>
> What I would wonder here is : If network X prefers UUnet over Quest then
> maybe
> UUnet offers better performance than Quest.  I think that most
> networks will
> not set a local pref unless there is a reason to override the default BGP
> behavior
> which is to use AS path length.  If service providers are avoiding Quest
> there is
> probably a good reason for it.  I don't think many people would
> try to give
> UUnet
> more preference that they already get by default, more likely
> networks lower
> the
> UUnet pref in order to balance their traffic.
>
>

This is simply not true. There is no incentive to balance outbound traffic
amongst peers, EXCEPT to preserve inbound/outbound ratios.  Almost all
backbones set local prefs on the vast majority of routes, in order to
establish a routing policy. Also, backbones do not tend to alter their local
prefs or routing policies based on the perceived quality of their peers -
only on things like congestion across a specific peering link. It is often
tempting to think that because one manages traffic in a certain way, in a
smaller or non-transit AS, that one would do it in the same way in a large
transit AS, with significant peering. However, in reality, these are much
different animals.

>
>
> >
> > - In general, all the UUNet peering will get treated the same by
> > Network X's
> > routing policy. This won't always be the case, but let's say
> that none of
> > the peering links are congested, etc. So, a certain number of paths are
> > carried throughout Network X via iBGP. If UUNet's routes "won" at
> > all those
> > peering points, you will not see any paths through Qwest on a
> > single carrier
> > route server like Nitrous.
>
> Not true.  Nitrous shows all routes it knows about whether they are
> preferred or not.
>

Looking Glasses like Nitrous, show the routes on the routers that they look
into. If paths from a specific provider are selected on all peering routers,
for a given route, than no paths to alternative providers will appear. This
is how BGP works. I suggest reading the appropriate RFCs, and perhaps,
Routing TCP/IP volume II by Jeff Doyle. Remember: large carriers tend to
have dedicated peering routers, where numerous private peers are terminated.

>
> >
> > - Route-views, and the like are different animals. They get
> ebgp multihop
> > views from many providers, so you will tend to see paths from
> > many different
> > vantage points, and are more likely to see paths from both your
> upstreams.
> >
> > ISPs get a heavy volume of calls every day. While Qwest may not have the
> > greatest customer service, it's not like you were actually down or had a
> > qwest originated routing issue. If that were the case, my
> > sympathy would be
> > greater.
>
> How would Quest have known if he actually had a problem since they never
> really
> talked to him ?  What if he had a real routing problem ?
>

If this was a real routing problem, it would be a much more interesting
conversation.
>
>
>
> >
> > - Daniel Golding
> >
> > -----Original Message-----
> > From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu]On Behalf Of
> > Andy Dills
> > Sent: Thursday, April 04, 2002 5:43 PM
> > To: nanog at merit.edu
> > Subject: Qwest Support
> >
> >
> >
> >
> > Wow, Qwest support is indeed terrible.
> >
> > Turned up the DS3 today...the connectivity seems fine. I
> decided to check
> > a couple of routeservers (nitrous); all had my much-prepended UUnet
> > announcement, but NONE had my Qwest announcement. Not a huge deal, but
> > curious to me.  Is Qwest just not at the public peering points? When I
> > checked route-views.oregan-ix.net, I felt better, but yet annoyed. Even
> > with the prepends, most networks were announcing UUnet's path.
> >
> > So I decided to call them and ask...man what a mistake. The guy is like,
> > "Ok, hold on, let me get somebody from our IP noc." 10 minutes goes by,
> > and he comes back with "Couldn't get anybody in the IP noc, let
> me try to
> > get somebody in your install group" (being that I turned up the DS3
> > today). Comes back another 10 minutes later with "Well, I left a message
> > for them, but there isn't much I can do. Nobody seems to be answering
> > their phone. If somebody doesn't call you back within 30 minutes, here's
> > a number to call..."
> >
> > So what if my routes were actually hosed? I'd just be screwed
> because they
> > can't get anybody at the IP noc?
> >
> > I wait. Nobody calls back within 30 minutes. I call the number
> he gave me.
> > Busy. You gotta be kidding me.
> >
> > So I call the main number again, talk to somebody different. She has me
> > hold, and then brings some guy on the line "who can help me". I start to
> > talk about route servers, and he's immediately like "Woah, this is a BGP
> > problem...I can't help you. Let me try to get somebody from the IP noc."
> >
> > So, I wait on hold for about 15 minutes, only to be given dial tone.
> >
> > Please tell me it isn't always THIS bad?
> >
> > Andy
> >
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Andy Dills                              301-682-9972
> > Xecunet, LLC                            www.xecu.net
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Dialup * Webhosting * E-Commerce * High-Speed Access
> >
>