Consistent routing policy?

Mon Sep 16 15:26:26 UTC 2019

Ben,

To make it a bit cleaner, you most likely want to send your aggregate (/21)
to all service providers, and then if you choose to deaggregate and create
more specific advertisements for traffic engineering purposes, you just
advertise the relevant longer prefixes (/22's for example) on the specific
uplink you want the traffic to return on.

So for example, let's say you have a /21, and you want to split the traffic
across 2x /22's, you advertise the /21 on both ISP links, and a single
(different) /22 on each ISP link.

This way the more specific route (/22) will pull the traffic towards the
ISP that is advertising it, but in case of a failure on one of those links,
you still have the /21 aggregate that will pull all the traffic to the
other link.

This should generally work, but may have strange edge cases, especially
when ISPs do their own (not necessarily standard) traffic engineering.
For example ISP A, getting a /21 could set the local preference for that
/21 higher than other peers (where they would be learning your other /22),
so traffic originating from this local ISP would take the local path
regardless of your policy. This is when you will have to start looking at
their BGP communities...

Tnx
Arie

On Mon, Sep 16, 2019 at 7:13 AM Ben Logan <benlogan at myriverstreet.net>
wrote:

> Thanks, Mark, that makes sense.
>
> Take care,
> Ben
>
> On Mon, Sep 16, 2019 at 9:05 AM Mark Tinka <mark.tinka at seacom.mu> wrote:
>
>>
>>
>> On 16/Sep/19 14:47, Ben Logan wrote:
>> > Thanks, Mark.  So the discrepancy between what's being advertised (/21
>> > vs /22) shouldn't cause any issues?  That's the part I got a bit
>> > confused about.  I don't see how it would, but I wanted to make sure.
>>
>> Longest match always wins... so provided your /22's are in the global
>> table, traffic will follow the path toward them before the /21 is
>> preferred.
>>
>> So, for example, if the upstream to whom you are sending the /21 doesn't
>> do anything about how they learn the /22 from another source, (for their
>> network) they will also send traffic back to you via the /22 path. This
>> may or may not be preferred by you, or them. I suppose that's the main
>> thing to think about.
>>
>> Mark.
>>
>
>
> --
> <https://img.beta.newoldstamp.com/r/13887/p>
> Ben Logan
> Senior Network Engineer | Working Lead
> Wilkes Communications | RiverStreet Networks
>
> Address: 1400 River St Wilkesboro, NC 28697
> Email: benlogan at myriverstreet.net
> Phone: 336-973-9075
> Mobile: 336-452-8072
>  wilkes.net <https://www.wilkes.net>
>  myriverstreet.net <https://www.myriverstreet.net>
> <https://img.beta.newoldstamp.com/r/13833/facebook>
> <https://img.beta.newoldstamp.com/r/13833/twitter>
> <https://img.beta.newoldstamp.com/r/13887/youtube>
> <https://img.beta.newoldstamp.com/r/13833/linkedin>
> <https://img.beta.newoldstamp.com/r/13833/instagram>
>
>
> This email transmission contains information which may be confidential
> and/or privileged. The information is intended to be for the use of the
> individual or entity named on this transmission. If you are not the
> intended recipient, be aware that any disclosure, copying, distribution or
> use of the contents of this email information is prohibited. If you have
> received this email in error, please notify the sender to arrange for
> retrieval of the original documents. Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190916/0c363f4f/attachment.html>