In T1289#78883, @Viacheslav wrote:

Like this?

vyos@r4-roll# set policy route-map FJFFJJF rule 10 set ip-next-hop 
Possible completions:
   <x.x.x.x>    IP address

where x.x.x.x route to blackhole?

Like this?

In T1289#35636, @dmbaturin wrote:

The usual procedure is to create a route-map that sets the nexthop to a blackholed address if the advertisment has a specific community string set.
So when a customer advertises an address (rather a /32 network) to you with that string set, it automatically ends up blackholed.

Do you just want a shortcut for that, or you are having issues with community string-based approach?

This logic does not allow for the complete removal of the protocol.
https://github.com/vyos/vyatta-cfg-quagga/blob/32cbb1e5059c6c27449b7013f790aff1c50a9831/templates/protocols/ospf/passive-interface/node.def#L29-L35

@Azayaka do you mean import routes to a specific table? T3032
Can you check it with the next rolling release?

@rizkidtn Update, please your request. Is the community works for you for blackholing?

I found some interesting information, it seems that inbound/outbound port mirroring can be achieved

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

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

Can you please share the entire configuration and version of the VyOS to reproduce the issue in the lab.

set interfaces ethernet eth1 ipv6 address no-default-link-local is the right command, yes

Bug ;) will be fixed soon

Yes, but iptables tee seems to support packet copy of various rules

Do you mean that?

set interfaces ethernet eth1 mirror

1. Not all interfaces can be used as "update-source"

Missed "vti | dum | lo" etc.
https://github.com/vyos/vyos-1x/blob/current/interface-definitions/protocols-bgp.xml.in#L639

PR https://github.com/vyos/vyos-1x/pull/587
Fix the FRR template for new bgp implementation.

Pull request is up: https://github.com/vyos/vyos-1x/pull/586

How to do it?

You actually can when setting ipv6 disable-link-local addressing on the particular interface.

The root cause for this is the sha256 checksum file itself. It contains the hash and the filename. When running sha256 --check during the upgrade it expects the "real" filename when calculating and verifying the hash. The real filename differs when using the vyos-rolling-latest.iso symlink on the webserver as it will tell the running VyOS installation a different filename and the validation fails. This is now fixed by not depending on the filename when verifying the has. We simply calculate the hash of the downloaded file and compare it to the hash we saved inside the checksum file and totally ignore the filename itself.

I have tested both SSTP and L2TP and it works as expected - thank you for this addition!

Put in a PR to separate hello/hold timers for IPv4 and IPv6. Added IPv6 timers.

I will check it tomorrow and verify operation. Thank you!

Fixed

vyos@r4-roll# run show version

@klase Check these options in the next rolling release (after 20201027)

https://github.com/vyos/vyos-1x/pull/583
https://github.com/vyos/vyos-build/pull/129

FRR doesn't delete isis configuration related "interfaces" with

delete protocols isis foo interface eth1

protocol "isisd" in the test was added here https://github.com/vyos/vyos-1x/pull/483/files#diff-060cdf269ea89160caa0deaebe8e323f0559aa6dfd19e5634a33634f3e38e461R72

@kroy What PR?

sounds good - would be good having some other options than just domain-name and email, but that's another story :). I'll follow the other task then!

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

It already fixed in the master branch.
https://github.com/hiroyuki-sato/vyos-documentation/commit/8587946d16aaae6f5495c1e591220f88005cd276

Resolved in T2985

@SrividyaA Thanks.

I have tested on this rolling release VyOS 1.3-rolling-202010231135 and created a lab setup similar to the reporter's setup.

@craterman it seems bug with your resolution.

set service https certificates certbot

domain-name(s) should contain the desired server-name. A rewrite is in progress in:
https://phabricator.vyos.net/T2289

@jestabro hmmm I don't see that "certbot" in the completion - running on rolling 1.3... ? In fact, nodes "certificates" and "certbot" are not shown here:
set service https
Possible completions:
> api VyOS HTTP API configuration
> api-restrict Restrict api proxy to subset of virtual hosts
> certificates TLS certificates
+> virtual-host Identifier for virtual host

I've been running chronyd for some time in a number of environments without any noticeable issues. I do think the clock on the hosts seems to be a bit more stable, but not something that is overly remarkable one way or the other. I'd have no problem with the change.

It exists:
https://phabricator.vyos.net/T1585