BGP RTBH Blackhole Flag Not Removed When Community is Withdrawn

Hello everyone,

I am facing an issue with Remote Triggered Black Hole (RTBH) filtering in MikroTik RouterOS 7.
Setup:

My CE router advertises prefixes with the 65535:666 community to trigger blackholing on the PE router.
MikroTik recommends using the following BGP input filter on the PE to implement RTBH:

    if (bgp-communities includes 65535:666) {  
        set blackhole yes;  
        accept;  
    }

This works as expected: when the CE sends a prefix with 65535:666, the PE correctly blackholes it.

Issue:

When the CE removes the 65535:666 community from a prefix, the PE does not remove the blackhole flag.
The prefix remains blackholed on the PE even though it no longer has the RTBH community.

Temporary Workaround:

To mitigate this, I added the following rule to explicitly unset the blackhole flag when 65535:666 is not present:

else {  
    set blackhole no;  
    accept;  
}

However, I am concerned that using else may unintentionally match other prefixes that should not be modified.
Question:

Is there a better way to ensure that the blackhole flag is removed only when the prefix was previously blackholed but no longer carries 65535:666?

Any suggestions or best practices would be appreciated.

Thanks!

Hello everyone,

I initially thought I had a configuration issue with RTBH, but after testing, I realized the routing works fine—this seems to be a Winbox display bug.
Issue Description:

My CE advertises a prefix with the 65535:666 community, which correctly triggers blackholing on my PE.
When I remove the 65535:666 community from the prefix, the route becomes reachable again and works fine.
However, in Winbox (versions 3.41 and 4b19), the route still appears with the blackhole flag, even though the blackhole state has been cleared.
After closing Winbox and logging back in, the blackhole flag disappears, and the route is displayed correctly.

Screenshots:

Here is a screenshot showing the blackhole flag still present after removing the community.

Has anyone else noticed this issue? It seems like a Winbox UI refresh problem rather than an actual routing issue.

Let me know if there’s a way to manually refresh the route display in Winbox without needing to relogin.

Thanks!