upd. on vyos-1.4-rolling-202105051111 it's still there eve after reboot

PR: https://github.com/vyos/vyos-1x/pull/838

Hi. Tried it (IPv4) on vyos-1.4-rolling-202103251004 in eve-ng
It reacts to set protocols static route 0.0.0.0/0 next-hop 195.7.0.102
After reboot it's still there
Screens added. It shows static route

Please use the following op-mode command to check:

Also bug for config "vyos" set mode clientset remote-port 12345

vyos@r6-roll# run show remote-config openvpn vtun0 remote-platform vyos 
NOTE: authentication options are deliberately left out,
since we cannot know file paths on a remote system

@zsdc Can we close it?

@krox2 The next rolling release will be with keepalived 2.1.5. Can you check?

thx for the fast feedback.

PR https://github.com/vyos/vyos-1x/pull/837

PR https://github.com/vyos/vyos-build/pull/165

This task was superseded by T3411, hence was not backported; however that missed the bug fix in the final commit. cherry-pick eeb9687.

@rherold, this was a known bug, fixed in 1.4, but missed in backports to 1.3. As a workaround, systemctl stop vyos-configd before the commit will reveal the errors; if I recall correctly, the error is a missing 'country-code' entry.

@ernstjo

set policy route-map ASxxx-CUS-IN6 rule 10 action 'permit'
set policy route-map ASxxx-CUS-IN6 rule 10 set large-community '65:23:1 additive'

Yes the point of "longer-prefixes" is to find smaller routes within a bigger netmask, so if you're leaving out prefix, it doesn't make sense.

PR https://github.com/vyos/vyos-1x/pull/836

the same is the case for GRE interfaces too (ip6gre in particular)

Frr itself doesn't allow to set longer-prefixes without "prefix"

r4-1.3# show ip route 1.1.1.1 
  <cr>           
  json           JavaScript Object Notation
  nexthop-group  Nexthop Group Information

I ran a packet capture on this BGP session and it appears that VyOS actually sends some packets out and they appear to go through the right gateway... I'm investigating with the provider and will post an update here shortly.

OK, it seems that this problem doesn't need any repair and will be closed

I agree with @c-po, no warning is needed inbthis case

Why should a warning be printed?

PR: https://github.com/vyos/vyos-1x/pull/835

@runar I just checked the current implementation. It seems that the current configuration is replacing "allowed VLAN" with "native VLAN", but there is no warning. I add a warning!

Please make it so when both are present the native-vlan command is used.. do not throw an exception as this would make configuration much harder, as a eg. allow-vlan 1-4096, native-vlan 50 will be impossible to configure... Splitting up the allow-vlan and redoing it just to change native-vlan is work that the scripts should do in the backend and not have the user do it

Sadly, two years later, OMAPI is still unsuitable for this purpose.

Yes, I've changed the source since i posted the configuration and now it is the specific IP address that the peer expects.

This issue is consistently reproducible and I'm experiencing it with two peers. I convinced one of them to disable passive mode on their end but the other one is not that flexible.

Can you change update source from eth0 to x.x.x.x?

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.

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)