<div dir="ltr">Sorry Guys,<div><br></div><div>issue solved. It is a feature. Not a bug :-)</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="monospace, monospace"><b>root@de-ain-hof:/home/rack#</b> cat /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr<br></font><font face="monospace, monospace">1</font> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="monospace, monospace"><br></font><font face="monospace, monospace"><b>root@de-ain-hof:/home/rack#</b> sysctl net.ipv4.icmp_errors_use_inbound_ifaddr=0<br></font><font face="monospace, monospace">net.ipv4.icmp_errors_use_inbound_ifaddr = 0</font></blockquote></div><div><br></div><div>after changing <span style="font-family:monospace,monospace">net.ipv4.icmp_errors_use_inbound_ifaddr </span>to<span style="font-family:monospace,monospace"> 0 things starts working as expected.</span></div><div><span style="font-family:monospace,monospace"><br></span></div><div><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"><b>QUOTE:</b> <a href="https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt">https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt</a>
icmp_errors_use_inbound_ifaddr - BOOLEAN
If zero, icmp error messages are sent with the primary address of
the exiting interface.
If non-zero, the message will be sent with the primary address of
the interface that received the packet that caused the icmp error.
This is the behaviour network many administrators will expect from
a router. And it can make debugging complicated network layouts
much easier.
Note that if no primary address exists for the interface selected,
then the primary address of the first non-loopback interface that
has one will be used regardless of this setting.
Default: 0</pre></div><div><br></div><div>Dont know why it was set to 1.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <font face="monospace, monospace"> My traceroute [v0.91.1-4c982]<br></font><font face="monospace, monospace"><b>de-nbg-voip-pri</b> (80.255.15.137) 2018-08-25T17:28:48+0200<br></font><font face="monospace, monospace">Keys: Help Display mode Restart statistics Order of fields quit<br></font><font face="monospace, monospace"> Packets Pings<br></font><font face="monospace, monospace"> Host Loss% Snt Last Avg Best Wrst StDev<br></font><font face="monospace, monospace"> 1. 80.255.15.129 0.0% 7 3.6 4.0 1.7 7.6 2.0<br></font><font face="monospace, monospace"> 2. 81.95.15.65 0.0% 7 0.8 0.8 0.6 1.0 0.1<br></font><font face="monospace, monospace"> 3. 81.95.2.38 0.0% 7 5.2 7.2 5.2 18.6 5.0<br></font><font face="monospace, monospace"> 4. 5.56.17.162 0.0% 7 5.2 5.3 5.1 5.9 0.3<br></font><font face="monospace, monospace"> 5. 91.205.12.1 0.0% 7 5.3 5.1 5.0 5.3 0.1<br></font><font face="monospace, monospace"> <b><font color="#45818e">6. 91.205.13.1 0.0% 6 7.5 7.0 5.7 7.6 0.7</font></b><br></font><font face="monospace, monospace"> 7. 91.205.13.17 0.0% 6 11.1 13.5 9.5 23.1 5.0</font></blockquote></div><div><br></div><div>Thank you for your help.</div><div>You pointed me to the right direction.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Am Sa., 25. Aug. 2018 um 17:14 Uhr schrieb Michael Rack <<a href="mailto:mail@michaelrack.de">mail@michaelrack.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes it uses 91.205.13.1<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="monospace, monospace"><b>root@de-ain-hof:/home/rack#</b> curl <a href="http://checkip.dyndns.org" target="_blank">http://checkip.dyndns.org</a><br></font><font face="monospace, monospace"><html><head><title>Current IP Check</title></head><body>Current IP Address: 91.205.13.1</body></html></font></blockquote><div><br></div><div>So perhaps that is a kernel issue and not related to OLSR.</div><div>That is wierd. </div></div><br><div class="gmail_quote"><div dir="ltr">Am Sa., 25. Aug. 2018 um 15:02 Uhr schrieb Teco Boot <<a href="mailto:teco@inf-net.nl" target="_blank">teco@inf-net.nl</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So on default table, there is src and onlink.<br>
<br>
Is outgoing traffic on eth1.2220 using 91.205.13.1?<br>
If this is the case, it looks like a kernel issue. Question is: should the ICMP-Exceeded packet take the interface IP address or the configured SRC IP address?<br>
<br>
Teco<br>
<br>
> Op 25 aug. 2018, om 13:47 heeft Michael Rack <<a href="mailto:mail@michaelrack.de" target="_blank">mail@michaelrack.de</a>> het volgende geschreven:<br>
> <br>
> root@de-ain-hof:/home/rack# ip r s t default<br>
> default via 91.205.12.1 dev eth1.2220 src 91.205.13.1 metric 2 onlink<br>
> default via 172.16.11.1 dev eth1.2220 proto bird src 91.205.13.1 metric 32<br>
> <br>
> root@de-ain-hof:/home/rack# ip a s dev lo<br>
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN<br>
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br>
> inet <a href="http://127.0.0.1/8" rel="noreferrer" target="_blank">127.0.0.1/8</a> scope host lo<br>
> valid_lft forever preferred_lft forever<br>
> inet <a href="http://91.205.13.1/32" rel="noreferrer" target="_blank">91.205.13.1/32</a> scope global lo:olsr<br>
> valid_lft forever preferred_lft forever<br>
> inet6 ::1/128 scope host<br>
> valid_lft forever preferred_lft forever<br>
> <br>
> But on traceroute:<br>
> traceroute to 91.205.13.18 (91.205.13.18), 30 hops max, 60 byte packets<br>
> 1 <a href="http://ae0-404.nbg20.core-backbone.com" rel="noreferrer" target="_blank">ae0-404.nbg20.core-backbone.com</a> (83.142.85.225) 0.330 ms 0.493 ms 0.472 ms<br>
> 2 <a href="http://ae4-2057.slz10.core-backbone.com" rel="noreferrer" target="_blank">ae4-2057.slz10.core-backbone.com</a> (81.95.2.38) 4.723 ms 4.752 ms 4.731 ms<br>
> 3 <a href="http://at-sbg-itz-tz-k10-r10-bgp02-et6-v101.rsm-connect.net" rel="noreferrer" target="_blank">at-sbg-itz-tz-k10-r10-bgp02-et6-v101.rsm-connect.net</a> (5.56.17.162) 4.640 ms 4.653 ms 4.633 ms<br>
> 4 <a href="http://sbg-rou1-1.rsm-connect.net" rel="noreferrer" target="_blank">sbg-rou1-1.rsm-connect.net</a> (91.205.12.1) 4.610 ms 4.575 ms 4.597 ms<br>
> 5 172.16.11.8 (172.16.11.8) 5.756 ms 5.748 ms 5.724 ms<br>
> 6 <a href="http://dynamic-ip5bcd0d12.ain-hof.rsm-connect.net" rel="noreferrer" target="_blank">dynamic-ip5bcd0d12.ain-hof.rsm-connect.net</a> (91.205.13.18) 17.897 ms 19.321 ms 24.536 ms<br>
> <br>
> there is the interface-ip-address from eth1.2220 on ICMP-Exceeded in transit.<br>
> <br>
> For locally generated ip-packets kernel lookup on the src attribute.<br>
> But when in my case "onlink" attribute is inserted, this will not work as expected.<br>
> <br>
> Currently i am switching from OLSR to eBGP with BFD for link-sensing.<br>
> On my new boxes this works as expected only running BIRD. This box runs BIRD and OLSRD simultan. OLSR with metric of 2 and BRID with metric of 32, so routes from OLSRD kicks in before BIRD.<br>
> <br>
> <br>
> Am Sa., 25. Aug. 2018 um 12:53 Uhr schrieb Teco Boot <<a href="mailto:teco@inf-net.nl" target="_blank">teco@inf-net.nl</a>>:<br>
> <br>
> > Op 25 aug. 2018, om 12:19 heeft Michael Rack <<a href="mailto:mail@michaelrack.de" target="_blank">mail@michaelrack.de</a>> het volgende geschreven:<br>
> > <br>
> > Yes i am using rt-table 100.<br>
> > <br>
> > Because of the onlink attribute on the route the src-attribute will not be injected / will not kick in.<br>
> <br>
> I wrote it works for me.<br>
> <br>
> <br>
> > I did some testing with manually added routes.<br>
> > When i add onlink to my route the src-attribute does not kick in.<br>
> <br>
> It does.<br>
> <br>
> root@host:~# ip route add 192.168.6.6 via 192.168.7.7 dev lo src 172.31.11.11<br>
> RTNETLINK answers: Network is unreachable<br>
> root@host:~# ip route add 192.168.6.6 via 192.168.7.7 dev lo src 172.31.11.11 onlink<br>
> root@host:~# ip route show 192.168.6.6<br>
> 192.168.6.6 via 192.168.7.7 dev lo src 172.31.157.11 onlink <br>
> root@host:~#<br>
> <br>
> 172.31.11.11 is MainIP and is configured on another interface.<br>
> <br>
> <br>
> > When i remove the onlink attribute it will work as expected.<br>
> > <br>
> > So is there an option in olsrd.conf to remove the onlink attribute?<br>
> > <br>
> > When will onlink be inserted?<br>
> > Why is it necesery at all?<br>
> <br>
> For next hop IP address that does not meet kernel checks. E.g. neighbor is on other subnet.<br>
> <br>
> Is your main address configured?<br>
> <br>
> Teco<br>
> <br>
> <br>
> > <br>
> > Am Sa., 25. Aug. 2018 um 11:59 Uhr schrieb Teco Boot <<a href="mailto:teco@inf-net.nl" target="_blank">teco@inf-net.nl</a>>:<br>
> > What is the issue: add src or remove onlink?<br>
> > <br>
> > SrcIpRoutes works for me.<br>
> > <br>
> > Your olsrd.conf may have something special. Table 100?<br>
> > <br>
> > Teco<br>
> > <br>
> > > Op 24 aug. 2018, om 19:15 heeft Michael Rack <<a href="mailto:michael.rack@rsm-freilassing.de" target="_blank">michael.rack@rsm-freilassing.de</a>> het volgende geschreven:<br>
> > > <br>
> > > Is there now solution to remove onlink attribute on routes?<br>
> > > <br>
> > > Liebe Grüße aus Freilassing,<br>
> > > <br>
> > > Michael Rack<br>
> > > RSM Freilassing<br>
> > > -- <br>
> > > RSM Freilassing Tel.: +49 8654 607110<br>
> > > Nocksteinstr. 13 Fax.: +49 8654 670438<br>
> > > D-83395 Freilassing <a href="http://www.rsm-freilassing.de" rel="noreferrer" target="_blank">www.rsm-freilassing.de</a><br>
> > > <br>
> > > <br>
> > > Am So., 25. März 2018 um 04:37 Uhr schrieb Michael Rack <<a href="mailto:mail@michaelrack.de" target="_blank">mail@michaelrack.de</a>>:<br>
> > > Hi,<br>
> > > <br>
> > > when i run olsrd-v1 i have some issues with KERNEL-SRC-Attribute:<br>
> > > <br>
> > > cat /etc/olsrd.conf<br>
> > > SrcIpRoutes yes<br>
> > > MainIp 91.205.13.1<br>
> > > <br>
> > > rack@de-ain-hof:~$ ip r s t 100<br>
> > > <a href="http://172.16.12.128/26" rel="noreferrer" target="_blank">172.16.12.128/26</a> via 172.16.4.196 dev eth1 metric 2 onlink<br>
> > > <a href="http://172.16.12.192/27" rel="noreferrer" target="_blank">172.16.12.192/27</a> via 172.16.11.132 dev eth0.2221 metric 2 onlink <br>
> > > <a href="http://172.16.13.92/30" rel="noreferrer" target="_blank">172.16.13.92/30</a> via 172.16.11.133 dev eth0.2221 metric 2 onlink <br>
> > > <a href="http://172.16.14.64/27" rel="noreferrer" target="_blank">172.16.14.64/27</a> via 172.16.11.133 dev eth0.2221 metric 2 onlink<br>
> > > <br>
> > > The SRC-Attribute does not kick in, so the wrong ip is shown on a traceroute.<br>
> > > <br>
> > > How do i remove the onlink from my routes?<br>
> > > -- <br>
> > > Olsr-users mailing list<br>
> > > <a href="mailto:Olsr-users@lists.olsr.org" target="_blank">Olsr-users@lists.olsr.org</a><br>
> > > <a href="https://lists.olsr.org/mailman/listinfo/olsr-users" rel="noreferrer" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
> > > -- <br>
> > > Olsr-users mailing list<br>
> > > <a href="mailto:Olsr-users@lists.olsr.org" target="_blank">Olsr-users@lists.olsr.org</a><br>
> > > <a href="https://lists.olsr.org/mailman/listinfo/olsr-users" rel="noreferrer" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
> > <br>
> <br>
<br>
</blockquote></div></div>
</blockquote></div>