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

Wed Jan 31 20:30:08 UTC 2024

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240131/c983d5f0/attachment.html>