Community discussions

MikroTik App
 
wintech2003
just joined
Topic Author
Posts: 10
Joined: Fri Jun 09, 2006 6:56 pm

BGP filters from v6 -> v7 high CPU

Mon Jun 05, 2023 8:08 pm

Hello,

I recently switched from a CCR1036 running RouterOS 6, to a CCR2004 running ROS v7.8
On RouterOS 6 I used the following filters to reject bogons from eBGP peers in an IXP:
add action=discard chain=own-prefix_discard_IPv4 prefix=[my_prefix]/24 prefix-length=24-32
add action=discard chain=rfc5735_discard_IPv4 prefix=0.0.0.0/8 prefix-length=8-32
add action=discard chain=rfc5735_discard_IPv4 prefix=10.0.0.0/8 prefix-length=8-32
add action=discard chain=rfc5735_discard_IPv4 prefix=100.64.0.0/10 prefix-length=10-32
add action=discard chain=rfc5735_discard_IPv4 prefix=127.0.0.0/8 prefix-length=8-32
add action=discard chain=rfc5735_discard_IPv4 prefix=169.254.0.0/16 prefix-length=16-32
add action=discard chain=rfc5735_discard_IPv4 prefix=172.16.0.0/12 prefix-length=12-32
add action=discard chain=rfc5735_discard_IPv4 prefix=192.0.0.0/24 prefix-length=24-32
add action=discard chain=rfc5735_discard_IPv4 prefix=192.0.2.0/24 prefix-length=24-32
add action=discard chain=rfc5735_discard_IPv4 prefix=192.88.99.0/24 prefix-length=24-32
add action=discard chain=rfc5735_discard_IPv4 prefix=192.168.0.0/16 prefix-length=16-32
add action=discard chain=rfc5735_discard_IPv4 prefix=198.18.0.0/15 prefix-length=15-32
add action=discard chain=rfc5735_discard_IPv4 prefix=198.51.0.0/24 prefix-length=24-32
add action=discard chain=rfc5735_discard_IPv4 prefix=203.0.113.0/24 prefix-length=24-32
add action=discard chain=rfc5735_discard_IPv4 prefix=224.0.0.0/4 prefix-length=4-32
add action=discard chain=rfc5735_discard_IPv4 prefix=240.0.0.0/4 prefix-length=4-32
add action=discard chain=PEER_IPv4_IN prefix=0.0.0.0/0
add action=jump chain=PEER_IPv4_IN jump-target=own-prefix_discard_IPv4
add action=jump chain=PEER_IPv4_IN jump-target=rfc5735_discard_IPv4
add action=accept chain=PEER_IPv4_IN set-bgp-local-pref=150
In ROS7 I used a similar approach, first reject the default router, then my own prefix and bogons and finally accept everything else. The bogons filter looks like this:
if (dst in 0.0.0.0/8 && dst-len in 8-32) {
    reject;
}
if (dst in 10.0.0.0/8 && dst-len in 8-32) {
    reject;
}
if (dst in 100.64.0.0/10 && dst-len in 10-32) {
    reject;
}
if (dst in 127.0.0.0/8 && dst-len in 8-32) {
    reject;
}
if (dst in 169.254.0.0/16 && dst-len in 16-32) {
    reject;
}
if (dst in 172.16.0.0/12 && dst-len in 12-32) {
    reject;
}
if (dst in 192.0.0.0/24 && dst-len in 24-32) {
    reject;
}
if (dst in 192.0.2.0/24 && dst-len in 24-32) {
    reject;
}
if (dst in 192.88.99.0/24 && dst-len in 24-32) {
    reject;
}
if (dst in 192.168.0.0/16 && dst-len in 16-32) {
    reject;
}
if (dst in 198.18.0.0/15 && dst-len in 15-32) {
    reject;
}
if (dst in 198.51.0.0/24 && dst-len in 24-32) {
    reject;
}
if (dst in 203.0.113.0/24 && dst-len in 24-32) {
    reject;
}
if (dst in 224.0.0.0/4 && dst-len in 4-32) {
    reject;
}
if (dst in 240.0.0.0/4 && dst-len in 4-32) {
    reject;
}
Unfortunately, applying the above into the filter chain, increases CPU very much. From ~20% without this filter to 60-80%.
The above is with one transit (default route only) and one IXP; traffic levels are 200-300Mbps.

I've gotten various tips on how to optimize this:
- drop bogons with raw firewall
- put all prefixes in address lists and change it to a single "if (dst in [address_list]) { reject; }" but the documentation says that this will only match the exact prefix
- blackhole bogon prefixes using the Cymru full bogons feed

So I have two questions:
1) Why is this happening? I practically copied the same logic that was working perfectly fine in ros6 to ros7, and get a huge increase in CPU load. Is this expected or could it be a bug?
2) What is the recommended way to go for an edge router? As a principle I try to avoid using firewall on the edges, but I'm open to suggestions.

Thanks,
George
 
wiseroute
Member
Member
Posts: 352
Joined: Sun Feb 05, 2023 11:06 am

Re: BGP filters from v6 -> v7 high CPU

Tue Jun 06, 2023 8:29 am

hello George,

maybe @ mrz can help you with this
Unfortunately, applying the above into the filter chain, increases CPU very much. From ~20% without this filter to 60-80%.
but for this one,
The above is with one transit (default route only) and one IXP; traffic levels are 200-300Mbps.
it is obvious that the high cpu usage maybe came from your suboptimal ix peering (to crowded)?

as for v6 to v7 different cpu utilization - maybe @ mrz could give you an insight.

if you really need to migrate to v7 - maybe you could lab it first, and try to find the performance bottleneck point - before going live.

just a thought 🤔

Who is online

Users browsing this forum: galp and 16 guests