RE: BGP over satellite link - update!!

["Mark Tinka" <mtinka at africaonline.co.ug>]

Hi guys.

Sorry to open this can again, but I just wanted to clarify something.

Being in Africa is quite interesting, you get to see a lot of new satellite
technology, since it's the most cost-effective method of connectivity to the
Internet.

Some of this new technology includes "the not-so-common" SCPC modulation
hardware/satellite modems. Newer equipment now connects directly to one's
ethernet segment. This equipment/box could run proprietory or even
open/closed source operating systems. This box is located at both ends of
the satellite link, naturally.

There are [Cisco] routers behind both these boxes, to handle the critical
routing requirements. Even though BGP is open-standards, it won't run on
either of these boxes. 

However, these boxes are running the basic routing services, so they know
how to reach your ethernet segment and the remote box on the other end. More
advanced routing is handled by the routers behind them. 

As a client, I would declare, in my router, that box as my default gatway to
the remote provider over the satellite. Once it gets the packets, it knows
how to send them over the satellite connection to the remote provider, and
then onto the Internet. 

Now, since we know we aren't running BGP on these boxes, yet we need to peer
with the remote provider, we shall need to use "ebgp-multihop", because the
remote BGP speaker is not directly connected to the satellite medium in the
way you would have a router connected to an ordinary satellite modem. So,
the remote BGP speaker is 3 hops away; I would tell this to my
"ebgp-multihop" statement.

However, Phillip said something interesting; that if there's a link failure
on the primary circuit, and we had a backup, that perhaps our router would
try to re-initialise the TCP connection to the remote BGP speaker over the
backup circuit, and the path taken by the traffic would be far from what is
expected. However, being that the "ebgp-multihop" statement categorically
states that that remote peer is 3 hops away, wouldn't the formation of a
neighborship fail, since the remote BGP speaker is more than 3 hops away,
although reachable?

What I am trying to say is; newer technology is becoming more manageable and
easier to deploy. This may, at times, take away what we/other networks have
been used to. In this case, wouldn't "ebgp-multihop" have a solid case, if
used right?

Regards,

Mark Tinka - CCNA
Network Engineer
Africa Online Uganda
5th Floor, Commercial Plaza
7 Kampala Rd,
Tel:   +256-41-258143
Fax:   +256-41-258144
E-mail: mtinka at africaonline.co.ug
Web:     www.africaonline.co.ug
 

-----Original Message-----
From: owner-afnog at afnog.org [mailto:owner-afnog at afnog.org] On Behalf Of
Philip Smith
Sent: Tuesday, April 08, 2003 7:38 AM
To: afnog at afnog.org
Subject: Re: BGP over satellite link


At 16:45 07/04/2003 -0400, Joe Abley wrote:

>>Is it an explanation of the reasons why we should not run eBGP 
>>multi-hop? If so, I'm afraid I did not understand it.
>
>I don't know what reasons Randy had for reacting to your diagram, but 
>here
>are some thoughts.

This is for the benefit of the list... ;-)

Generally the problem with eBPG-multihop is that the next hop is not 
physically attached by a direct link to the router in question. It is 
somewhere out there, in the wide blue yonder. And you have to set up some 
other sort of routing entries to tell your router how to get to this 
next-hop. Usually people will point a static route for that particular 
address at something closer. Or do worse, as is often the case.

Now, many of us all understand how this works. And know the pitfalls. And 
many ISPs also understand this, and take the attitude of "ebgp-multihop 
over my dead body". The only uses they see are for things like loadsharing 
over parallel circuits between physically connected routers, or providing 
routing information to the many route views around the world.

But there seems to be an urban myth on the go which says that 
"ebgp-multihop" is good. I encounter it lots, and I'm accused of all sorts 
of things when I try and point out the problems. Anyone who has worked in 
operations, or in a NOC, or on customer support, trying to deal with a BGP 
customer or peer who is not very experienced with BGP and has a badly 
broken eBGP-mhop configuration will very quickly start cursing Cisco for 
even having the capability. (Well, I did in my past. ;-) The problem I've 
hinted at above - providing the routing information to get to the next hop. 
When this breaks, due to bad static route, bad connectivity, poor 
configuration of IGP, etc, etc, etc, some people find that their eBGP 
multihop sometime might still work, but the path taken by traffic is 
completely unexpected. Or the BGP bounces up and down for no apparent 
reason. Or is broken and they have no idea how to restart it. Customers 
generally don't understand BGP, so they whinge at the ISP for their network 
being broken. And the ISP wastes lots of time explaining to customer that 
it's the customer network which is "broken". And round it goes. Been there 
many times. :-(

So advice, and certainly best practice as far as I and many others are 
concerned, is to use eBGP-multihop as an absolute last resort, and even 
then only if you really understand what you are doing.

>Contrary to popular opinion, you don't need lots of RAM to run BGP.

Exactly!!! Another urban myth, no doubt helped by sales people and 
resellers trying to maximise their profits. A simple basic 2501 with IP 
software will run BGP just nicely. The  full routing table won't fit on 
there, but as I go on time and again, no one needs the full routing table 
unless they are seriously in the transit business with many diverse paths 
to many different parts of the Internet. If people don't believe me, check 
out the NANOG BGP tutorials for the configuration examples, distilled from 
configs of real live ISPs.

>  The chances are "entry router" above has more than enough horsepower 
> to
> announce local nets to "upstream router" and to learn a default using 
> BGP. A cisco 2501 with the minimum amount of RAM necessary to load an IP 
> image will do just fine.

Exactly. I wonder how many ISPs have I worked with to multihome with BGP 
using the basic original 4M RAM 4M FLASH 2501 router...  :))

>Simplicity and consistency are good. Complexity is best avoided.

Agreed with Joe 100%.

philip
--


-----
This is the afnog mailing list, managed by Majordomo 1.94.5

To send a message to this list, e-mail afnog at afnog.org
To send a request to majordomo, e-mail majordomo at afnog.org and put your
request in the body of the message (i.e use "help" for help)

This list is maintained by owner-afnog at afnog.org





-----
This is the afnog mailing list, managed by Majordomo 1.94.5

To send a message to this list, e-mail afnog at afnog.org
To send a request to majordomo, e-mail majordomo at afnog.org and put
your request in the body of the message (i.e use "help" for help)

This list is maintained by owner-afnog at afnog.org