Hi

I have system with two Mikrotik CCR routers and three ISPs with full BGP - R1 connected to first router, two to R2. Routers have session IBGP between them.
The issue is - when i enable BGP session to second ISP on R2 first BGP session drops connection with message 'cease: prefix limit reached' in logfile.
I have filter set up to only allow my /22 class.
Am i doing something wrong? I don't have much experience with BGP.

It sounds like ISP2 might be sending you full Internet routes, and you have a prefix limit set too low.
Prefix Limit is a limit on how many prefixes you can receive (not send) - so if you set this to 1 thinking that it would limit how many you may send, then this is the problem.

sounds like ISP1 has prefix-limit, and CCR starts to announce all ISP2 routes to ISP1

looks like you need to setup filters to allow only your networks to be announced

"sounds like ISP1 has prefix-limit, and CCR starts to announce all ISP2 routes to ISP1"

It seems that's exactly what is happening. I have filters set up but it doesn't seem they work properly. Maybe i'm doing something incorrectly?
Full list of filters below. There is one BGP instance with 4 peers - ISP1(atm-in,atm-out), ISP2(atm-in, netia-out), community blacklist(wanguard-in, wanguard-out) and our second router connected to ISP3(local-in, local-out).

0 chain=all-out distance=!0-1 invert-match=no action=discard set-bgp-prepend-path=""
1 chain=atm-in prefix=127.0.0.0/8 protocol=bgp invert-match=no action=discard set-bgp-prepend-path=""
2 chain=atm-in prefix=10.0.0.0/8 protocol=bgp invert-match=no action=discard set-bgp-prepend-path=""
3 chain=atm-in prefix=169.254.0.0/16 protocol=bgp invert-match=no action=discard set-bgp-prepend-path=""
4 chain=atm-in prefix=172.16.0.0/12 protocol=bgp invert-match=no action=discard set-bgp-prepend-path=""
5 chain=atm-in prefix=192.168.0.0/16 protocol=bgp invert-match=no action=discard set-bgp-prepend-path=""
6 chain=atm-in prefix=224.0.0.0/4 protocol=bgp invert-match=no action=discard set-bgp-prepend-path=""
7 chain=atm-in prefix=MYPREFIX/22 protocol=bgp invert-match=no action=discard set-bgp-prepend-path=""
8 chain=atm-in prefix-length=25-32 protocol=bgp invert-match=no action=discard set-bgp-prepend-path=""
9 chain=atm-in invert-match=no action=accept set-bgp-prepend-path=""
10 chain=atm-out protocol=bgp bgp-communities=100:666 invert-match=no action=accept set-bgp-prepend-path="" set-bgp-communities=24723:666
11 chain=atm-out prefix=MYPREFIX/22 prefix-length=22 invert-match=no action=accept set-bgp-prepend=15 set-bgp-prepend-path=""
12 chain=atm-out prefix=MYIPV6PREFIX/29 prefix-length=29 invert-match=no action=accept set-bgp-prepend=15 set-bgp-prepend-path=""
13 chain=atm-out protocol="" invert-match=no action=discard set-bgp-prepend-path=""
14 X chain=netia-out protocol=bgp bgp-communities=100:666 invert-match=no action=accept set-bgp-prepend-path="" set-bgp-communities=24723:666
15 chain=netia-out prefix=MYPREFIX/22 prefix-length=22 invert-match=no action=accept set-bgp-prepend=10 set-bgp-prepend-path="" set-bgp-communities="" append-bgp-communities=""
16 chain=netia-out prefix=MYIPV6PREFIX/29 prefix-length=29 invert-match=no action=accept set-bgp-prepend=10 set-bgp-prepend-path="" set-bgp-communities="" append-bgp-communities=""
17 chain=netia-out protocol="" invert-match=no action=discard set-bgp-prepend-path="" set-bgp-communities="" append-bgp-communities=""
18 chain=local-in prefix=0.0.0.0/0 invert-match=no action=accept set-bgp-prepend-path=""
19 chain=local-out prefix=MYPREFIX/22 prefix-length=0-128 invert-match=no action=discard set-bgp-prepend-path=""
20 chain=local-out invert-match=no action=accept set-bgp-prepend-path=""
21 chain=wanguard-in bgp-communities=100:666 invert-match=no action=accept set-bgp-prepend-path=""
22 chain=wanguard-in invert-match=no action=discard set-bgp-prepend-path=""
23 chain=wanguard-out invert-match=no action=discard set-bgp-prepend-path=""
24 chain=wanguard-out bgp-as-path-length=!0-1 invert-match=no action=accept set-bgp-prepend-path=""

13 chain=atm-out protocol="" invert-match=no action=discard set-bgp-prepend-path=""

isn't that the reason? seems like protocol="" won't match anything, that's why this rule won't discard anything. you need to unset 'protocol' field ('up' triangle at the right side of that field in WinBox)

seems like protocol="" won't match anything, that's why this rule won't discard anything. you need to unset 'protocol' field ('up' triangle at the right side of that field in WinBox)

Good observation, Chupaka. (I've seen other people get caught by the same thing, but using community="" caused by not collapsing the triangle...

Another thing to check for:
Spot check some of the prefixes to see if they have community 0:0 set (internet) - apparently Mikrotik's community filter always matches lists containing 0:0
See this thread

One more thing - it doesn't have to do with your issue, but you may want to fix rules 1-6 by adding "prefix-length=0-32" to them. Otherwise, they only match the full prefixes themselves and not any sub-prefixes of them.

Thanks for all responses, i fixed my BGP rules according to them. Sadly this did not fix the problem.
Also, it's possible that ISP2 is sending routes with 0:0 community, would it be save to set a custom one, eg their AS number in input filter? Or are there any rules for that?
I have 'Redistribute Other BGP' enabled on that router so it's sending it's routes to the second one. Maybe that is causing the issues?
But shoudn't filters work anyway?

you may post your filters again. all is working for me

also, check that filters are set for BGP peers

I have 'Redistribute Other BGP' enabled on that router so it's sending it's routes to the second one. Maybe that is causing the issues?
But shoudn't filters work anyway?

You should use a single instance of BGP for both the EBGP session and for the IBGP session. BGP's best path algorithm compares multiple paths in the BGP table, and then puts the best one into the routing table. If you have multiple processes, then the paths can't be compared by best path - each process will simply stuff its best route for each prefix into the routing table, and then the administrative distance would be a tiebreaker if you happened to set one process at a different distance than the other - but then one entire BGP process is considered "better" than the other for ALL routes learned, and NOT based on the BGP algorithm itself.

Redistributing squashes a lot of path data on each prefix because your router is essentially throwing every route from ISP1 into the trash, and then making its own original route which mimics the original route - but your router is the new origin of these "bootleg" routes. I suspect that a redistributed route won't have the original BGP communities on it (but haven't tested this)

For IBGP, best practice is to have a loopback IP address on each router, and to use these loopback addresses when peering with an IBGP neighbor.
In the peer settings, you set the update source = the loopback interface / IP, and you configure the address of the IBGP peer to be the other router's loopback IP.
Make sure that the loopback IPs are in your IGP (OSPF) and that the IP ranges on your ISP links are also in OSPF, so that routers will be able to synchronize on them and make the best next-hop decision.

EDIT: I threw together a quick lab to test what redistribute other-bgp routes look like because I wasn't sure, and it turns out that I was incorrect and the communities are maintained. However, the point I made about routing decisions is still true.

welcome to the club, you are trying to filter with bgp communities and thats just not working

(as the internet is broken -> community 0:0 flying around)

-> 10 chain=atm-out protocol=bgp bgp-communities=100:666 invert-match=no action=accept set-bgp-prepend-path="" set-bgp-communities=24723:666
that line accepts some weired prefixes with community 0:0....

You can read my post where i described the problem:
http://forum.mikrotik.com/viewtopic.php?f=1&t=112327

@Mikrotik: FIX THAT or give me the Sourcecode and i fix it myself.

Best Regards,
Tobias