[c-nsp] BGP for multi-homed environment

[Mark Tinka]

On Monday 06 September 2004 18:21, Alex Foster wrote:
> To begin with Im a novice with BGP and its terminology so please forgive
> any inaccuracies.

No problem.

> I am migrating our existing network from a single 
> upstream connection to a dual-fed environment (different ISPs).

Goodie.

> I have all 
> the BGP information that I need (AS numbers etc) but am a little unsure as
> to the best topology/configuration to implement.  I want to connect each
> feed into a separate router and load share from my network.

If you have the hardware, this is usually the best approach, so that you have 
both IP link and hardware failover/redundancy.

> First off - is 
> this possible ??

This is very possible!

> I have been allocated a class C address block.

Didn't know 'Class-types' addressing were still used in a sentence, but I am 
assuming you mean you have demarcated a /24 for this. 

In most cases, however, most networks on the Internet will filter on /24's. 
With 2 providers, you will most likely want to announce a shorter netmask, 
e.g. /23 or shorter, so you can have enough room to leverage your redundancy.

> I also  
> want the ability to provide seamless failover between both providers.

This is possible. Since you will have 2 border router, each connected to one 
provider, they will need to be concentrated into one (or two) aggregation 
routers that provide access to the rest of your network/customers.

Accepting full BGP feeds from your providers will work great - if you pass 
those routes on to your aggregation router(s), your network will be able to:

a) Pick the best route to a destination.

b) Failover to your secondary router, in case the primary one fails

> I am 
> also a little unsure as to what is required with regards to filtering etc; 
> what is the best policy here??

This could be lengthy, but the way you announce your networks to your 
providers will influence your return traffic over both circuits. Typical load 
balancing measures will include announce longer prefixes over certain paths 
and prepending (increasing the AS_PATH).

Choice of outbound traffic will depend on best path chosen from routes you 
accept from your providers. However, these can be influenced by using the 
LOCAL_PREF attribute.

Most of these load balancing features will come into play depending on the 
size of your links, and which link you'd like to carry most of your traffic.

As for filtering, prefix-lists and filter-lists are typical. For outbound 
announcements to your providers, announce only:

a) Your networks
b) Keep them no longer than /24
c) Filter out RFC1918 and other private IP's.


For inbound announcements from your providers, accept only:

a) Full routes (if your router can handle that)
b) Default information (in case you can't handle full routes)
c) Don't accept prefixes longer than /24
d) Your providers networks and their immediate customers (covered by part a))


Also, make sure your networks/ASN are registered in your respective RIR 
database, and ensure your providers advise their providers of your 
networks/ASN, so they open their filters. 

For some providers that update their filters using RPSL, this could take a 
couple of hours, but usually no more than a day.

> If anybody implements a similar configuration - I would appreciate some
> tips or feedback.

These are just some general tips in your quest to setup your BGP. Feel free to 
ask more questions as you go along.

Mark.

>
> Kind Regards
>
> Alex
>
>
> The information in this e-mail and any attachments is confidential and may
> be subject to legal professional privilege. It is intended solely for the
> attention and use of the named addressee(s). If you are not the intended
> recipient, or person responsible for delivering this information to the
> intended recipient, please notify the sender immediately. Unless you are
> the intended recipient or his/her representative you are prohibited from,
> and therefore must not, read, copy, distribute, use or retain this message
> or any part of it. The views expressed in this e-mail may not represent
> those of Gamma Telecom.
>
> This message has been scanned for viruses by MailController
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/