A quick solution that convert JSON to config set

Can be "cherry picked" to 1.3 and 1.2

PR https://github.com/vyos/vyatta-op-vpn/pull/27

Well yeah kinda :) The driver VYOS is using is reporting wrong information to ethtool about autoneg support. No idea if it's fixed in a newer driver. Can't really play around much and I only have this type of nic in a single server. Let's hope someone comes along later with a X710 and can try more.

PR https://github.com/vyos/vyos-1x/pull/840
Can be "cherry-picked" to "equuleus" and "crux"

vyos@r6-roll# load ntp.conf
Loading configuration from 'ntp.conf'
Load complete. Use 'commit' to make changes effective.
[edit]
vyos@r6-roll#

Well then somehow this feels to me NIC related as I can not see it here.

Yes. Tried before posting the above comment.

I tried reproducing this issue on VyOS 1.3.0-rc4 but I see no link flaps on my IGB card connected to a Cisco Catalyst 1000.

thx for the fast feedback.

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

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.

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)

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