@fvbrasileiro Yeah, we found that out too today, we are working on a solution already. Please be patient.

In T1705#44982, @hagbard wrote:

@fvbrasileiro Please test at your earliest convenience.

https://github.com/vyos/vyos-1x/commit/e45648cdd5a52569be7f3ac30473b0c7474a7894
http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb

@bertleywjh What issue are your trying to debug?

Next rolling will have it: https://github.com/vyos/vyatta-op-quagga/commit/219265ae4c8886bb6997ffc79f34610d6e2ea2d0 or you can manually install from the source below, if it is an urgent matter.

The cli part for the routing suite is up for rewrite, json is only working because it's supported by frr and the cli doesn't filter it. I think getting show ip route tag 20 working shouldn't be a big deal, but I try to avoid to add too much to the cli, will make just the rewrite way harder.

@hagbard via a route-map for example. set policy route-map TAG rule 10 set tag 33

There were multiple complains about bgpd crashes, memory issues inthe forum. They used the workaround removing the tables from snmpd successfully.

@olofl How do you set the tag? via CLI?

I do not see this problem on a full table v4/v6 router with 2 cores 4 GB RAM. The question is why? Is removing the table a good idea? What was the state with 1.1.8?

Pull Request to clarify group names must be unique.

@fvbrasileiro Please test at your earliest convenience.

I made a test lab at home for this, so let me know if you have any other settings or anything you need documentation for.

https://github.com/vyos/vyatta-cfg-system/commit/4b3434f8fab3201e7483bff95af71b7a1f51a13c

1.2 is not affected which runs OpenSSH_6.7p1 Debian-5+deb8u8, OpenSSL 1.0.1t 3 May 2016

Well, shame on you in that case ;0)

@phillipmcmahon I only implemented it as of yesterday ....

Well, shame on me for not trying. Appreciate you checking that on my behalf.

set interfaces ethernet ethß dhcp-options vendor-class-id "bar fooo vyos" is what you get 😄

@cpo cumulus behave differently cause they use an other implementation as in pure frr. They use PTMD see https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Bidirectional-Forwarding-Detection-BFD/ and https://github.com/CumulusNetworks/ptm

@c-po wrote:
I would not backport it. Its a proof of concept and things are still unclear about peer configuration (why does cumulus FRR behave differently and has no peer config) also the FRR interface is only a PoC.

Can we just remove the deprecated options from being generated? They only leave a few lines in syslog, but these options are deprecated already in stretch.
(https://www.openssh.com/txt/release-7.5 ff)

https://github.com/vyos/vyos-build/commit/1ff1b22726f1f4678dca8295860623d728e20521

Any way of reproducing this with a simple snmpwalk? snmpget?

I'm somewhat agnostic to the implementation method. Whether as raw options or explicitly supported options handled natively in the CLI. Both work for me.

@phillipmcmahon personally I'm not a fan of general raw option passing as we have in other places like OpenVPN oder DHCP server.

BGP scan-time parameter is unneeded in current FRRouting and VyOS - there are used modern next-hop tracking instead. You must avoid using this option. I have prepared PR to delete this option and migrate the old configuration, where it exists:
https://github.com/vyos/vyatta-cfg-quagga/pull/36
https://github.com/vyos/vyos-1x/pull/145

• systemctl disable pacemaker
• systemctl disable corosync
• systemctl disable wpa_supplicant
• systemctl disable squid

I see in v1.2.3 that the option to supply client-id and hostname exists which is great. My ISP requires the sending of DHCP Option 60 (VCI) in order to correctly get a lease. In EdgeOS it ends up looking like the following

@trae32566 definately! As Arista is gaining more food in the marked please share it here so we can then add it to our documentation.

I have a VyOS <-> Arista configuration, which should be similar to Cisco, if that works for y'all?

I would not backport it. Its a proof of concept and things are still unclear about peer configuration (why does cumulus FRR behave differently and has no peer config) also the FRR interface is only a PoC.

Yes I'm currently utilizing the rolling releases in service after basic functionality testing, and so far BFD has worked flawlessly for all protocols I've tested.

Hi @albeu thank you for this contribution. While reviewing it I found one flaw:

The following patch fix the issue for me: