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

Warren Kumari warren at kumari.net
Wed Jan 31 22:23:48 UTC 2024


On Wed, Jan 31, 2024 at 5:20 PM, Tom Beecher <beecher at 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 at kumari.net> wrote:
>
>>
>>
>>
>>
>> On Wed, Jan 31, 2024 at 3:56 PM, William Herrin <bill at herrin.us> wrote:
>>
>>> On Wed, Jan 31, 2024 at 12:30 PM Warren Kumari <warren at 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 at herrin.us
>>> https://bill.herrin.us/
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240131/dde77f2f/attachment.html>


More information about the NANOG mailing list