MikroTik

I don't know why i seeing ip address of router itself in log...

22:41:48 route,ospf,error src address=fe80::20c:42ff:febf:91c1
22:41:58 route,ospf,error Discarding packet: locally originated
22:41:58 route,ospf,error src address=fe80::20c:42ff:febf:91c1
22:42:08 route,ospf,error Discarding packet: locally originated
22:42:08 route,ospf,error src address=fe80::20c:42ff:febf:91c1
22:42:18 route,ospf,error Discarding packet: locally originated
22:42:18 route,ospf,error src address=fe80::20c:42ff:febf:91c1
22:42:28 route,ospf,error Discarding packet: locally originated
22:42:28 route,ospf,error src address=fe80::20c:42ff:febf:91c1

This problem shows even if i set all passive and active only one interface.

[majkls@xxx] > /routing ospf-v3 export
# jan/16/2012 22:53:12 by RouterOS 5.11
#
/routing ospf-v3 instance
set default disabled=no distribute-default=never metric-bgp=auto metric-connected=20 metric-default=1 metric-other-ospf=auto metric-rip=20 metric-static=20 name=default \
redistribute-bgp=no redistribute-connected=as-type-1 redistribute-other-ospf=no redistribute-rip=no redistribute-static=no router-id=xxxx
/routing ospf-v3 area
set backbone area-id=0.0.0.0 disabled=no instance=default name=backbone type=default
/routing ospf-v3 interface
add area=backbone cost=5 dead-interval=40s disabled=no hello-interval=10s instance-id=0 interface=ether3 network-type=default passive=no priority=1 retransmit-interval=5s \
transmit-delay=1s use-bfd=no

This error message appears if you have queue set on the same interface where OSPFv3 is running. We will fix it in the future, but currently you can ignore it.

Yup get the same thing... is there an eta on when the new fix will be released?
weeks, monthes, or years?

Thnx

Yup get the same thing... is there an eta on when the new fix will be released?
weeks, monthes, or years?

Thnx

Normus,

This bug has literally been in RouterOS for YEARS!!! It clogs up our log files with useless junk and frankly makes RouterOS's programmers look bad.

Please intervene and get this fixed!

Thanks in advance!!!

hi!

I have this exact problem: but I don't have any queue on interface running OSPFv3???

Same issue here. Unfortunately it makes it difficult to find the source of other problems because it fills the log very quickly so there is no room for other entries.

- Mat

Same issue here, details follows:

- RouterOS 5.19 (on x86 box).
- NO Custom queues applied on OSPF Interfaces (only ethernet-default is active).
- OSPF Network-Type: 'Point-to-Point'
- Configured interfaces: TWO (two dedicated P2P links with two Cisco Neighbors, both in same 'backbone' Area)

The problem persists when configuring OSPFv3 (IPv6), even if all unneeded interfaces are configured as 'passive'.

13:49:22 route,ospf,error Discarding packet: locally originated
13:49:22 route,ospf,error src address=fe80::****:****:****:10e9

Discarded packets has always Link-Local IPv6 Address as source.


Some debug follows ('ospf !raw' memory logging enabled with 'OSPF' prefix), addresses has been masked:
13:53:13 route,ospf,debug OSPF: RECV: Hello <- ***.***.***.157 on ether4 (***.***.***.158)
13:53:13 route,ospf,debug OSPF: received options: E|R
13:53:13 route,ospf,debug OSPF: SEND: Hello ***.***.***.154 -> 224.0.0.5 on ether3
13:53:13 route,ospf,debug OSPF: SEND: Hello ***.***.***.158 -> 224.0.0.5 on ether4
13:53:18 route,ospf,debug OSPF: SEND: Hello -> ff02::5 on ether3
13:53:18 route,ospf,error OSPF: Discarding packet: locally originated
13:53:18 route,ospf,error OSPF: src address=fe80::****:****:****:10a3
13:53:18 route,ospf,debug OSPF: RECV: Hello <- fe80::****:****:****:1080 on ether4
13:53:18 route,ospf,debug OSPF: received options: V6|E|R
13:53:18 route,ospf,debug OSPF: RECV: Hello <- ***.***.***.153 on ether3 (***.***.***.154)
13:53:18 route,ospf,debug OSPF: received options: E|R
13:53:19 route,ospf,debug OSPF: RECV: Hello <- fe80::****:****:****:103b on ether3
13:53:19 route,ospf,debug OSPF: received options: V6|E|R
13:53:22 route,ospf,debug OSPF: SEND: Hello -> ff02::5 on ether4
13:53:22 route,ospf,error OSPF: Discarding packet: locally originated
13:53:22 route,ospf,error OSPF: src address=fe80::****:****:****:10e9


Anyone found a solution? Is this the same problem you guys have in your environment?

Best,
-A

As a 'Hack', I created two IPv6 Firewall rules, blocking all inbound traffic originated from 'local' Link-Local addresses as follows (Masked/Fake IPs):

/ipv6 firewall filter
add action=log chain=input disabled=no log-prefix=OSPF-IN-LinkLocal protocol=ospf src-address=fe80::****:****:****:7a10/128
add action=log chain=input disabled=no log-prefix=OSPF-IN-LinkLocal protocol=ospf src-address=fe80::****:****:****:6a10/128
add action=drop chain=input disabled=no protocol=ospf src-address=fe80::****:****:****:7a10/128
add action=drop chain=input disabled=no protocol=ospf src-address=fe80::****:****:****:6a10/128

Note: logging rules can be disabled and has to be used only for debugging purposes.

Let's wait for a definitive solution for this problem, for the moment I'm not annoyed anymore from flooding OSPF error messages and no unattended packets are processed from OSPFv3 process.


Best, hope this help.
-A

This problem is fixed in v6rc1.

The problem persists on version 6.0.

The problem persists on version 6.2.

The problem persists, I wonder if it is my setup, but with seeing so many other people experiencing it.. I wonder... ROS 6.7.

For us this was fixed on version 6.2 and higher

We have the same problem between routers Mikrotik 5.26 and Mikrotik 6.2

How many years and still not fixed? Get it together guys.

6.12

This is fixed long time ago. If you see this still with v6.12 then there is a problem in your network setup or configuration.

Thanks for the unhelpful input. Id wager that the problem is in how you assign link local addresses to tunnel interfaces that results in te same link local address on a remote side as on another tunnels local side. Otherwise, it shouldn't matter if the same link local address is found on 2 seperate interfaces because the %interface suffix makes it unique. Routeros ospf3 must not care about that.

Then next time be more specific and write to support with bug report. Original bug had nothing to do with tunnels.