is that part your current problem?
This is but one symptom of a larger problem, a problem that needs to be addressed, and the issue reported here would have been an ideal solution, especially when combined with the ability to push prefixes into address lists from route filters.
that wasn't other as'es fault. that's how ebgp works. all providers do the same thing: which is do some filter, prepend etc. bgp is about mind games between friends.
Agreed, but it's not mind games either, if you think it is perhaps you need to re-evaluate some of your assumptions. Please understand what the problem is before posting so called solutions. I've been at this for nearly two decades, and ROS7 is finally touching on some aspects for which I've been asking and hoping for for more than a decade. Combined with FRR it seems we're finally starting to get some of the building blocks that's required for defence of the internet infrastructure as a whole.
I can do the required using as per mrz using a sequence of filters like:
if (dst in 192.168.0.0/16) { reject }
I have a few problems with this:
1. It's hard to dynamically add/remove IPT customer ranges to the bogon filter.
2. I can't sensibly import CYMRU bogon lists into route-filters to prevent receiving these routes as advertisements (installing blackhole routes is easy enough, but not good enough).
3. The list of bogon's isn't shared between the firewall and the route filters (a single source of truth should obviously always be preferred).
4. Maintaining such in two places on even a handful of edge routers is hard - imagine scaling that to several tens. Now you're beginning to feel the pain.
At the moment we've got a mechanism to update the address list semi dynamically by building it from from frr using a cron on a central server serving acting as a route-reflector on top of Linux (which means availability of bash), then performing some checksum magic and based on the checksum a rsc script can determine if the address list needs to be updated or not, we can then download the updated set as a rsc script (generated by shell script) and import that. So for a period of at most a few minutes we may have sub-optimal or non-existent routes for IPT customers where their L2 to us fails. This doesn't happen frequently, but it does happen, and in the one case where it happens most frequently it's usually one of their internal links that fails resulting in us falling back to a much less than optimal path for a few minutes compared to then just picking up their routes from a shared INX. Are you starting to get that my question is about much, much more than the over-simplified symptom raised here?
now... as i said the simplest thing - why would you comfortable on doing hard math logic just for filtering while your network on loops??
It's but one possible symptom of much larger eco-system that is significantly more complex than most people realise. Simplify the issue to get sensible answers. Solving hard math is, well, hard. So tackle sub problems and solve those. Then coalesce the smaller solutions into a larger more comprehensive but also more complex solution. Then go back and question everything and try and simplify again. As simple as possible but no simpler than required.
just find which prefix go back to you and from which peer, then - analyze those prefix, are they in /24 form or /23 like you say.
Right, so as it stands in the bogon filter there are just under 20 prefixes which is static, and another 10 or so that's dynamic (explanation above). The proposal you make here is exactly what got me to making this post. We'd have liked to reference address lists in the route filters rather than duplicating the address lists to the route filters.
my normal guess would be you advertise /24.
Incorrect assumption, typically anything between (including) /20 and /23 with only a handful of /24s. We already filter anything more specific than a /24 (v4) or a /48 (v6), but we can't outright just filter all /24s. We need this to be dynamic, so the bogon filter will based on the information from this topic need to be something like:
if (afi ipv4 && dst-len > 24) { reject; }
if (afi ipv6 && dst-len > 48) { reject; }
if (dst in 10.0.0.0/8) { reject; }
if (dst in 192.168.0.0/16) { reject; }
if (dst in 0.0.0.0/8) { reject; } <-- specifically added as a nasty example that cannot be handled by way of address list.
if (dst in ...) { reject; }
... incl some of which we'd like to be dynamic.
return;
if those prefix in /24 (even though they would form a /23 eventually) - then just do basic /24 filter. done. network secured.
Very, very wrong. Oh I don't even know where to begin with how wrong this statement is. Your total number of prefixes that can be generated for your network can be calculated, so let's assume a total of public space of exactly a /19. This means:
1 x /19
2 x /20
4 x /21
8 x /22
16 x /23
32 x /24
Or 2^(24-19+1)-1 = 2^6-1 = 63.
Drop a few because most likely the space is fragmented, so let's say a /20 and two /21s, that's 2(2^(24-21+1)-1) + 2^(24-20+1)-1 = 61 ... that's not even such a significant space, and already a fair number of possible prefixes. Can be filtered using 4 static route filter rules, or two if using address_lists, but we don't want 61 prefixes in the address list, only 3. With address_lists being much more dynamic in that it's easier to modify them programmatically compared to route filters. I'm guessing 2^(24-tsize+1)-number_of_base_prefixes but I've not spent time now to mathematically prove this one.
Not really the issue though since every base prefix can be dealt with in a single rule, but the moment we use address lists, we have to insert all of those routes. For filtering 0.0.0.0/8 (assuming more specific than /24 has already been axed) that's a whopping 2^(24-8+1)-1 = 131071 prefixes to be inserted into the address list. So the if (dst in 10.0.0.0/8) { reject } mechanism is much simpler, except it's definitely not dynamic (neither are address lists but their easier to manipulate programmatically).
then when you get home - you can continue figuring your math logic.
The math has already been done, over and over again. Been working on it for many years. More than I care to count. You're missing this point. The idea behind this topic was to simplify the complexity of the algorithmic nature (rules) of calculating (deploying) the math.
good luck
I don't believe in or function on luck. I believe in and function on cold hard calculation and precision. And improving precision, and preventing manual mistakes makes perfect sense for me. Our almost ideal solution:
1. Originate bogon routes from route reflector with a specific community, eg 857:65500 (RFC1918, LSN, 0.0.0.0/8, multicast etc ..., but not RIR assigned prefixes)
2. Originate ASN prefixes that's been RIR assigned from route reflectors with 857:65500 (so that they're bogon's too) as well a community indicating how/where they should be advertised.
3. On edge routers install routes received from RRs with community 857:65500 as unreachable routes.
4. Copy all prefixes with community 857:65500 into address_list.
5. Use address_list to filter prefixes received on eBGP.
6. Use same address_list in firewall to filter ingress traffic - this one unfortunately forces traffic through CPU, so it's probably best to rather use switch chip ACLs to filter the static rules, and just periodically sync these ACL rules with the static bogon lists (ie, traffic from any prefix with 857:65500 on a RED interface should get dropped). No branching or anything, so if the RED interface is a 4x10G LACP bridge port this gets nasty, so this point we still need to consider, however, it's perfectly possible to redirect things like DNS, NTP and SMTP from the switch chip to CPU and filter (for example) just those - since these are the protocols we found is most abused. As it stands in order to maintain routing performance this one will at least partially remain a pipe dream.
There are other use-cases for these things which I won't go into now, but needless to say, the possibilities are insane, if you can send address lists from RRs to edge routers, there is just more options available for doing dynamic filtering. One such use-case is to peer with CYMRU and get the total unallocated space from RIRs (both v4 and v6) from them, now push that to edge routers as per above with 857:65500 - since these are filtered, and unreachable routes gets installed, you're effectively closing down on a very common phenomenon whereby unallocated space gets jacked by less-than-savoury characters and protecting your clients from those. We inherited space that was abused in this way - so this is a sensitive topic. RPKI is supposed to help here, but that only works if RIRs are allowed to publish a "reject" signature for these ranges. Meantime in the real world we need alternative solutions to protect our networks and our customers - something for which this whole discussion is but a small part.
But I digress ... please let's just stick to the topic at hand, for now:
Can we have the in operator match as in, and not as ==? For now we're getting the prefixes into the address list by means other than BGP, but we would like to use address_lists to help with filtering BGP advertisements, for now, since fixing up the filters by way of routeros scripting is actually quite hard. Getting to put stuff into those address lists using BGP would be a future endeavour once that functionality is available from ROS as per "Routing filter add a prefix to address list" from
https://help.mikrotik.com/docs/display/ ... l+Overview