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)

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

@francis We don't know anything about this issue.
And it difficult to say without the current configuration.

Any thoughts here @Viacheslav ? This issue persists in 1.3-rc4

Will take a look later today starting of with VyOS 1.4

@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.

@rherold can you recheck it? Or say is it real 1.3.0-rc4?
I can't reproduce it.

PR https://github.com/vyos/vyatta-cfg-quagga/pull/77