r6:~$ show ip route 172.107.195.1 Routing entry for 172.107.195.1/32 Known via "static", distance 1, metric 0, best Last update 00:32:33 ago * 38.39.193.57, via eth0, weight 1
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
May 10 2021
May 10 2021
I've also tried with disable-connected-check option with no effect
This is the current setup:
I think there is no routes to neighbor
So you get it via default-route
You need to declare /32 route
Or use option
“ set protocols bgp neighbor <address|interface> disable-connected-check”
The route is set and validated with traceroute and it has 2 hops.
it not directly connected neighbours It can’t determine route to the next hop.
Try to set /32 route to ipv4 next hop and check again.
dtoux renamed T3533: BGP IPv4 does not initiateate a session from BGP IPv4 does not initiate ate session to BGP IPv4 does not initiateate a session.
Related to the image here are sanitized configs (I've removed firewall entries since I've tested without a firewall config and the issue persists. I've replaced all IPs with dummy ones
I can try to sanitize my configs and post here – FWIW, this issue is not in 1.2.7 LTS (self built)
Here is an old implementation for Vyatta. Moreover Jool does MAP-T, offers a kernel module, and is being implemented into nftables.
I tested vyos-1.3-rolling-202105011026-amd64.iso and everything is correct
GitHub <noreply@github.com> committed rVYOSONEXfe12810cc65f: smoketest: policy: T3526: replace seq x for policy tests (authored by Viacheslav).
Viacheslav closed T3528: Frr 7.5.1 uses 'seq' for community-lists, a subtask of T3182: Main blocker Task for FRR 7.4/7.5 series update, as Resolved.
@francis We don't know anything about this issue.
And it difficult to say without the current configuration.
May 9 2021
May 9 2021
Any thoughts here @Viacheslav ? This issue persists in 1.3-rc4
c-po closed T2175: Rewriting all FRR processes allow for reloading and to XML/Python style, a subtask of T3355: Remove all remaining legacy Vyatta code, as Resolved.
c-po closed T2175: Rewriting all FRR processes allow for reloading and to XML/Python style as Resolved.
c-po moved T3531: policy: prefix-list and route-map names do not allow underscores in names (FRR does) from Open to Finished on the VyOS 1.4 Sagitta board.
c-po renamed T3531: policy: prefix-list and route-map names do not allow underscores in names (FRR does) from vyos shell prefix-list and route-maps does not allow underscores in names, but vtysh does to policy: prefix-list and route-map names do not allow underscores in names (FRR does).
c-po added a comment to T3531: policy: prefix-list and route-map names do not allow underscores in names (FRR does).
Will take a look later today starting of with VyOS 1.4
c-po changed the status of T3531: policy: prefix-list and route-map names do not allow underscores in names (FRR does) from Open to In progress.
c-po moved T3529: vyos.frr class has no support for multi-line modify_section from Open to Backlog on the VyOS 1.4 Sagitta board.
c-po renamed T3483: Update Linux Kernel to v4.19.195 from Update Linux Kernel to v4.19.188 to Update Linux Kernel to v4.19.190.
c-po edited projects for T3479: route-maps containing "aggregator as" can not be deleted, added: VyOS 1.2 Crux (VyOS 1.2.8); removed VyOS 1.2 Crux.
May 8 2021
May 8 2021
@Viacheslav yes it was rc4 got the link some day's befor release via slack. I will setup a test lab next days, these boxes are now in production.
c-po changed the status of T3512: set protocols static table creates wrong frr config from Open to On hold.
c-po renamed T3318: Update Linux Kernel to v5.4.208 / 5.10.142 from Update Linux Kernel to v5.4.115 / 5.10.33 to Update Linux Kernel to v5.4.117 / 5.10.35.
Viacheslav removed a subtask for T3528: Frr 7.5.1 uses 'seq' for community-lists: T3517: FRR 7.5 bfd behavior for 1.3.
Viacheslav removed a parent task for T3517: FRR 7.5 bfd behavior for 1.3: T3528: Frr 7.5.1 uses 'seq' for community-lists.
@rherold can you recheck it? Or say is it real 1.3.0-rc4?
I can't reproduce it.
Viacheslav closed T3517: FRR 7.5 bfd behavior for 1.3, a subtask of T3182: Main blocker Task for FRR 7.4/7.5 series update, as Resolved.
Viacheslav closed T3517: FRR 7.5 bfd behavior for 1.3, a subtask of T3528: Frr 7.5.1 uses 'seq' for community-lists, as Resolved.
Viacheslav added a subtask for T3528: Frr 7.5.1 uses 'seq' for community-lists: T3517: FRR 7.5 bfd behavior for 1.3.
Viacheslav added a parent task for T3517: FRR 7.5 bfd behavior for 1.3: T3528: Frr 7.5.1 uses 'seq' for community-lists.
Viacheslav added a parent task for T3528: Frr 7.5.1 uses 'seq' for community-lists: T3182: Main blocker Task for FRR 7.4/7.5 series update.
May 7 2021
May 7 2021
set vpn ipsec site-to-site peer 100.64.0.2 dhcp-interface eth1
Viacheslav updated subscribers of T3341: Wrong behavior of the "reset vpn ipsec-peer XXX tunnel XXX" command.
Which proper format do we need?
For example 2 tunnels:
peer-100.64.0.2-tunnel-0
peer-100.64.0.2-tunnel-1
PBR works if we change the static route to:
Viacheslav closed T3333: "show vpn ipsec sa" reports ESP tunnels to be up when they are not., a subtask of T2641: Rewrite vpn ipsec OP commands in new style XML syntax, as Resolved.
Viacheslav closed T3333: "show vpn ipsec sa" reports ESP tunnels to be up when they are not. as Resolved.
Viacheslav triaged T3505: Commits do not respect changes in FRR that are not stored in a config as High priority.
Maybe related task T3505 which deletes the default route for DHCP in the commit.
Note that adding autosudo=False to the call to cmd does not fix this issue because this parameter is never passed to popen: https://github.com/vyos/vyos-1x/blob/current/python/vyos/util.py#L143
GitHub <noreply@github.com> committed rVYOSONEXb5c608949719: remote: T3356: use custom MissingHostKeyPolicy (authored by erkin).
mbailey added a comment to T3429: Hyper-V integration services not working on VyOS 1.4 (sagitta/current).
Confirming that this bug is still present on 1.4-rolling-20210505111.
May 6 2021
May 6 2021
I have not built vyos since 2018, so my last production version was 201803051831.