On Wed, Jan 31, 2024 at 5:56 PM, Owen DeLong <o...@delong.com> wrote:
> On Jan 31, 2024, at 13:46, Warren Kumari <war...@kumari.net> wrote: > > > > > > On Wed, Jan 31, 2024 at 3:56 PM, William Herrin <b...@herrin.us> wrote: > >> On Wed, Jan 31, 2024 at 12:30 PM Warren Kumari <war...@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 >> b...@herrin.us >> https://bill.herrin.us/ >> >
