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@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Andy Dills Sent: Thursday, April 04, 2002 5:43 PM To: nanog@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