[Olsr-users] Do not insert onlink routes GNU/LINUX
Michael Rack
(spam-protected)
Sat Aug 25 17:33:49 CEST 2018
Sorry Guys,
issue solved. It is a feature. Not a bug :-)
*(spam-protected):/home/rack#* cat
> /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr
> 1
> *(spam-protected):/home/rack#* sysctl
> net.ipv4.icmp_errors_use_inbound_ifaddr=0
> net.ipv4.icmp_errors_use_inbound_ifaddr = 0
after changing net.ipv4.icmp_errors_use_inbound_ifaddr to 0 things starts
working as expected.
*QUOTE:* https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
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
Dont know why it was set to 1.
My traceroute [v0.91.1-4c982]
> *de-nbg-voip-pri* (80.255.15.137)
> 2018-08-25T17:28:48+0200
> Keys: Help Display mode Restart statistics Order of fields quit
> Packets
> Pings
> Host Loss% Snt Last Avg
> Best Wrst StDev
> 1. 80.255.15.129 0.0% 7 3.6 4.0
> 1.7 7.6 2.0
> 2. 81.95.15.65 0.0% 7 0.8 0.8
> 0.6 1.0 0.1
> 3. 81.95.2.38 0.0% 7 5.2 7.2
> 5.2 18.6 5.0
> 4. 5.56.17.162 0.0% 7 5.2 5.3
> 5.1 5.9 0.3
> 5. 91.205.12.1 0.0% 7 5.3 5.1
> 5.0 5.3 0.1
> *6. 91.205.13.1 0.0% 6 7.5
> 7.0 5.7 7.6 0.7*
> 7. 91.205.13.17 0.0% 6 11.1 13.5
> 9.5 23.1 5.0
Thank you for your help.
You pointed me to the right direction.
Am Sa., 25. Aug. 2018 um 17:14 Uhr schrieb Michael Rack <(spam-protected)
>:
> Yes it uses 91.205.13.1
>
> *(spam-protected):/home/rack#* curl http://checkip.dyndns.org
>> <html><head><title>Current IP Check</title></head><body>Current IP
>> Address: 91.205.13.1</body></html>
>
>
> So perhaps that is a kernel issue and not related to OLSR.
> That is wierd.
>
> Am Sa., 25. Aug. 2018 um 15:02 Uhr schrieb Teco Boot <(spam-protected)>:
>
>> So on default table, there is src and onlink.
>>
>> Is outgoing traffic on eth1.2220 using 91.205.13.1?
>> 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?
>>
>> Teco
>>
>> > Op 25 aug. 2018, om 13:47 heeft Michael Rack <(spam-protected)> het
>> volgende geschreven:
>> >
>> > (spam-protected):/home/rack# ip r s t default
>> > default via 91.205.12.1 dev eth1.2220 src 91.205.13.1 metric 2 onlink
>> > default via 172.16.11.1 dev eth1.2220 proto bird src 91.205.13.1
>> metric 32
>> >
>> > (spam-protected):/home/rack# ip a s dev lo
>> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> > inet 127.0.0.1/8 scope host lo
>> > valid_lft forever preferred_lft forever
>> > inet 91.205.13.1/32 scope global lo:olsr
>> > valid_lft forever preferred_lft forever
>> > inet6 ::1/128 scope host
>> > valid_lft forever preferred_lft forever
>> >
>> > But on traceroute:
>> > traceroute to 91.205.13.18 (91.205.13.18), 30 hops max, 60 byte packets
>> > 1 ae0-404.nbg20.core-backbone.com (83.142.85.225) 0.330 ms 0.493
>> ms 0.472 ms
>> > 2 ae4-2057.slz10.core-backbone.com (81.95.2.38) 4.723 ms 4.752 ms
>> 4.731 ms
>> > 3 at-sbg-itz-tz-k10-r10-bgp02-et6-v101.rsm-connect.net
>> (5.56.17.162) 4.640 ms 4.653 ms 4.633 ms
>> > 4 sbg-rou1-1.rsm-connect.net (91.205.12.1) 4.610 ms 4.575 ms
>> 4.597 ms
>> > 5 172.16.11.8 (172.16.11.8) 5.756 ms 5.748 ms 5.724 ms
>> > 6 dynamic-ip5bcd0d12.ain-hof.rsm-connect.net (91.205.13.18) 17.897
>> ms 19.321 ms 24.536 ms
>> >
>> > there is the interface-ip-address from eth1.2220 on ICMP-Exceeded in
>> transit.
>> >
>> > For locally generated ip-packets kernel lookup on the src attribute.
>> > But when in my case "onlink" attribute is inserted, this will not work
>> as expected.
>> >
>> > Currently i am switching from OLSR to eBGP with BFD for link-sensing.
>> > 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.
>> >
>> >
>> > Am Sa., 25. Aug. 2018 um 12:53 Uhr schrieb Teco Boot <(spam-protected)>:
>> >
>> > > Op 25 aug. 2018, om 12:19 heeft Michael Rack <(spam-protected)>
>> het volgende geschreven:
>> > >
>> > > Yes i am using rt-table 100.
>> > >
>> > > Because of the onlink attribute on the route the src-attribute will
>> not be injected / will not kick in.
>> >
>> > I wrote it works for me.
>> >
>> >
>> > > I did some testing with manually added routes.
>> > > When i add onlink to my route the src-attribute does not kick in.
>> >
>> > It does.
>> >
>> > (spam-protected):~# ip route add 192.168.6.6 via 192.168.7.7 dev lo src
>> 172.31.11.11
>> > RTNETLINK answers: Network is unreachable
>> > (spam-protected):~# ip route add 192.168.6.6 via 192.168.7.7 dev lo src
>> 172.31.11.11 onlink
>> > (spam-protected):~# ip route show 192.168.6.6
>> > 192.168.6.6 via 192.168.7.7 dev lo src 172.31.157.11 onlink
>> > (spam-protected):~#
>> >
>> > 172.31.11.11 is MainIP and is configured on another interface.
>> >
>> >
>> > > When i remove the onlink attribute it will work as expected.
>> > >
>> > > So is there an option in olsrd.conf to remove the onlink attribute?
>> > >
>> > > When will onlink be inserted?
>> > > Why is it necesery at all?
>> >
>> > For next hop IP address that does not meet kernel checks. E.g. neighbor
>> is on other subnet.
>> >
>> > Is your main address configured?
>> >
>> > Teco
>> >
>> >
>> > >
>> > > Am Sa., 25. Aug. 2018 um 11:59 Uhr schrieb Teco Boot <(spam-protected)
>> >:
>> > > What is the issue: add src or remove onlink?
>> > >
>> > > SrcIpRoutes works for me.
>> > >
>> > > Your olsrd.conf may have something special. Table 100?
>> > >
>> > > Teco
>> > >
>> > > > Op 24 aug. 2018, om 19:15 heeft Michael Rack <
>> (spam-protected)> het volgende geschreven:
>> > > >
>> > > > Is there now solution to remove onlink attribute on routes?
>> > > >
>> > > > Liebe Grüße aus Freilassing,
>> > > >
>> > > > Michael Rack
>> > > > RSM Freilassing
>> > > > --
>> > > > RSM Freilassing Tel.: +49 8654 607110
>> > > > Nocksteinstr. 13 Fax.: +49 8654 670438
>> > > > D-83395 Freilassing www.rsm-freilassing.de
>> > > >
>> > > >
>> > > > Am So., 25. März 2018 um 04:37 Uhr schrieb Michael Rack <
>> (spam-protected)>:
>> > > > Hi,
>> > > >
>> > > > when i run olsrd-v1 i have some issues with KERNEL-SRC-Attribute:
>> > > >
>> > > > cat /etc/olsrd.conf
>> > > > SrcIpRoutes yes
>> > > > MainIp 91.205.13.1
>> > > >
>> > > > (spam-protected):~$ ip r s t 100
>> > > > 172.16.12.128/26 via 172.16.4.196 dev eth1 metric 2 onlink
>> > > > 172.16.12.192/27 via 172.16.11.132 dev eth0.2221 metric 2 onlink
>> > > > 172.16.13.92/30 via 172.16.11.133 dev eth0.2221 metric 2 onlink
>> > > > 172.16.14.64/27 via 172.16.11.133 dev eth0.2221 metric 2 onlink
>> > > >
>> > > > The SRC-Attribute does not kick in, so the wrong ip is shown on a
>> traceroute.
>> > > >
>> > > > How do i remove the onlink from my routes?
>> > > > --
>> > > > Olsr-users mailing list
>> > > > (spam-protected)
>> > > > https://lists.olsr.org/mailman/listinfo/olsr-users
>> > > > --
>> > > > Olsr-users mailing list
>> > > > (spam-protected)
>> > > > https://lists.olsr.org/mailman/listinfo/olsr-users
>> > >
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20180825/cf099d45/attachment-0001.html>
More information about the Olsr-users
mailing list