Re: If I announce 192.0.2.0/24, do I need a discard route? (Looking for a reference…)

[Owen DeLong via NANOG <nanog () nanog org>]

> On Jan 31, 2024, at 13:46, Warren Kumari <warren () kumari net> wrote:
>
>
>
>
>
> On Wed, Jan 31, 2024 at 3:56 PM, William Herrin <bill () herrin us <mailto:bill () herrin us>> wrote:
> > On Wed, Jan 31, 2024 at 12:30 PM Warren Kumari <warren () kumari net <mailto:warren () kumari net>> wrote:
> >
> > So, let's say I'm announcing some address space (e.g 192.0.2.0/24 <http://192.0.2.0/24>), but I'm only using part of 
> > it internally (e.g 192.0.2.0/25 <http://192.0.2.0/25>). I've always understood that it's best practice[0] to have a 
> > discard route (eg static to null0/discard or similar[1]) for what I'm announcing.
> >
> > Hi Warren,
> >
> > Your router won't announce 192.0.2.0/24 <http://192.0.2.0/24> unless it knows a route to 192.0.2.0/24 
> > <http://192.0.2.0/24> or has been configured to aggregate any internal routes inside 192.0.2.0/24 
> > <http://192.0.2.0/24> to 192.0.2.0/24 <http://192.0.2.0/24>.
>
>
> It that always true? I'd started off thinking that, but a friend of mine (yes, the same one that started this  
> argument) convinced me that some forms of BGP summarization/aggregation don't always generate a "local" route…

It’s not ALWAYS true. For example, aggregate-address commands and equivalent on many platforms will cause the route to 
be announced if any component prefixes are present in the RIB on some platforms.

There are also some cases where “auto-summary” (does anyone actually use this? EVER?) will have a similar effect.

There are also some implementations where disabling synchronization or in many cases where synchronization has simply 
been deprecated by the implementor where any bap “network” statement (or equivalent) will result in announcement 
regardless of what’s in the RIB.

> I'd also thought that I'd seen this when redistributing an IGP into BGP, and using that as a contributor to 
> 'aggregate-address' on Cisco devices. This is from a long time ago, and really hazy now, but I'd thought that any 
> contributor would cause that the aggregate-address route to be announced, and a local hold down not to be created.  
> It's possible that a: I'm just wrong b: this is not longer true, c: both of the above.

Redistributing an IGP into BGP is almost always a bad idea. However, that aside, yes, as mentioned above, exactly what 
you are saying here is true with or without the redistribution on most platforms IIRC.

a: you are not wrong
b: it’s still true on many platforms at least (though may be implementation dependent)
c: no, but it’s certainly not best practice to behave in this way or depend on either of these behaviors for the other 
original reason you stated among other reasons.

With BGP, you really want to have a deterministic clean definition of what your router will do. As a general rule, if 
your peer is reachable, you usually want to advertise your originated routes to them and make damn sure your router can 
reach those some how no matter what.

> There are also some more inventive ways of getting routes into BGP, like using ExaBGP as an example.

Sure, but using ExaBGP really amounts to originating the prefix from another router. This discussion was (at least 
theoretically) about local origination on the router in question.

Owen

> W
>
>
>
> > 192.0.2.0/25 <http://192.0.2.0/25> doesn't count; it needs to know a route to 192.0.2.0/24 <http://192.0.2.0/24>. 
> > Sending 192.0.2.0/24 <http://192.0.2.0/24> to discard guarantees that the router has a route to 192.0.2.0/24 
> > <http://192.0.2.0/24>.
> >
> > Historically, folks would put 192.0.2.0/24 on the ethernet port. Then, when carrier was lost on the ethernet port 
> > for a moment, the router would no longer have a route to 192.0.2.0/24 <http://192.0.2.0/24>, so it'd withdraw the 
> > announcement for 192.0.2.0/24 <http://192.0.2.0/24>. This is a bad idea for obvious reasons, so best practice was to 
> > put a low priority route to discard as a fall-back if the ethernet port briefly lost carrier.
> >
> > Regards, 
> > Bill Herrin
> >
> > -- 
> > William Herrin 
> > bill () herrin us <mailto:bill () herrin us> 
> > https://bill.herrin.us/