On Thu, 13 Aug 2020 at 01:24, Yham <[email protected]> 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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
