Mailing List Archive

BGP route announcements and Blackholes
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 when creating a /32 static discard route
to announce to that blackhole peer.

The blackhole peer does receive the /32 announcement, but the aggregate
route also becomes discarded and thus routes to the other peers stop
working.

Been trying to determine just how to accomplish this function without
killing all routes.

So we have several /30 to /23 routes within our /19 block that are
announced via OSPF from our switches to the routers. The routers aggregate
these to the /19 to announce the entire larger block to the backbone
providers.

The blackhole peer takes routes down to a /32 for mitigation of an attack.
If we add a static route as "route x.x.22.12/32 discard" we get:

show route x.x.22.10

inet.0: 931025 destinations, 2787972 routes (931025 active, 0 holddown, 0
hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

x.x.0.0/19 *[OSPF/125] 5d 19:26:19, metric 20, tag 0
> to 10.20.20.3 via ae0.0
[Aggregate/130] 5d 20:18:36
Reject


While we see the more specific route as discard:

show route x.x.22.12

inet.0: 931022 destinations, 2787972 routes (931022 active, 0 holddown, 0
hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
x.x.22.12/32 *[Static/5] 5d 20:20:07
Discard



Does anyone have a working config for this type of setup that might be able
to share some tips or the likes on what I need to do or what I'm doing
wrong?

Best,

-Lee
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP route announcements and Blackholes [ In reply to ]
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 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 when creating a /32 static discard route
> to announce to that blackhole peer.
>
> The blackhole peer does receive the /32 announcement, but the aggregate
> route also becomes discarded and thus routes to the other peers stop
> working.
>
> Been trying to determine just how to accomplish this function without
> killing all routes.
>
> So we have several /30 to /23 routes within our /19 block that are
> announced via OSPF from our switches to the routers. The routers aggregate
> these to the /19 to announce the entire larger block to the backbone
> providers.
>
> The blackhole peer takes routes down to a /32 for mitigation of an attack.
> If we add a static route as "route x.x.22.12/32 discard" we get:
>
> show route x.x.22.10
>
> inet.0: 931025 destinations, 2787972 routes (931025 active, 0 holddown, 0
> hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
>
> x.x.0.0/19 *[OSPF/125] 5d 19:26:19, metric 20, tag 0
> > to 10.20.20.3 via ae0.0
> [Aggregate/130] 5d 20:18:36
> Reject
>
>
> While we see the more specific route as discard:
>
> show route x.x.22.12
>
> inet.0: 931022 destinations, 2787972 routes (931022 active, 0 holddown, 0
> hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
> x.x.22.12/32 *[Static/5] 5d 20:20:07
> Discard
>
>
>
> Does anyone have a working config for this type of setup that might be able
> to share some tips or the likes on what I need to do or what I'm doing
> wrong?
>
> Best,
>
> -Lee
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP route announcements and Blackholes [ In reply to ]
On Tue, 19 Mar 2024 at 19:44, Lee Starnes via juniper-nsp
<juniper-nsp@puck.nether.net> 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 is not clear to me what the actual problem is.

Of course if you want a blackhole, you want an internal blackhole too,
so you internally are going to add some route to discard,
then this is the route you'd leak to upstream.

How this would impact the next-hop type or readversability of the
aggregate is unclear to me, unless you're blackholing the next-hop of
some route.




--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP route announcements and Blackholes [ In reply to ]
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 when you create the /32 discard, you stop advertising the
/19? or something else?

P

On Tue, Mar 19, 2024 at 1:44?PM Lee Starnes via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> 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 when creating a /32 static discard route
> to announce to that blackhole peer.
>
> The blackhole peer does receive the /32 announcement, but the aggregate
> route also becomes discarded and thus routes to the other peers stop
> working.
>
> Been trying to determine just how to accomplish this function without
> killing all routes.
>
> So we have several /30 to /23 routes within our /19 block that are
> announced via OSPF from our switches to the routers. The routers aggregate
> these to the /19 to announce the entire larger block to the backbone
> providers.
>
> The blackhole peer takes routes down to a /32 for mitigation of an attack.
> If we add a static route as "route x.x.22.12/32 discard" we get:
>
> show route x.x.22.10
>
> inet.0: 931025 destinations, 2787972 routes (931025 active, 0 holddown, 0
> hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
>
> x.x.0.0/19 *[OSPF/125] 5d 19:26:19, metric 20, tag 0
> > to 10.20.20.3 via ae0.0
> [Aggregate/130] 5d 20:18:36
> Reject
>
>
> While we see the more specific route as discard:
>
> show route x.x.22.12
>
> inet.0: 931022 destinations, 2787972 routes (931022 active, 0 holddown, 0
> hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
> x.x.22.12/32 *[Static/5] 5d 20:20:07
> Discard
>
>
>
> Does anyone have a working config for this type of setup that might be able
> to share some tips or the likes on what I need to do or what I'm doing
> wrong?
>
> Best,
>
> -Lee
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP route announcements and Blackholes [ In reply to ]
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 discard (presumably to send to the RTBH peer ) , your
aggregate is 'impacted' somehow.

There's not enough info to fully grasp what is going on here.(What does
"impacted" mean?) But a couple points.

1. Aggregate routes are intentionally NH discard all the time. The intent
is that traffic for the entire /19 would come to this router, and that you
will have more specific routes for parts of the /19 you're actually using.
Anything not covered by a more specific would just be dropped. You can
change this if you want, but normally don't need to.
2. This may be part of your issue.

x.x.0.0/19 *[OSPF/125] 5d 19:26:19, metric 20, tag 0
> to 10.20.20.3 via ae0.0
[Aggregate/130] 5d 20:18:36
Reject

Aggregates are not installed unless there is a contributing route present
as well. Contributing route must be a route with a longer mask covered by
the aggregate; can't be an exact match. This means that your OSPF /19 is
NOT the contributor to the aggregate, it must be something else. ( Also,
OSPF/125 ? )

If I had to guess, you're doing something here that is impacting the
contributing routes, causing the aggregate to disappear.

On Tue, Mar 19, 2024 at 1:43?PM Lee Starnes via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> 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 when creating a /32 static discard route
> to announce to that blackhole peer.
>
> The blackhole peer does receive the /32 announcement, but the aggregate
> route also becomes discarded and thus routes to the other peers stop
> working.
>
> Been trying to determine just how to accomplish this function without
> killing all routes.
>
> So we have several /30 to /23 routes within our /19 block that are
> announced via OSPF from our switches to the routers. The routers aggregate
> these to the /19 to announce the entire larger block to the backbone
> providers.
>
> The blackhole peer takes routes down to a /32 for mitigation of an attack.
> If we add a static route as "route x.x.22.12/32 discard" we get:
>
> show route x.x.22.10
>
> inet.0: 931025 destinations, 2787972 routes (931025 active, 0 holddown, 0
> hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
>
> x.x.0.0/19 *[OSPF/125] 5d 19:26:19, metric 20, tag 0
> > to 10.20.20.3 via ae0.0
> [Aggregate/130] 5d 20:18:36
> Reject
>
>
> While we see the more specific route as discard:
>
> show route x.x.22.12
>
> inet.0: 931022 destinations, 2787972 routes (931022 active, 0 holddown, 0
> hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
> x.x.22.12/32 *[Static/5] 5d 20:20:07
> Discard
>
>
>
> Does anyone have a working config for this type of setup that might be able
> to share some tips or the likes on what I need to do or what I'm doing
> wrong?
>
> Best,
>
> -Lee
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP route announcements and Blackholes [ In reply to ]
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 those to a /19 by the routers, I personally wouldn't
redistribute the aggregated /19 back to OSPF. Without knowing the
details could it be that when advertising the aggregate to your peers
your BGP policy is expecting that the /19 route is from protocol
aggregate, but when the OSPF route is the best/active route, it either
does not match the policy or does not contain all the required
communities? But without knowing the details it is hard to say for sure.

There seem to be some intentional design choices being made wrt OSPF
routes, as the OSPF route has a protocol preference (a.k.a. admin
distance) of 125, which is OTOH not a default value for OSPF external
routes. If you have an aggregate route I would assume that you would
want to have it as a best/active route because what would be the point
of the aggregate route otherwise?

Kindly,

Antti


On 19/03/2024 19.43, Lee Starnes via juniper-nsp wrote:
> 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 when creating a /32 static discard route
> to announce to that blackhole peer.
>
> The blackhole peer does receive the /32 announcement, but the aggregate
> route also becomes discarded and thus routes to the other peers stop
> working.
>
> Been trying to determine just how to accomplish this function without
> killing all routes.
>
> So we have several /30 to /23 routes within our /19 block that are
> announced via OSPF from our switches to the routers. The routers aggregate
> these to the /19 to announce the entire larger block to the backbone
> providers.
>
> The blackhole peer takes routes down to a /32 for mitigation of an attack.
> If we add a static route as "route x.x.22.12/32 discard" we get:
>
> show route x.x.22.10
>
> inet.0: 931025 destinations, 2787972 routes (931025 active, 0 holddown, 0
> hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
>
> x.x.0.0/19 *[OSPF/125] 5d 19:26:19, metric 20, tag 0
> > to 10.20.20.3 via ae0.0
> [Aggregate/130] 5d 20:18:36
> Reject
>
>
> While we see the more specific route as discard:
>
> show route x.x.22.12
>
> inet.0: 931022 destinations, 2787972 routes (931022 active, 0 holddown, 0
> hidden)
> @ = Routing Use Only, # = Forwarding Use Only
> + = Active Route, - = Last Active, * = Both
> x.x.22.12/32 *[Static/5] 5d 20:20:07
> Discard
>
>
>
> Does anyone have a working config for this type of setup that might be able
> to share some tips or the likes on what I need to do or what I'm doing
> wrong?
>
> Best,
>
> -Lee
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp