I've also hade some hard times to understand the original problem
statement. However, IMHO there is one confusing potential design flaw in
the setup and it is that the aggregated /19 route is also redistributed
into OSPF by some router(s). If you have more specific routes in OSPF
and aggregate
I've read this a couple times. Also confused, but I think this is what you
are saying :
- You have a /19 aggregate that is announced via BGP to upstreams.
- You use an upstream RTBH service that will sink a particular destination
via a BGP announcement to a particular peer.
- When you add a /32
Don't really follow this either. Aggregate routes should use a discard NH
- I always tend not to use the aggregate route type and simply use static
routes with discard NH and attach the BGP communities I need directly to
them, but I don't see how this is an issue in your case.
Are you saying
On Tue, 19 Mar 2024 at 19:44, Lee Starnes via juniper-nsp
wrote:
> The blackhole peer does receive the /32 announcement, but the aggregate
> route also becomes discarded and thus routes to the other peers stop
> working.
I couldn't follow this, and the output you shared didn't support it.
So it
What about no-install
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/no-install-edit-protocols.html
?
On Tue, 19 Mar 2024 at 10:44, Lee Starnes via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hello Juniper gurus. I am seeing an issue where
Hello Juniper gurus. I am seeing an issue where we have a carrier that does
RTBH via BGP announcement rather than community strings. This is done via
BGP peer to a blackhole BGP router/server.
My issue here is that our aggregate IP block that is announced to our
backbone providers gets impacted
6 matches
Mail list logo
