Community discussions

MikroTik App
 
jkroon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 58
Joined: Thu Apr 03, 2008 2:18 am
Contact:

BGP bogon filtering

Tue Aug 10, 2021 2:21 pm

Hi,

So looking at cymru, it's easy enough to import the unreachable routes. This is however not "good enough" (so we're going to deploy cymru to push unreachable/null routes to our edge devices via our reflectors). This will allow us to use loose rpf filtering (really which Mikrotik would allow us to set RPF level on a per interface level instead of globally since for customer facing interfaces we really want strict). to filter for these. However, consider a scenario where we would receive an advertisement (fictitious example, trimmed a bit):

```
kerberos# sh ipv6 bgp 8123::/16
BGP routing table entry for 2002::/16
Paths: (3 available, best #3, table Default-IP-Routing-Table)
65530 65534, (Received from a RR-client)
:: (metric 11) from 172.31.255.5 (154.73.32.5)
Origin IGP, localpref 150, valid, internal
Community: 857:0
Last update: Fri Aug 6 07:23:56 2021
```
Note that the bogon route is 8000::/1, so with 8123::/16 being more specific, this range is now effectively jacked.

So we really want to prevent our edges from accepting 8000::/1-128 in the first place. Looking at CYMRU there are 124200 such IPv6 and 1384 such IPv4 ranges (which includes the space still sitting with the 5 RIRs).

We've tried creating a really, really large route-filter but this didn't pan out so well on MT. We have two options:

1. Create VRFs in a way that allows us to filter this using quagga (which we're hoping can deal with this better). Has the added bonus of preventing external parties from (ab)using our network for transit using a (very cheap) RPF type filter rather than netfilter (/ip firewall). Still need to figure out the details. This does have benefits, simplicity isn't one of them. Plus we're having trouble figuring out how to set this up on MT to function correctly.

2. Find a more efficient way to route-filter. The current mechanism (/routing filter add chain="bogon8" action=discard prefix="8000::/1" prefix-length=1-128) basically ends up not scaling at all. Not to mention that even just importing 120k rules into the route filter takes several hours, it gets as bad as causing routing failures due to bgp failing to function whilst this is ongoing (in spite of the filters not even being active yet, simply loading it into an unused route-filter set). And to update is actually hard unless we also start keeping track of which routes gets removed from the bogon list from cymru (not impossible, just hard).

We'd like to know how other parties are dealing with these things. If there is a way to match incoming advertised routes against routes with a specific community or even route distinguisher, that would be great as well, or even against an address-list (as in ipset). I know from Linux one can "ipset test ..." but this could potentially be a somewhat expensive operation. One could then reload the entire bgon set every now and again with (mikrotik equivalent of) "set add bogons4 10.0.0.0/8 timeout 172800 -exist" This would mean that from the moment a new range gets allocated and cymru picks up on it, it'll be less than 48 hours until we permit the range too. Why 48 horus? Because if you're familiar with RIR systems you'll be aware that within 48 hours after initial allocation it's highly unlikely the range will actually be usable.

Who is online

Users browsing this forum: manish and 12 guests