[c-nsp] BGP - advertising default route to Branch offices

[James Bensley]

On Thu, 13 Aug 2020 at 01:24, Yham <yhameed81 at gmail.com> wrote:
>
> Hello Gentlemen,

There's really no need to exclude women is there?

> Can anyone please tell which is considered a best practice when it comes to
> the advertising default route? If any vendor documentation addresses this,
> please feel free to share.

I'm not sure if there is a best practice here. My problem with "best
practices" is that they tend to draw people to the conclusion that
there is a single best way (or very small number of ways) of doing
something. I don't approve of "one size fits all" approaches because
your requirements aren't my requirements. The real question here, and
the info you need to provide the community in order to get the most
optimal response/advice is: what are you selling / what is your
requirement?

> I have 100+ branch offices peering BGP with Core and I need to advertise
> the default route (only) to them. Core switches are receiving the default
> route via eBGP from upstream devices. I can think of two ways to advertise
> the default route as follows
>
> 1- advertise/pass on the default route that core switches receive from
> upstream edge devices. Along with that add a static default route pointing
> to null0 with higher administrative distance and redistribute into BGP.
> that way if for any reason upstream edge devices stop advertising the
> default route, the static default route will kick in.

If your aggregation devices learn a default route via BGP from an
upstream device, why have the static null0 route? With the static
null0 route, if you lose the upstream BGP route you may pull traffic
from your remote devices, to your aggregation device which then drops
the traffic because it has no upstream route. If each site is sending
the aggregation device it's LAN prefix(es) then upstream routing to
the Internet would be lost in this case, but inter-site traffic would
still work. So what is the requirement here, to maintain inter-site
connectivity when upstream routing is dead, and only failover to the
other agg device when the first agg device is completely dead, or
failover over to your other aggregation device as soon as the default
route is lost?

> 2 - default-originate command under every BGP neighborship. I have 100+
> neighbors so configure this command for all.

^ If you have 100 BGP neighbours to configure, you possibly have 100
interfaces to configure, and 100 CPEs/remote devices to configure,
this extra bit of config won't change the configuration complexity
from O(1). Regardless of the config overhead, in this 2nd scenario
which involves re-advertising the default route from the upstream
device to the downstream remote devices without having a local static
route, seems to me to allow for failover between aggregation devices
when the default route is lost from an agg device's upstream device.
Is this a requirement for you? If so, then I'd choose roughly this
path.

I say roughly, because as others have said, you could in fact simply
place two static routes on your remote devices, one to each agg device
and then you can remove the complexity of BGP from them. Again, what
is your requirement here? If you don't expect to advertise additional
routes between agg devices and remote devices in the future, I'd
choose the static route method. If you do, I'd then choose BGP. I see
an IGP protocol like OSPF/ISIS/EIGRP as a last resort and/or for some
special exceptions.

Hopefully that helps.

Cheers,
James.