[SOLVED] Routes seem fine but does not work

Hi there,

Not sure if I found a bug or if it is related to this one: https://phabricator.vyos.net/T1218
Anyway I have a simple router (no fw, no routing policy, no nat) that has some weird behaviour.
The problem is that a static route does not work, and traffic try to go out using default-gateway even if address is in the same subnet of ethernet interface.

Here you are show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 10.127.20.71/28 u/u
eth1 10.127.10.74/28 u/u WAN
lo 127.0.0.1/8 u/u
::1/128
vti1 - A/D
vti2 - A/D
vti3 - A/D

show ip route 10.127.20.78
Routing entry for 10.127.20.64/28
Known via "connected", distance 0, metric 0, best
Last update 00:14:13 ago
* directly connected, eth0

Same subnet so virtually no routing

Then if I traceroute to 10.127.20.78 this happen:

traceroute to 10.127.20.78 (10.127.20.78), 30 hops max, 60 byte packets
1 10.127.10.78 (10.127.10.78) 0.178 ms 0.098 ms 0.154 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 *^C

Why does my router try to reach an address (which is also ARP resolved) using the default route?

traceroute to 10.127.20.49 (10.127.20.49), 30 hops max, 60 byte packets

I think something is wrong with your example here. That IP is in neither subnet, therefore it would try and find it through the default gateway.

1 Like

Sorry, corrected the example.

Can you post the output of

ip a
ip r

A directly connected IP would always take precedence.

Hi @agv
Try arping and check correct unicast reply
sudo arping 10.127.20.78 -I eth0 -s 10.127.20.71

@kroy here you are (btw thank you):

vyos@ROUTER:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 06:da:88:01:c0:be brd ff:ff:ff:ff:ff:ff
    inet 10.127.20.71/28 brd 10.127.20.79 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4da:88ff:fe01:c0be/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:00:38:f0:00:01 brd ff:ff:ff:ff:ff:ff
    inet 10.127.10.74/28 brd 10.127.10.79 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::38ff:fef0:1/64 scope link
       valid_lft forever preferred_lft forever
4: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
5: vti1@NONE: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ipip 10.127.20.71 peer 10.127.20.49
6: vti2@NONE: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ipip 10.127.10.74 peer 185.100.111.110
7: vti3@NONE: <POINTOPOINT,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ipip 10.127.10.74 peer 188.125.117.50
vyos@ROUTER:~$ ip r
default via 10.127.10.78 dev eth1 proto static metric 20
10.127.10.64/28 dev eth1 proto kernel scope link src 10.127.10.74
10.127.20.48/28 via 10.127.20.78 dev eth0 proto static metric 20
10.127.20.64/28 dev eth0 proto kernel scope link src 10.127.20.71
vyos@ROUTER:~$ ^C

And also arping result (which seems to work for @Viacheslav

vyos@ROUTER:~$ sudo arping 10.127.20.78 -I eth0 -s 10.127.20.71
ARPING 10.127.20.78 from 10.127.20.71 eth0
Unicast reply from 10.127.20.78 [00:00:5E:00:01:C1]  1.215ms
Unicast reply from 10.127.20.78 [00:00:5E:00:01:C1]  1.212ms
Unicast reply from 10.127.20.78 [00:00:5E:00:01:C1]  1.215ms
^CSent 3 probes (1 broadcast(s))
Received 3 response(s)

Maybe I forgot to mention one important thing:

This router was working just fine running 1.1.7 till this morning when I decided to try to update it to latest version 1.2.4 epa1

What about the output of:

sudo traceroute -i eth0 10.127.20.78

I don’t spot anything that stands out that would require the interface given the state of your routing table.

Here you are:

 traceroute to 10.127.20.78 (10.127.20.78), 30 hops max, 60 byte packets
 1  10.127.20.77 (10.127.20.77)  0.246 ms !X  0.223 ms !X *

What’s the networking like on 10.127.20.78 that’s causing it to respond from .77?

I don’t know for sure, it is provider side.
It seems the problem is outside the vyos router.
I already checked with the provider but they said everything is fine by their side.

@agv can you check

ip route show table 220

This is the output of ip route show table 220

default via 10.127.10.78 dev eth1 proto static

Can you try
ip route delete default table 220
and set
set vpn ipsec options disable-route-autoinstall

It works!
Thank you @Dmitry

Can you also explain what happened?

Thank you again

This information exist in our blog, I think be better to share link https://blog.vyos.io/vyos-1-dot-2-0-development-news-in-july

I did read that blog entry (and forgot about it) and in any case I would not relate these two things.

What is strange is that I have two router with the same (mirrored) configuration.
Both were 1.1.7 until this morning when I updated both at 1.2.4
These two router are just left side and right side of the same VPN and only left side had this problem, no routing problem at right side.

Anyway thank you again.

UPDATED: After some reboot the right side also behaved the same.
Solved with set vpn ipsec options disable-route-autoinstall

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.