1.1.8 configuration

set system syslog host [2001:db8::2]:514 facility all level 'all'

Looks good on 1.4-rolling-202103090218:

Try one of them options

I kill the vm 80+ times.
All works fine.
@c-po can we "cherry-pick" it to 1.3.0?

Same problem here in version1.4.

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

Related task https://phabricator.vyos.net/T2362
A maybe better solution in this case to create interfaces like bridge and interfaces with an option which block adding link-local address.

PR:

• https://github.com/vyos/vyos-1x/pull/762
• https://github.com/vyos/vyatta-cfg-system/pull/139

PR https://github.com/vyos/vyatta-wanloadbalance/pull/10

i just tested that solution and it worked too. thanks!

@marcomuskus as a temporary solution try to use CLI sysctl param

configure
set system sysctl custom net.ipv6.conf.default.addr_gen_mode value 0
commit

Looks good on 1.4-rolling-202103080218:

Looks good on 1.4-rolling-202103080218:

vrf detected even it not created
https://github.com/vyos/vyos-1x/blob/dd35eb76153191bc487e3ea23c3e73c753ec1d4b/src/etc/dhcp/dhclient-enter-hooks.d/03-vyos-ipwrapper#L55-L59

root@r-roll01:/home/vyos# basename /sys/class/net/eth1/upper_* | sed -e 's/upper_//'
eth1v1

Wrong behavior

Original task https://phabricator.vyos.net/T3377

Original task https://phabricator.vyos.net/T3377

Original task https://phabricator.vyos.net/T3377

Original task https://phabricator.vyos.net/T3377

@Viacheslav , thanks for improving, now it works properly. I found one interesting moment, it looks like we cant configure via CLI listen to PPPoE clients on interfaces eth1 and eth1.50 or eth1.something at the same time.

vyos@vyos# run show configuration commands | match "pppoe-server interface"
set service pppoe-server interface eth1 vlan-id '50'
set service pppoe-server interface eth1.1000 vlan-range '1-4095'
[edit]
vyos@vyos# set service pppoe-server interface eth1

@trystan attach please configuration with sets, how to reproduce it.
For example

set param xxx option xxx..
set param2 xxx .option xxx..

And after commit... tc error..

Also does not display other interfaces under the end node

vyos@RTR1# run show interfaces 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             xxx.xxx.36.246/24                 u/u  
lo               127.0.0.1/8                       u/u  
                 ::1/128                                
tun0             2001:470:xxxx:xxx::2/64           u/u  HE.NET IPv6 Tunnel
[edit]
vyos@RTR1# run show interfaces tunnel 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
[edit]
vyos@RTR1# run show interfaces ethernet 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
[edit]
vyos@RTR1#

For VXLAN multicast this is a real bug.

@Cheeze_It that's the new "normal".

For 1.2 this could be evaluated in the tunnels node.def file by something like:

@c-po, using a value of "0" for use inbound packet would actually be the best behavior if we can specify/use that.

I wonder why it is 1 by default now - we actually specify 0 which means "take it from the inbound packet". Nevertheless we need a migrator to mimic existing behavior vor users upgrading from 1.2 -> 1.3, so the migrator should simply insert ttl = 16 into the CLI.

The same with ports.
It will be fixed after rewriting the firewall to python.

Same thing on

vyos@vyos:~$ show vers
Version:          VyOS 1.2.7-epa1
Release Train:    crux

The same behavior happens with VyOS-1.3.0-rc1

vyos@vyos:~$ show vers

Submitted this PR to fix the issue:

I know my opinion is....really not that important but I would *highly* recommend going to maximum TTL of 255 or at minimum 127. TTL is a very hard thing to troubleshoot most of the time and therefore it's almost never worth going lower than maximum for IP TTL.

@c-po , yes now it works. Maybe we need to define ttl=16 as the default value?

FRR doesn't have such a function.