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

[Tom Beecher <beecher () beecher cc>]

> This sounded perfect, and I could beat my friend around the head with
> it… but reading further reveals:
> "Route aggregation and information reduction techniques (see
> Section 9.2.2.1) may optionally be applied.
>
>  Any local policy that results in routes being added to an Adj-RIB-Out
> without also being added to the local BGP speaker's forwarding table is
> outside the scope of this document."
I had to go into the weeds of the datatracker, but this thread discusses
the wording and meaning.

https://mailarchive.ietf.org/arch/msg/idr/JDPRPNUB0YhcZ5SqGHlg3jH8xGE/

Specifically this specific :
https://mailarchive.ietf.org/arch/msg/idr/1RglrwAgw5VIZSMxai-3fQRogzE/

The clause is saying 'A BGP route can validly be in Adj-RIB-Out, even if
it's not actually being used for forwarding.'  (Personally I think they
chose one of the clunkiest wordings suggested, but what do I know. :) )

FIB :
- Static route to D, next-hop FOO
- IGP route to BAR, next-hop BAZ
Loc-RIB : BGP route to D, next-hop BAR
Adj-RIB-Out : BGP route to D, next-hop BAR

The BGP route to D is permitted to be in Adj-RIB-Out because the
destination D AND next-hop BAR are both resolvable in the FIB. However, the
actual route *used* by the FIB is the static route to FOO because of admin
distance.




> I was initially excited by Tom's pointing at RFC4271, Sec 9.1.3, which
> states:
> "A route SHALL NOT be installed in the Adj-Rib-Out unless the
> destination, and NEXT_HOP described by this route, may be forwarded
> appropriately by the Routing Table."
>
> This sounded perfect, and I could beat my friend around the head with
> it… but reading further reveals:
> "Route aggregation and information reduction techniques (see
> Section 9.2.2.1) may optionally be applied.
>
>  Any local policy that results in routes being added to an Adj-RIB-Out
> without also being added to the local BGP speaker's forwarding table is
> outside the scope of this document."




On Thu, Feb 1, 2024 at 5:22 PM Warren Kumari <warren () kumari net> wrote:

> On Wed, Jan 31, 2024 at 5:56 PM, Owen DeLong <owen () delong com> wrote:
>
> > 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> wrote:
> >
> > > On Wed, Jan 31, 2024 at 12:30 PM Warren Kumari <warren () kumari net>
> > > wrote:
> > >
> > > So, let's say I'm announcing some address space (e.g 192.0.2.0/24), but
> > > I'm only using part of it internally (e.g 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 unless it knows a route to
> > > 192.0.2.0/24 or has been configured to aggregate any internal routes
> > > inside 192.0.2.0/24 to 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.
>
>
> Yah, agreed…. This seems "obvious", but is there actually anything that
> states this? I'm not really sure where I think that I'd find something
> authoritative *to* state something.
>
> Even though we claim to be network **engineers**, there isn't really very
> much documentation of correct behavior — there are things like the MANRS
> docs, and the short-lived BCOPS series, but much of the rest of the
> understanding of what is appropriate / best practice seems to be
> undocumented and passed on through cultural diffusion, pointing at some
> NANOG post from 1998, or vague handwaving  towards the cymu secure IOS
> template….
>
> I was initially excited by Tom's pointing at RFC4271, Sec 9.1.3, which
> states:
> "A route SHALL NOT be installed in the Adj-Rib-Out unless the
> destination, and NEXT_HOP described by this route, may be forwarded
> appropriately by the Routing Table."
>
> This sounded perfect, and I could beat my friend around the head with
> it… but reading further reveals:
> "Route aggregation and information reduction techniques (see
> Section 9.2.2.1) may optionally be applied.
>
>  Any local policy that results in routes being added to an Adj-RIB-Out
> without also being added to the local BGP speaker's forwarding table is
> outside the scope of this document."
>
> W
>
> > 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 doesn't count; it needs to know a route to 192.0.2.0/24.
> > > Sending 192.0.2.0/24 to discard guarantees that the router has a route
> > > to 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, so it'd withdraw the
> > > announcement for 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
> > > https://bill.herrin.us/