OSPF flaps and logging

RouterOS Forwarding Protocols
1

I have a few MT routers, a mix of 3.28 and 4.1 talking OSPF to each other, with a Cisco on the edge. The routes for some of the MTs are stable, while others seem to flap. It appears that the neighbor does not drop, but the routes are withdrawn from the routing table. Is there a way to turn on some logging on this? I’d use something like debug ip ospf events on the Cisco side, but I don’t know what the equivalent is in the MT world.

2

You could try /system logging add topics=ospf,!raw
That should give you a pretty good overview on what’s going on.

3

That is exactly what I needed, thanks. I had found topics=ospf, but the ,!raw was needed to make it intelligible.

4

I have attached a log of the OSPF events, it seems that I get an error regarding “MinArrival test” then the LSA is deleted. Any thoughts?

Jan/02/1970 13:03:16 route,ospf,debug Retransmitted some LSA updates
Jan/02/1970 13:03:16 route,ospf,debug count=1
Jan/02/1970 13:03:16 route,ospf,debug to=10.253.0.17
Jan/02/1970 13:03:16 route,ospf,debug SEND: Link State Update 184352786 → 10.253.0.17 on wlan1
Jan/02/1970 13:03:16 route,ospf,debug RECV: Link State Update ← 10.253.0.17 on wlan1 (10.253.0.18)
Jan/02/1970 13:03:16 route,ospf,debug LSA Update received: Installing and flooding it
Jan/02/1970 13:03:16 route,ospf,debug header=Network LSA id=10.253.0.14 originator=10.254.12.9 seqnum=0x80000b47
Jan/02/1970 13:03:16 route,ospf,debug Installing an LSA
Jan/02/1970 13:03:16 route,ospf,debug lsa=Network LSA id=10.253.0.14 originator=10.254.12.9 seqnum=0x80000b47
Jan/02/1970 13:03:16 route,ospf,debug old=Network LSA id=10.253.0.14 originator=10.254.12.9 seqnum=0x80000b46
Jan/02/1970 13:03:16 route,ospf,debug Flooding an LSA
Jan/02/1970 13:03:16 route,ospf,debug lsa=Network LSA id=10.253.0.14 originator=10.254.12.9 seqnum=0x80000b47
Jan/02/1970 13:03:16 route,ospf,debug area=area1
Jan/02/1970 13:03:16 route,ospf,debug Adding to neighbor’s retransmit list
Jan/02/1970 13:03:16 route,ospf,debug lsa=Network LSA id=10.253.0.14 originator=10.254.12.9 seqnum=0x80000b47
Jan/02/1970 13:03:16 route,ospf,debug neighbor=10.254.12.6
Jan/02/1970 13:03:16 route,ospf,debug number of retransmits=1
Jan/02/1970 13:03:16 route,ospf,debug SEND: Link State Update 184352789 → 224.0.0.5 on ether1
Jan/02/1970 13:03:16 route,ospf,debug RECV: Link State Update ← 10.253.0.17 on wlan1 (10.253.0.18)
Jan/02/1970 13:03:16 route,ospf,debug RECV: Link State Update ← 10.253.0.22 on ether1 (10.253.0.21)
Jan/02/1970 13:03:16 route,ospf,debug Ignoring LSA Update: failed MinArrival test
Jan/02/1970 13:03:16 route,ospf,debug Deleting an LSA
Jan/02/1970 13:03:16 route,ospf,debug lsa=Network LSA id=10.253.0.14 originator=10.254.12.9 seqnum=0x80000b46
log.0.txt (34.1 KB)

5

Appears to be resolved. I had a default being injected from two directions. Disabled the interface in the direction of the offending route, and now things are stable. I’ll need to filter or set costs to bring the link back up.

6

Hi guys,

How do I disable this logging?


Thanks

7

Find ospf logging entry:

/system logging print

Locate number entry from above command and remove

/system logging remove #

Example:
[user@ROUTER] > /system logging print
Flags: X - disabled, I - invalid, * - default

TOPICS ACTION PREFIX

0 * info memory
1 * error memory
2 * warning memory
3 * critical echo
4 ospf memory
!raw
[user@ROUTER] > system logging remove 4