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@myriverstreet.net> wrote:
Thanks, Mark, that makes sense.

Take care,
Ben

On Mon, Sep 16, 2019 at 9:05 AM Mark Tinka <mark.tinka@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.


--
Ben Logan
Senior Network Engineer | Working Lead
Wilkes Communications | RiverStreet Networks
 
Address: 1400 River St Wilkesboro, NC 28697
Phone: 336-973-9075
Mobile: 336-452-8072
 

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.