I’ve reviewed the routing filter rules for v7.4 via the docs: https://help.mikrotik.com/docs/display/ROS/Route+Selection+and+Filters
I haven’t found a way to reject routes from a specific router ID or originator when using OSPF.
Can someone share an example please?
If it is not possible, is there a way to ignore opaque-areas?
thank you
Here are the errors on the bird side… How do I prevent these entries in the lsa table and set a filter out rule? It doesn’t seem like there is a field I can filter on…
Jul 30 18:24:26 vpn1 bird: ospf1: Bad LSA (Type: 0000, Id: 1.0.0.18, Rt: 10.70.140.1) in LSUPD
Jul 30 18:24:26 vpn1 bird: ospf1: received from nbr 10.70.251.22 on wg8531 - unknown type
Jul 30 18:24:31 vpn1 bird: ospf1: Bad LSA (Type: 0000, Id: 1.0.0.18, Rt: 10.70.140.1) in LSUPD
Jul 30 18:24:31 vpn1 bird: ospf1: received from nbr 10.70.251.22 on wg8531 - unknown type
Jul 30 18:24:36 vpn1 bird: ospf1: Bad LSA (Type: 0000, Id: 1.0.0.18, Rt: 10.70.140.1) in LSUPD
Jul 30 18:24:36 vpn1 bird: ospf1: received from nbr 10.70.251.22 on wg8531 - unknown type
Jul 30 18:24:42 vpn1 bird: ospf1: Bad LSA (Type: 0000, Id: 1.0.0.18, Rt: 10.70.140.1) in LSUPD
Jul 30 18:24:42 vpn1 bird: ospf1: received from nbr 10.70.251.22 on wg8531 - unknown type
Jul 30 18:24:47 vpn1 bird: ospf1: Bad LSA (Type: 0000, Id: 1.0.0.18, Rt: 10.70.140.1) in LSUPD
Jul 30 18:24:47 vpn1 bird: ospf1: received from nbr 10.70.251.22 on wg8531 - unknown type
Jul 30 18:24:52 vpn1 bird: ospf1: Bad LSA (Type: 0000, Id: 1.0.0.18, Rt: 10.70.140.1) in LSUPD
Jul 30 18:24:52 vpn1 bird: ospf1: received from nbr 10.70.251.22 on wg8531 - unknown type
Jul 30 18:24:57 vpn1 bird: ospf1: Bad LSA (Type: 0000, Id: 1.0.0.18, Rt: 10.70.140.1) in LSUPD
Jul 30 18:24:57 vpn1 bird: ospf1: received from nbr 10.70.251.22 on wg8531 - unknown type
and here are the routes from the LSA table on the SXT - I am looking to filter out these two entries.
[admin@nycmesh-177-sxtsq] > /routing/ospf/lsa/print where type=opaque-area
Flags: S - self-originated, F - flushing, W - wraparound; D - dynamic
3 D instance=default area=backbone type="opaque-area" originator=10.70.140.1 id=1.0.0.1 sequence=0x80003D02 age=1669 checksum=0x7BB9 body=address: 10.70.140.1
4 D instance=default area=backbone type="opaque-area" originator=10.70.140.1 id=1.0.0.18 sequence=0x800023B2 age=1269 checksum=0xC9AA body=corrupted body
You can filter only external LSAs. What device is generating those opaque LSAs with corrupt body?
its a ubiquiti edgemax device. these lsadb entries dont turn into routes on the mikrotik devices (as expected), however, bird still gets these LSADB entries which I want to remove.
Been using BIRD a lot lately and glanced at this. AFAIK BIRD 2.X doesn’t yet implement opaque LSAs (see suggestions for future work) [1].
If I follow correctly, rather than filtering them transiting through the Mikrotik, could you filter them inbound in BIRD? That would at least prevent BIRD from error logging the LSAs it doesn’t understand. I’m a little worried about the plausibility of my suggestion because I can’t seem to find LSA type documented as a field you can filter on in the BIRD filter grammar … but maybe I missed something 
It is better to disable feature that is generating opaque LSAs. Especially if Ubiquity is generating corrupt body. Run a packet sniffer to see if the arriving messages are actually corrupted.
thank you. I will try to do that
Firstly, I am using Bird 1.6.3,. not 2.x. Secondly, I have tried to do that but failed to get the filter correct. Do you have any suggestions? These two opaque routes only exist in the LSADB - they dont show up in routes in BIRD or the mikrotik devices. From a post above, you can see the LSA type is coming in as 0000 (Bird doesnt recognize it)
I assume if it’s not implemented in 2.x it’s not in 1.x either, but I didn’t specifically check.
I looked through the BIRD source a little bit and I can’t find a reference to being able to filter by LSA type. It doesn’t appear to be documented. Maybe you can’t.
The LSA type being 0000 is weird because you’d expect it to be 9/10/11 if it’s formed correctly. It’s also possible that BIRD has an enum of the supported types that only goes up to 8 and it prints the log as 0 because it thinks the LSA is malformed. Hard to say. mrz has the right idea there to packet capture and future out whether the LSAs are actually malformed or whether it’s just an artifact of BIRD not understanding them.
In the end, is the problem that BIRD is polluting its logs with malformed LSA notifications? It’s probably not impacting the actual functionality, right? Also to mrz’s point if you aren’t actually using them, turning them off at the source is better. I was under the impression you were intentionally using them but that you just wanted to restrict their propagation to devices that didn’t understand them.
yes it is a weird issue. I fixed this by logging into the Ubiquiti Edge Router device, upgrading it and making sure opaque lsa routes are off.