Dormant static default route over unnumbered PPP interface
Static default route over unnumbered PPP interface is stuck in dormant state. Manually installing this route in kernel with 'ip route' does not give any issues. bird> show static 0.0.0.0/0 via 10.210.137.96 (dormant) bird> show route Table master4: 10.210.137.97/32 unicast [direct1 10:55:13.947] * (255) dev lo 10.210.137.96/32 unicast [direct1 10:55:19.252] * (255) dev p1-1-1-1-2 10.0.0.0/20 unicast [direct1 10:54:37.104] * (255) dev eth0 # ifconfig p1-1-1-1-2 p1-1-1-1-2 Link encap:Point-to-Point Protocol inet addr:10.210.137.97 P-t-P:10.210.137.96 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:1178 errors:0 dropped:2 overruns:0 frame:0 TX packets:782 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:62113 (60.6 KiB) TX bytes:57060 (55.7 KiB)
On Wed, Apr 29, 2020 at 12:17:07PM +0000, Kenth Eriksson wrote:
Static default route over unnumbered PPP interface is stuck in dormant state. Manually installing this route in kernel with 'ip route' does not give any issues.
Hi What is an output of 'show interfaces' and static protocol config? Does it help if you restart static protocol?
bird> show static 0.0.0.0/0 via 10.210.137.96 (dormant)
bird> show route Table master4: 10.210.137.97/32 unicast [direct1 10:55:13.947] * (255) dev lo 10.210.137.96/32 unicast [direct1 10:55:19.252] * (255) dev p1-1-1-1-2 10.0.0.0/20 unicast [direct1 10:54:37.104] * (255) dev eth0
# ifconfig p1-1-1-1-2 p1-1-1-1-2 Link encap:Point-to-Point Protocol inet addr:10.210.137.97 P-t-P:10.210.137.96 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:1178 errors:0 dropped:2 overruns:0 frame:0 TX packets:782 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:62113 (60.6 KiB) TX bytes:57060 (55.7 KiB)
-- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Wed, 2020-04-29 at 14:44 +0200, Ondrej Zajicek wrote:
What is an output of 'show interfaces' and static protocol config?
protocol static static1 { ipv4 {import all;}; check link 1; route 0.0.0.0/0 via 10.210.137.96 {preference=255;}; } bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 127.0.0.1/8 (Preferred, scope host) 10.210.137.97/32 (scope site) eth0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.0.1.1/20 (Preferred, scope site) eth1 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkDown MTU=1500 10.210.137.97/20 (Preferred, scope site) eth2 up (index=4) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 eth2.11 up (index=5) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 eth2.12 down (index=6) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth2.13 down (index=7) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth2.14 down (index=8) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth2.21 down (index=9) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth2.22 down (index=10) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth2.23 down (index=11) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth2.24 down (index=12) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 p1-1-1-1-2 up (index=13) PtP Multicast AdminUp LinkUp MTU=1492 10.210.137.97/32 (Preferred, opposite 10.210.137.96, scope site) bird>
Does it help if you restart static protocol? No
On Wed, Apr 29, 2020 at 12:17:07PM +0000, Kenth Eriksson wrote:
Static default route over unnumbered PPP interface is stuck in dormant state. Manually installing this route in kernel with 'ip route' does not give any issues.
Hmm, works for me (with latest master branch): bird> show static static4 10.10.4.0/24 via 10.10.2.3 (dormant) # ip addr add dev ve0 10.10.1.1 peer 10.10.2.3 bird> show static static4 10.10.4.0/24 via 10.10.2.3 bird> show route 10.10.4.0/24 Table master4: 10.10.4.0/24 unicast [static4 01:02:05.390] * (200) via 10.10.2.3 on ve0 (although it is on virtual ethernet and not PPP interface, but this should depend only on PtP addresses and not interface type). Could you check latest version, whether it is not related to 'link check' option, and whether it would work on ethernet with PtP addresses? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Thu, 2020-04-30 at 01:09 +0200, Ondrej Zajicek wrote:
Could you check latest version, whether it is not related to 'link check' option, and whether it would work on ethernet with PtP addresses?
If I change it from ip nexthop to interface nexthop then it works (with check link 1) bird> show static 0.0.0.0/0 dev p1-1-1-1-2 It also works with ip nexthop if I remove check link bird> show static 0.0.0.0/0 via 10.210.137.96 bird> All tests done on 2.04. Can check 2.0.7 if you think any changes are done there.
On Thu, Apr 30, 2020 at 08:39:22AM +0000, Kenth Eriksson wrote:
On Thu, 2020-04-30 at 01:09 +0200, Ondrej Zajicek wrote:
Could you check latest version, whether it is not related to 'link check' option, and whether it would work on ethernet with PtP addresses?
If I change it from ip nexthop to interface nexthop then it works (with check link 1)
bird> show static 0.0.0.0/0 dev p1-1-1-1-2
It also works with ip nexthop if I remove check link
You also have: eth1 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkDown MTU=1500 10.210.137.97/20 (Preferred, scope site) Which has matching prefix. For static route next hops, BIRD just finds the first matching iface, does not do longest-match. So it matches with eth1 and then fails due to LinkDown and 'check link'. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Thu, 2020-04-30 at 15:09 +0200, Ondrej Zajicek wrote:
You also have:
eth1 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkDown MTU=1500 10.210.137.97/20 (Preferred, scope site)
Which has matching prefix. For static route next hops, BIRD just finds the first matching iface, does not do longest-match. So it matches with eth1 and then fails due to LinkDown and 'check link'.
Correct. The route was indeed resolved over eth1. Re-tested with vanilla 2.0.7, same issue there.
On Thu, 2020-04-30 at 15:09 +0200, Ondrej Zajicek wrote:
For static route next hops, BIRD just finds the first matching iface, does not do longest-match.
What is the rationale to not do LPM on static routes? How difficult would it be to fix? Static routes without LPM is a bit awkward.
On Mon, May 04, 2020 at 01:23:48PM +0000, Kenth Eriksson wrote:
On Thu, 2020-04-30 at 15:09 +0200, Ondrej Zajicek wrote:
For static route next hops, BIRD just finds the first matching iface, does not do longest-match.
What is the rationale to not do LPM on static routes? How difficult would it be to fix? Static routes without LPM is a bit awkward.
Well, for usual interfaces (say ethernet) there should not be covering prefix ranges on different interfaces (either the prefix is same, because iface is connected to the same network, or disjoint), so no need for LPM. This is different from regular routing table, which may contains also aggregate prefixes, so LPM is necessary in general routing table lookup. But it is true that with PtP links it makes sense to have /32 neighbor routes that are subset od some other network on different iface, like in your case, so we will change it to do regular LPM even in this case. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Mon, 2020-05-04 at 16:07 +0200, Ondrej Zajicek wrote:
But it is true that with PtP links it makes sense to have /32 neighbor routes that are subset od some other network on different iface, like in your case, so we will change it to do regular LPM even in this case.
Great, let me know when you have a commit SHA.
On Mon, May 04, 2020 at 02:36:22PM +0000, Kenth Eriksson wrote:
On Mon, 2020-05-04 at 16:07 +0200, Ondrej Zajicek wrote:
But it is true that with PtP links it makes sense to have /32 neighbor routes that are subset od some other network on different iface, like in your case, so we will change it to do regular LPM even in this case.
Great, let me know when you have a commit SHA.
Hi, fixed in commit b8bbbbaf569799ab8faff0ee185528b6a2129154. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Kenth Eriksson -
Ondrej Zajicek