There is no such thing like separate identities. You can either decrypt a package or you can't, that's about it. You basically have to hand out more public keys, you have to maintain more keys. As I mentioned before I only see currently disadvantages so far. However the user can chose what way to go and multiple options are always good. If it helps you, well that's nice to hear.

In T1572#42883, @hagbard wrote:

It's not so much the implementation as I wrote before, it just doesn't seem beneficial. It gets implemented anyway, but I try to understand why a user would like to use that. The private key is by the way no identity and also won't interfere with multiple VPN peers if you are using only one pk. On IP:12345 arrives an encrypted packet, it is simply decrypted using your pk. If it works it's given to your kernel netlink interface as far as I recall and routed there, so no verification of the private key anywhere. If it can't be decrypted, it's discarded. If you have multiple wg interfaces, your 'crypto routing' either allows the traffic to the peer or discards it if it doesn't fit, the private key has nothing to do with that, since the public key of your peer is used to encrypt it. Summary, I still cna't see any benefit having that, which doesn't mean that I won't implement it.

This feature is currently in the 1.2 rolling release.

It would be awsome if the feature could also be made available in the next VyOS 1.2.x version.
Because it likely takes a lot more time until version 1.3 gets released.

https://github.com/vyos/vyos-1x/commit/c6e9285262ddd762aac96ad3fa30d63cdeb2c6f2

Can confirm. All my routing tables now have 0.0.0.0/0, no matter what the device is. This is just in 1.2.3.

Seems that it s merged an in 1.2.3 it looks in the moment good for me:

Unfortunately we have multiple commands like this.

Exist interesting moment when LLDPD communicate with cisco ios, after 1 min 55 second LLDPD in VyOS forget cisco device, but cisco device send LLDP (with ethertype encapsulated in vlan 1 0x8100). However LLDPD in VyOS remember mikrotik and other VyOS router, which directly connected, and which also transmit LLDP. I was try using and new version LLDPD which build for myself, but same result.
After adding vlan 1 on directly connected interface with cisco device LLDPD in VyOS, R1 don't forget it.

That's fixed the problem we had, but we've encountered some other strangeness.

At this point I've moved all my ASAs to VyOS, and all my tunnels to Wireguard. Unfortunately I cannot test this setup anymore.

Do you still have that problem?
Did you see EwaldvanGeffen's message?
Do you have any comment on it?

Thank you, @c-po, I'll go deploy it now, then! :-)

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201909231545-amd64.iso

ISO rebuild triggered

It's in 1.2 rolling too, but the iso has to rebuild. You can alternatively download and manually install http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb.

Has this been merged into 1.2, or just 1.3? Because all of the 1.2-rolling images currently available from downloads.vyos.io right now have this bug in them :-(

MikroTik RouterOS supports something like this:

Why does this BGP neighbor need to be configred in the VyOS CLI? Wouldn't it be added automatically as a side-effect of wanting netflow data to have ASNs? Maybe add a flag to netflow, for those of us who are carrying full tables.

https://github.com/vyos/vyos-1x/commit/eed2ba5379067ba3ef3a7b9eef72b8252958e766

Having had bgpd peg a core to 100% (for no discernible reason), I'd welcome the ability to give quag^WFRR a kick, rather than rebooting the entire VyOS box.

We run ntop on a separate device, and export netflow data to the ntop/nprobe box from our routers (VyOS included). Would that work in your scenario too?

To elaborate on what was written above, in the case of amd64 packages, a package more recent than 3.8.2 is not available from the debian.org repository as there are no more recent releases. The official SourceForge project has been marked as unmaintained by its owner wimpunk, and 3.8.2 was the last release.

Hello @kroy I trying test your issue in lab and some question about rfc4957, Does LLDP should see more one neighbour? In my Lab all directly connected devices filter ethertype LLDP (0x88cc) for passthrough. Can you explain, how exactly connected R1,R2,R3,R4? In one switch?

Created pull request

Just some feedback here, but this has been working flawlessly in all my environments so far for BGP, OSPF, and OSPFv3 ... you guys are awesome!

Almost done, also implemented 'random' flag, looks ok? or change name? for example - flag, or flags

Using 1.2-rolling-201909210810, it has happened to me.

Please add the config here as text so it can be easily extracted. Image hosting services tend to not store information forever.

Would be very nice, I tested with an old one already, but want to make sure I haven't uncovered side effects.

Already fixed manually, but I can test on yesterday's vm backup if needed.

Not sure what you mean by pre and post-commit config blocks.

https://github.com/vyos/vyos-1x/commit/eb9c6ff745fc5d4e23c224a441874ae6fcf97ac5
@mb300sd Tomorrows rolling will have the fix applied.

https://phabricator.vyos.net/T1499

@thinkl33t you can run your own DNS server with dynamic update functionality, vyos's dhcp server will write the hostnames to it. Doing that is outside the scope of vyos though, and you'd have to think of security, e.g. can a rogue dhcp client DNS spoof your hostnames to do a MITM attack. Systems that do do dyn-dns updates, for example FreeIPA, usually use some sort of pre-shared keys/certificates on the clients (for authentication) and limit the scope to IP updates on preexisting hostnames only, they don't allow adding arbitrary hostnames. At least I'd limit the scope to add all dynamic dns updates to a single zone predefined expressly for that purpose, and not use that zone for any security-critical applications, like logging in to services or doing unauthenticated connections, where a MITM may scrape your sensitive data. I'd only do dyn-dns hostnames from dhcp on a DHCP network where I'm absolutely sure no rogue client could gain access to it, via the network or physically, and that is almost never useful.

In T1416#40429, @zsdc wrote:

@thinkl33t, recommended way is using dynamic-dns-update, all other ways are not recommended to use at this moment.

Seems that upstream did not backport the fixes to the stable version's. So it is only included in frr 7.2.
I asked them for backport.

Okay, the old vyatta-bonding.pl executed the following code when a bond member has been removed:

PR merged.

This issue don't reproduces at 1.2.2 and 1.2.3-epa1. As for rolling release after T1548, seems all correct and works.

set interfaces openvpn vtun0 server push-route '100.64.0.0/24'
set interfaces openvpn vtun0 server push-route '172.16.41.0/24'
set interfaces openvpn vtun0 server push-route '172.16.42.0/24'

vyos@vyos# sudo cat /opt/vyatta/etc/openvpn/openvpn-vtun0.conf | grep push
push "route 100.64.0.0 255.255.255.0"
push "route 172.16.41.0 255.255.255.0"
push "route 172.16.42.0 255.255.255.0"

on client

vyos@vyos-rtr01# run show ip route | grep vtun0
S>* 10.23.0.0/16 [1/0] is directly connected, vtun0, 00:03:25
C>* 10.23.1.1/32 is directly connected, vtun0, 00:03:25
K>* 100.64.0.0/24 [0/0] via 10.23.1.1, vtun0, 00:03:25
K>* 172.16.41.0/24 [0/0] via 10.23.1.1, vtun0, 00:03:25
K>* 172.16.42.0/24 [0/0] via 10.23.1.1, vtun0, 00:03:25

@kronenpj can you try last rolling release for confirm this?

I have just sent a Pull Request to clarify on the manual how tricky openvpn-option --reneg-sec can be.

@rcit Lot's of development underway and since I wasn't able to reproduce it anymoe, I thought I ask, Feel free to reopen if the issue re-occurs.

@hagbard I don't know if this is somehow relevant regarding VyOS 1.3, but i have tested it with VyOS 1.2.3-epa1 just today and it works perfectly.

Thank you Taras. Pull request sent.
https://github.com/vyos/vyos-documentation/pull/103