From: Hansang Bae (hbae@xxxxxxxxxx)
Date: Sat Mar 09 2002 - 01:32:19 GMT-3
At 03:25 PM 3/8/2002 +0000, McCallum, Robert wrote:
>Why would a company want BGP?
>In what scenarios would it be good working policy to actually sell them BGP in
stead of advertising their netblock through redistribution means and giving the
m a default route.
>I have struggled with this question for a while and I can't really come up wit
h any hard evidence to the benefits of BGP for a customer.
>I mean what does BGP give a customer?
>Any thoughts welcome
**************************************************************************
From: Question 77
Date: 02 February 2002
Subject: What are the pro's and con's of using two ISP/BGP providers?
Answer by: vcjones@NetworkingUnlimited.com (Vincent C Jones)
>Why would you use BGP with 2 Internet T1 vs using equal cost
>static routing? What's the pros and cons? Thank you.
This question (or variations on it) get hashed out fairly routinely on
this newsgroup, hopefully Hansang will be able to include a brief
discussion in the FAQ even though it is not a Cisco specific problem.
The answer in a nutshell is: It depends.
If each T1 goes to a different ISP, then you must use BGP to have the
same public address regardless of route taken.
If each T1 goes to the same ISP and load sharing and ease of
setup/management is more important than availability, then go with
static routes.
If the T1 links do not support end-to-end keepalives, go with BGP to
avoid black holes.
If the T1 links go to different POPs of the same ISP, use BGP and
indicator routes to detect ISP segmentation.
If the T1 links go to geographically diverse POPs, then BGP with full or
local routes may improve routing efficiency.
For more detail, see the blurb I wrote for O'Reilly on the topic at
http://www.oreillynet.com/pub/a/network/2001/05/11/multihoming.html
(for those reading this out of the archives at a future date, a
more detailed version of this paper will be appearing as a White
Paper on my web site, but it will not be there until late Summer).
Chapter 8 of my book walks you through all the alternatives from
two T1s between a single router at your site and a single router
at the ISP, to two T1's between separate routers at your site to
two different ISPs. For how to get the most out of BGP, including
load sharing and efficiency considerations (my book only considers
availability), read Halabi's book.
If none of the above makes sense to you, hire a competent consultant
to walk you through the alternatives and their tradeoffs.
Note to Hansang: Feel free to extract/reuse whatever you need from
the O'Reilly blurb mentioned above, I own the copyright and will be
glad to give "reprint permission" to the FAQ as long as Networking
Unlimited gets proper credit.
***** The O'Reilly article follows: *****
by Vincent Jones 05/11/2001
Many organizations depend upon Internet connectivity to support critical
applications. One popular approach for improving Internet connectivity is to
connect to more than one Internet service provider (ISP), a technique called
multi-homing.
Multi-homing can be very effective for ensuring continuous connectivity --
eliminating the ISP as a single point of failure -- and it can be cost
effective as well. However, your multi-homing strategy must be carefully
planned to ensure that you actually improve connectivity for your company, not
degrade it.
THE CONCEPT OF PHYSICAL DIVERSITY
First, I want to discuss the network components that can affect overall
connectivity. Because most network failures are due to problems in the WAN
links, it does little good to connect to a second ISP if both ISP links are
carried over the same communications circuit. Even if independent circuits are
used -- if they are not physically diverse they will still be subject to common
failure events such as construction work inside your building or digging in the
street outside.
Providing complete physical diversity can be difficult and expensive, but the
requirement is not limited to ISP connections. All critical network links for
internal communications should also be diversified. Assuming an otherwise well-
designed internal network, the easiest way to achieve physical diversity in
your ISP connections is to connect from two different locations that are
already well-connected to each other. But they must be far enough apart that
they don't share any common communications facilities to either ISP.
REDIRECTING TRAFFIC USING THE BORDER GATEWAY PROTOCOL
Once physical connectivity is in place, you need to make it useful. Taking
advantage of redundant links requires two conditions to always be present.
First, you must be able to detect when a link has failed. Second, you must have
a mechanism for redirecting traffic that would normally flow across a failed
link to take a different path that is still functional. In a multi-homing
environment, both tasks are normally achieved by running Border Gateway
Protocol (BGP) between your routers and those of the ISPs.
BGP is often assumed to mean complex configurations on expensive, high-end
routers to handle the huge routing tables required to fully describe the
Internet. However, depending upon the specific application requirements and the
degree of load-balancing you want across all available links, it may be
practical to implement multi-homing using the smallest routers you have
available that are capable of handling the traffic load.
In other words, implementing multi-homing doesn't have to be an all-or-nothing
choice. There are choices you can make along the way based upon the equipment
you have available and the level of connectivity you need to provide.
DETERMINING LEVEL OF CONNECTIVITY REQUIRED
At one extreme, when your goal is to simply to provide internal users with
access to the Internet, you don't need to run BGP at all. As long as the link
layer protocol supports the exchange of keep-alive messages from router to
router, link failure will be detected by the link layer protocol. Floating
static routes can then reliably direct all outbound traffic to a working ISP
link.
Network Address Translation (NAT) is then used to send outbound packets with a
source IP address associated by the ISP with that outbound link. Return traffic
will automatically come back via the same working link because that link is the
only link servicing that address range.
Of course this approach will not work if you are providing services to the
outside world, as the addresses associated with the failed link will disappear.
Similarly, connections that were established over the link that failed will
need to be reconnected. However, for many applications this impact is minor.
For example, a typical web surfer would merely need to hit the "page refresh"
button. This approach is also sufficient to provide high-availability virtual
private networks (VPN) across the Internet if you use a routing protocol such
as OSPF to detect and route around failed IPSec tunnels.
The other extreme would be when you need to support a common IP address range
using both ISPs. Then you need to run BGP. This will normally be the case any
time your applications include providing services to Internet users, such as
access to a common database. You will need to arrange for both ISPs to accept
your BGP advertisements of your IP address prefixes. Then your ISPs need to
advertise those address prefixes to the rest of the Internet.
Getting your address prefixes advertised is usually not a problem. You do,
however, have to use care in your configuration to ensure that you do not
inadvertently advertise any other address prefixes. In particular, you must
ensure that you do not advertise yourself as a path between the two ISPs. This
could cause your links to be consumed by transit traffic of no interest to you.
More challenging is setting up your advertisements so that incoming traffic is
reasonably balanced between the ISP links. Achieving that can be difficult at
best, and nearly impossible at worse.
CHOOSE THE RIGHT ROUTE FOR YOU
The final decision is determining which routes to accept from each ISP. This
can range from merely accepting a default route (used to detect if the link is
up or down) to accepting all routes (so called "running defaultless"). The
former is usually insufficient, because it does not protect you from an ISP
which has an internal failure cutting them off from the rest of the Internet.
The latter requires using "carrier-class" routers with lots of memory installed
(and therefore more expensive). Fortunately, there are some "in-between"
choices.
Rather than using a simple default route, you can use a conditional default
route to protect against ISP failure behind the ISP's router that serves you. A
conditional default route is a default route that is defined by a router only
if a specific address is already in that router's routing table. Each ISP is
only used for a default route if it is advertising one or more routes that
indicate it is receiving advertisements from the rest of the Internet. That
way, you will always use a default route which promises to be useful.
Another option is to have the ISP send you just its local routes. That way, you
can optimize your outbound routing to avoid sending packets that could be
locally delivered to the wrong ISP, adding to delivery delays. Care must be
taken when using this option, however, because some ISPs have so many local
routes that there is no cost benefit in the size of the routers required to
handle them compared to running defaultless.
Options can also be combined. In many cases, taking local routes and a
conditional default route will provide all the availability benefits of running
defaultless, while still allowing the use of low-cost routers. As is always the
case in networking, a good understanding of the requirements and the available
capabilities is essential to maximizing cost-effectiveness.
******************************************************************
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:56:57 GMT-3