Mailing List Archive

On 8/12/20 5:20 PM, Yham wrote:
> Hello Gentlemen,
> 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.
> 2 - default-originate command under every BGP neighborship. I have 100+
> neighbors so configure this command for all.
>
> 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.
>
Hello

This really sounds like OSPF may have been a better choice, IMHO.

Do you have more than one link back to core from each site? If not, then
why not just stick with/use a static default? Easier to configure and
nearly goof-proof.

Otherwise, I would think that 'default-originate' would be the better
choice under each neighborship.

Mike-

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Thanks Mike for the input.

Its bgp end to end (branch switches <-bgp-> core switches <-bgp-> edge
devices). branch switches dual home to two core switches.

On Wed, Aug 12, 2020 at 9:31 PM Mike <mike+lists@yourtownonline.com> wrote:

> On 8/12/20 5:20 PM, Yham wrote:
> > Hello Gentlemen,
> > 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.
> > 2 - default-originate command under every BGP neighborship. I have 100+
> > neighbors so configure this command for all.
> >
> > 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.
> >
> Hello
>
> This really sounds like OSPF may have been a better choice, IMHO.
>
> Do you have more than one link back to core from each site? If not, then
> why not just stick with/use a static default? Easier to configure and
> nearly goof-proof.
>
> Otherwise, I would think that 'default-originate' would be the better
> choice under each neighborship.
>
> Mike-
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Thu, 13 Aug 2020 at 03:25, Yham <yhameed81@gmail.com> wrote:

> 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.

In my opinion there is never a need to carry default route in dynamic
routing protocols, it's always inferior solution to static.

In this particular case, two options

1) BGP
a) Advertise some candidate route from BGP (like your PA aggregate,
which you originate from stable backbone boxes)
b) Recursive static default route in branch routers pointing to the PA
aggregate as next-hop

2) IGP
a) have loopback42 in every LSR/P box with same IP address, which you add to IGP
b) Recursive static default route in branch routers pointing to the
loop42 address as next-hop

In both cases isolated edge won't blackhole the the branch by
advertising default it doesn't have as well as you'll always choose
closest working exit.


--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi,

On Wed, Aug 12, 2020 at 08:20:39PM -0400, Yham wrote:
> 2 - default-originate command under every BGP neighborship. I have 100+
> neighbors so configure this command for all.

Peer-groups are an amazing invention.

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

Gert Doering wrote on 13/08/2020 08:40:
> Peer-groups are an amazing invention.

+ if it's 100+ neighbours, then automation would be useful.

Nick
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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