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

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

Jan 31, 2024, 12:30 PM

Post #1 of 10 (217 views)

Hey all,

This falls into the "Somebody is wrong on the Internet …" category.

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.

There are a bunch of reasons for this, but the standard (or easiest to
explain one!) is what happens if this comes from some provider space, and
they announce a supernet/covering route. If I *don't* have a
discard/hold-down route, and a packet is sent to part of the space I'm not
using (e.g 192.0.2.200), I would send it to the covering route, they would
just send it back to the more specific, I'd return it to them, etc…

Many, but not all mechanisms that people use for advertising a route in BGP
automagically create this sort of discard route (e.g Juniper's
'aggregate'), but I wasn't really able to find any useful documentation
suggesting that if you announce a route, you should make sure that you have
some route covering all of the space…

Perhaps there isn't really anything saying this (because it's obvious), but
I'd really like to find something so that I can point at it….

Can anyone help me win this somewhat pointless argument?
W

[0]: Best practice as in "you should do this, unless you've got some weird
corner case and have thought about it for more than a few seconds...."
[1]: Yes, in some cases I'll have e.g an interface that match the
announcement, and that accomplishes the same thing.
[3]: E.g. 192.0.2.0/24 comes from a provider, and they are announcing
something shorter.

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

nanog at nanog

Jan 31, 2024, 12:53 PM

Post #2 of 10 (217 views)

Permalink

> On Jan 31, 2024, at 12:30, Warren Kumari <warren@kumari.net> wrote:
>
> Hey all,
>
> This falls into the "Somebody is wrong on the Internet …" category.

Doesn’t everything eventually end up there?

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

Usually, but it’s not always necessary.

> There are a bunch of reasons for this, but the standard (or easiest to explain one!) is what happens if this comes from some provider space, and they announce a supernet/covering route. If I *don't* have a discard/hold-down route, and a packet is sent to part of the space I'm not using (e.g 192.0.2.200), I would send it to the covering route, they would just send it back to the more specific, I'd return it to them, etc…

Well… Unless you have some other more specific covering the rest of the space, yes, this is a risk.

> Many, but not all mechanisms that people use for advertising a route in BGP automagically create this sort of discard route (e.g Juniper's 'aggregate'), but I wasn't really able to find any useful documentation suggesting that if you announce a route, you should make sure that you have some route covering all of the space…

I don’t know if it’s documented, but it’s certainly common sense.

> Perhaps there isn't really anything saying this (because it's obvious), but I'd really like to find something so that I can point at it….

I think your “reason” paragraph above is quite sufficient explanation, no?

> Can anyone help me win this somewhat pointless argument?

No, because if you have an opponent who won’t buy the content of your reason paragraph above, you are arguing with someone who isn’t going to take any amount of fact or documentation over whatever ill conceived reality they have decided to live in.

You simply cannot win an argument when confronted with an opponent living in an alternative reality.

Owen

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

bill at herrin

Jan 31, 2024, 12:56 PM

Post #3 of 10 (217 views)

Permalink

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

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

warren at kumari

Jan 31, 2024, 1:46 PM

Post #4 of 10 (217 views)

Permalink

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…

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.

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

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

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

bill at herrin

Jan 31, 2024, 2:08 PM

Post #5 of 10 (217 views)

Permalink

On Wed, Jan 31, 2024 at 1:46?PM 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:
>> 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…

Hi Warren,

I'm not sure what you mean. Aggregation means that if at least one
more-specific is present, the aggregate will be announced. If none of
the more-specifics are present, the aggregate will not be announced.
If you have a default route, I suppose you could end up with a loop,
but that would be your fault for failing to tie down the route you
were announcing. Another reason why it's best practice to have that
explicit route to discard. If you don't have a default route,
recognize that there is an -implicit- discard route for default which
catches everything for which you do not have a route.

Regards,
Bill Herrin

--
William Herrin
bill@herrin.us
https://bill.herrin.us/

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

beecher at beecher

Jan 31, 2024, 2:20 PM

Post #6 of 10 (215 views)

Permalink

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

By spec, a route cannot be put into Adj-RIB-Out and announced to a peer
UNLESS that route exists in Loc-RIB, with a resolvable next-hop. ( RFC
4721, 9.1.3 . Your friend may need this :) )

It's certainly possible that a BGP implementation exists that violates this
rule, or hides the fact that it's doing this, but if it's standards
compliant this is what should be happening.

On Wed, Jan 31, 2024 at 4:47?PM 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…
>
> 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.
>
> There are also some more inventive ways of getting routes into BGP, like
> using ExaBGP as an example.
>
> 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/
>>
>
>

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

warren at kumari

Jan 31, 2024, 2:23 PM

Post #7 of 10 (215 views)

Permalink

On Wed, Jan 31, 2024 at 5:20 PM, Tom Beecher <beecher@beecher.cc> wrote:

> 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…
>>
>> 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.
>>
>
> By spec, a route cannot be put into Adj-RIB-Out and announced to a peer
> UNLESS that route exists in Loc-RIB, with a resolvable next-hop. ( RFC
> 4721, 9.1.3 . Your friend may need this :) )
>

Sweet! That seems exactly like what I need — I'll go rub his nose in it
(what else are friends for?)

Thank you.
W

> It's certainly possible that a BGP implementation exists that violates
> this rule, or hides the fact that it's doing this, but if it's standards
> compliant this is what should be happening.
>
> On Wed, Jan 31, 2024 at 4:47?PM 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…
>>
>> 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.
>>
>> There are also some more inventive ways of getting routes into BGP, like
>> using ExaBGP as an example.
>>
>> 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/
>>>
>>

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

nanog at nanog

Jan 31, 2024, 2:56 PM

Post #8 of 10 (215 views)

Permalink

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

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

warren at kumari

Feb 1, 2024, 2:20 PM

Post #9 of 10 (210 views)

Permalink

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

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

beecher at beecher

Feb 2, 2024, 2:42 PM

Post #10 of 10 (203 views)

Permalink

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