[138465] in North American Network Operators' Group
Re: A BGP issue?
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Tue Mar 8 10:48:08 2011
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <E6392336-FD04-4BB9-81FF-AB10C17D2C93@gmail.com>
Date: Tue, 8 Mar 2011 10:47:18 -0500
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 8, 2011, at 8:52 AM, Greg Ihnen wrote:
> On Mar 7, 2011, at 10:19 PM, Patrick W. Gilmore wrote:
>> On Mar 7, 2011, at 14:27, Greg Ihnen <os10rules@gmail.com> wrote:
>>=20
>>> I run a small network on a mission base in the Amazon jungle which =
is fed by a satellite internet connection. We had an outage from Feb =
25th to the 28th where we had no connectivity with email, http/s, ftp, =
Skype would indicate it's connected but even chatting failed, basically =
everything stopped working except for ICMP. I could ping everywhere just =
fine. I started doing traceroutes and they all were very odd, all not =
reaching their destination and some hopping all over creation before =
dying. But if I did traceroute with ICMP it worked fine. Does this =
indicate our upstream (Bantel.net) had a BGP issue? Bantel blamed =
Hughesnet which is the service they resell. I'm wondering what kind of =
problem would let ping work fine but not any of the other protocols. It =
also seems odd that I could traceroute via UDP part way to a destination =
but then it would fail if the problem was my own provider. Thanks.
>>>=20
>>> If this is the wrong forum for this post I'm sorry and please just =
hit delete. If this is the wrong forum but you'd be kind enough to share =
your expertise please reply off-list. Thanks!
>>=20
>> Honestly, I would rate this as one of the most on-topic posts in a =
while.
>>=20
>> BGP only handles reachability, not higher level protocols. (Of =
course, you can h4x0r anything to do jus about anything, but we are =
talking the general case here.)
>>=20
>> If you can ping, BGP is working. If you can ping and cannot use TCP, =
then something other than BGP is at fault.=20
>>=20
>> I've seen strange things like someone enabling TCP compression =
(common on very small or very expensive links) one side but not the =
other, which then allowed ICMP and UDP but not TCP. It is a great way =
to annoy someone. "See, I can ping, it must be your side!"
>>=20
>> Have you tried TCP traceroute? Or telnetting to port 80?
> I did try TCP traceroute and it failed too. I didn't have a =
machine to telnet to on port 80 but I did try an ssh tunnel on port 9999 =
and it failed too.
Sure you do. Any web server will allow you to telnet to port 80.
TiggerBook-Air3:~ patrick$ telnet www.yahoo.com 80
Trying 67.195.160.76...
Connected to any-fp.wa1.b.yahoo.com.
Escape character is '^]'.
GET GET
<HEAD><TITLE>Not Found</TITLE></HEAD>
<BODY BGCOLOR=3D"white" FGCOLOR=3D"black">
<FONT FACE=3D"Helvetica,Arial"><B>
Your requested URL was not found.</B></FONT>
=09
<!-- default "Not Found" response (404) -->
</BODY>
Connection closed by foreign host.
[In case it wasn't clear, I typed "GET GET" myself, just to have the web =
server respond with something.]
> =46rom what everyone is saying it sounds like it was the =
satellite internet provider's compression scheme that was having trouble =
or some kind of an MTU issue.
>=20
> What I don't understand is why when using traceroute UDP/TCP/GRE =
I could get replies from some routers but not all routers to the =
destination, and why some routes were bizarre. If it was a failure of =
the sat internet provider's compression scheme or an MTU issue wouldn't =
traceroute UDP/TCP/GRE fail completely? What could have happened to my =
packets that would make them go only part way or go the wrong way?
It was likely not MTU if you can traceroute to some places, but not =
others. Traceroute doesn't send or receive big packets.
And I didn't really see anything terribly unusual in the traces you =
sent, other than some not completing. If you are talking about the =
Cogent one, with many routers per hop, that's just standard load =
balancing.
--=20
TTFN,
patrick
