See this page for documentation: https://wiki.mikrotik.com/wiki/Manual:Routing/Routing_filters
The bgp-communities line says: match the COMMUNITIES BGP attribute. Match is done when communities attribute in a route contains all entries from this configured list.
So you cannot put both of them in the same filter entry as it will be an AND operation.
If you change the order of the rules matching on bgp-communities, does it change anything (i.e. filtering routes from FB and not filtering those from Google)? If not, can you check (using sniffing and Wireshark) that the COMMUNITIES attribute indeed arrives for the FB routes?
What is the CPU architecture and RouterOS release you use? On my lab CHRs running 6.48.6, I am adding bgp-community 0:12345 using an out-filter on one peer. On the other peer, the first in-filter rule discards on bgp-community=0:54321, the second rule discards on bgp-community=0:12345, and the second rule works (which is expected). If I swap their order, the one matching on 0:12345 works as well, so their mutual order doesn’t matter in my case. The only difference as compared to your scenario are the particular numbers after the colon and, likely, that I test that on igp peers.
What works weird in my case is that if I disable the second rule, the routes it filters out do not reappear in the routing table until I disable and re-enable the peer at the other router.
Routing filters do not work on already installed routes, they work on BGP input, which means that you have to request route refresh after you change the in filter rules. See “refresh”, “resend” commands.
Yeah, and then you face the problem that these commands do not work correctly in RouterOS v7. So it is often required to disconnect/reconnect the peer.
There is at least a problem when using these commands between v6 and v7, I do not know if the fault is on v6 or v7 side.
When v6 side uses refresh, the v7 side logs this:
route,bgp,warning RECV RouteRefresh with invalid subtype: 0
and does nothing.
v6 side needs to disconnect/reconnect to force v7 side to do a refresh.
For the record, in my case, it’s not an ROS v6 vs. ROS v7 interworking issue. I simply did not assume that the refresh would be needed at all, given that for action=reject, no refresh is needed to make the route list change after enabling or disabling of the routing filter rules, and even more important, that enabling the action=discard rule has an immediate effect, which does not seem compatible with the idea of only handling the route as it is being received from the peer. So my assumption was that the routes received from each peer were stored permanently, and the filter was just controlling which ones of them make it further to redistribution and kernel routing table, so an update of the filter re-processes the stored list without asking the peer to send the route list again.
igp or egp? How exactly they “don’t work”, same like with @anishpla, i.e. only the first one works and the second one doesn’t? Can you show your routing filter chains at both the source (which assigns the community marks) and a the recipient (which filters by them)?