Routing blackhole

Rudios · Fri Sep 30, 2016 2:57 pm

I have a system consisting of multiple MikroTik routers (MT1 MT2, MT3 and MT4), all connected towards 1 central Mikrotik (MTC) which has an internet connection.
MT1, MT2, MT3 and MT4 are all handling their own 192.168.x.0/24 ip segment and OSPF is running.
In order to prevent unnecessary routing towards the MTC i'm looking into blackholing specific IP ranges, specifically the private 192.168.x.0/24 ranges NOT used by any of the MT1, MT2, MT3 or MT4.
What I was thinking is adding the following rule

/ip route add dst-address=192.168.0.0/16 type=blackhole

Is it wise to do this or is it just bogus?

haik01 · Fri Sep 30, 2016 5:17 pm

Why /16?

And if you try it, what happens?

are you coming to the MUM in Amsterdam?

skuykend · Fri Sep 30, 2016 8:11 pm

I've been doing that with a metric of 5 to avoid routing any 192.168. that doesn't have a lower value metric route without problem.

che · Fri Sep 30, 2016 8:41 pm

I think you are trying to secure the routing table? If you do, the method you want to use is route filters (ospf-in and ospf-out). By blackholing whole /16 segment (and announcing it to other routers by enabling redistribute-static?) you did the opposite - you made whole segment always reachable up to your gateway router. I am also assuming all of your border routers have default gateways (0.0.0.0/0), in which case blackholing does nothing. Blackholing is usually used to prevent frequent routing table updates or preventing specific traffic from reaching past the router.

Setting metric of your BH /16 segment to 5 doesn't do anything compared to distance 1, since more specific routes (your /24 segments) have priority and default OSPF route distance is 110 anyway.

Fri Sep 30, 2016 8:49 pm

This is very normal and actually good practice.

Metrics don't come into play the way you're thinking.
192.168.0.0/16 is a "broad" route - meaning that it is not as specific as your active networks.
So if router C has a blackhole for 192.168.0.0/16 and a route for 192.168.1.0/24 to R1 for instance, a packet destined for 192.168.1.98 is going to match the most specific route, i.e. 192.168.1.0/24.
Metrics are like tie breakers for two routes of the same specificity. So if you have two routes: 192.168.0.0/16 metric 1 gw=x.x.x.x and 192.168.0.0/16 blackhole metric 2, then as long as the x.x.x.x route is active, it will win because its distance metric is smaller.

Happy routing!

EDIT: re: announcing the blackhole route in OSPF:

You would generally not want to redistribute this into OSPF, but there would be no harm in doing so, since the edge routers will have a default GW pointing to the core router anyway.
To cut down on wasted throughput, you would want to blackhole 192.168.0.0/16 with a static route in every router.

Rudios · Mon Oct 03, 2016 8:07 am

@haik01
Like said by Che, more specific routes (I do have /24 for each segment) 'win' in favor of the /16.

@che
I'm not redistributing my statics within OSPF, I'm only distributing my default route from my central router which has a 0.0.0.0/0 towards the internet.

@ZeroByte
Adding a blackhole rule for the /16 was indeed the way I was tending to go.
An in the meantime I think I will also add 10.0.0.0/8 and 172.16.0.0/12 just to block all private ranges.

Does this still make sense?

Mon Oct 03, 2016 5:27 pm

@ZeroByte
Adding a blackhole rule for the /16 was indeed the way I was tending to go.
An in the meantime I think I will also add 10.0.0.0/8 and 172.16.0.0/12 just to block all private ranges.

Does this still make sense?

Definitely. I put those very routes in all of my border routers. No need wasting my bandwidth on packets to those addresses.

Rudios · Mon Oct 03, 2016 7:24 pm

@ZeroByte
Adding a blackhole rule for the /16 was indeed the way I was tending to go.
An in the meantime I think I will also add 10.0.0.0/8 and 172.16.0.0/12 just to block all private ranges.

Does this still make sense?
Definitely. I put those very routes in all of my border routers. No need wasting my bandwidth on packets to those addresses.

Thank you for your comments. I will put the blackhole routes as much as possible to all my configurations. Should be included in my default settings to consider when building a new config.

Rudios · Tue Oct 04, 2016 9:49 am

@ZeroByte
Adding a blackhole rule for the /16 was indeed the way I was tending to go.
An in the meantime I think I will also add 10.0.0.0/8 and 172.16.0.0/12 just to block all private ranges.

Does this still make sense?
Definitely. I put those very routes in all of my border routers. No need wasting my bandwidth on packets to those addresses.

I did want to rate your post positive to give you some credits, but how?

Tue Oct 04, 2016 5:33 pm

You have to give feedback directly to the user profile now. Mikrotik has disabled post up/down voting.

pe1chl · Tue Oct 04, 2016 5:47 pm

Definitely. I put those very routes in all of my border routers. No need wasting my bandwidth on packets to those addresses.

I also do that all the time, but normally I use "unreachable" instead of "blackhole":

/ip route
add distance=1 dst-address=10.0.0.0/8 type=unreachable                          
add distance=1 dst-address=169.254.0.0/16 type=unreachable                      
add distance=1 dst-address=172.16.0.0/12 type=unreachable                                      
add distance=1 dst-address=192.168.0.0/16 type=unreachable

Tue Oct 04, 2016 5:56 pm

For those who want to know the difference between blackhole and unreachable:

If the destination is black hole then the router just silently discards all packets which match the route.
If the destination is unreachable, then the router will drop the packets, but will also generate an ICMP destination unreachable message to the sender.
This would be good in an internal network because it will speed up failure detection.

Consider attempting an ssh connection to one of these addresses in both scenarios:
If the discarding router is a black hole, then the ssh client will just keep doing retries until it gives up and times out - this can take several seconds of staring at an empty window.
If the discarding router sends ICMP unreachable messages, then the client will get a nearly instant failure response. This is particularly good for automated processes because they'll run much faster if they don't waste tons of time waiting on timeouts to happen.

pe1chl · Tue Oct 04, 2016 9:04 pm

If the destination is unreachable, then the router will drop the packets, but will also generate an ICMP destination unreachable message to the sender.
This would be good in an internal network because it will speed up failure detection.

Also, when not using an OS that wants to hide all technical messages from the user, it gives you appropriate diagnositic messages.

ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Host Unreachable
From 192.168.1.1 icmp_seq=2 Destination Host Unreachable

This tells me that the 192.168.10.1 host is in an unreachable network, and that the 192.168.1.1 router is telling me that.
When there are other hops towards the destination that do not have the unreachable route entry, it tells me where that entry is located.
Often quite useful when looking for errors in a complicated network with autorouting (BGP, OSPF) etc....
But you know all about that

Rudios · Wed Oct 05, 2016 8:03 am

If the destination is unreachable, then the router will drop the packets, but will also generate an ICMP destination unreachable message to the sender.
This would be good in an internal network because it will speed up failure detection.
Also, when not using an OS that wants to hide all technical messages from the user, it gives you appropriate diagnositic messages.

ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Host Unreachable
From 192.168.1.1 icmp_seq=2 Destination Host Unreachable

This tells me that the 192.168.10.1 host is in an unreachable network, and that the 192.168.1.1 router is telling me that.
When there are other hops towards the destination that do not have the unreachable route entry, it tells me where that entry is located.
Often quite useful when looking for errors in a complicated network with autorouting (BGP, OSPF) etc....
But you know all about that

That makes even more sense!
I have set them all to unreachable now. Thank you all for the comments

Routing blackhole

Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Re: Routing blackhole

Who is online