[afnog] RE : Re: RE : Re: hrobert@iservices.tg

[Mark Tinka]

On Tuesday 01 August 2006 13:50, AINA ALAIN PATRICK(TRS) wrote:

> 3- You are currently announcing the same sets of /24 of your
> customers  blocks to the three neighbors and is receiving
> defaults from them

I'm not sure if this was mentioned in previous posts, but are you 
receiving a full BGP feed from your upstream?

>
> 4- You want to do loadsharing based on this scheme:
>
> "For each costumer, use one link as primary and the two other
> lines as backup with priority to one of the them."
>
>
> I think that one way to do it is :
>
> 1- outbound traffic
>
> With PBR ( i have no suggestions)

PBR would be good, but then he'd have 2 links un(der)utilized. 
One way to do this would be categorize his customers/production 
gear based on which source IP addresses they come from, and then 
write a policy route map forcing their outbound traffic via a 
specific interface, setting a secondary IP address in the 'set' 
section of route map in case the default interface were to 
transition to a state of up/down or down/down (not always 
reliable, as interface might be up but problem resides in 
upstream's core).

If he is getting full BGP feeds (plus a default route), then he 
would have load balancing by default (and would help detect 
far-end upstream issues). Manipulation of the LOCAL_PREF BGP 
attribute might help.

However, neither suggestion guarantees equal distribution of 
egress traffic across all three circuits. A lot of time and 
analysis of implementations will need to be spent.

> 2- Inbound traffic
>
> BGP with MED.
>
> For costumer X set metric of 100 on link 1 (primary), of 200 
> on link 2(first backup) and  of 300 on the last link.

Although I hadn't yet tried it, several months back, I was 
looking at exporting optional communities into my upstream's 
network to influence over which circuits return traffic arrives 
(some AS's have routing policies that will not "obey" any number 
of AS_PATH prepends you attach to a prefix).

Needless to say, this requires significant co-operation with your 
upstream (and perhaps, their upstreams).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://listserv2.cfi.co.ug/pipermail/afnog/attachments/20060801/4fa53e24/attachment.bin