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.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Mar 8 2021
@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
Mar 7 2021
@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
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#Mar 6 2021
For VXLAN multicast this is a real bug.
Mar 5 2021
@c-po , yes now it works. Maybe we need to define ttl=16 as the default value?
Mar 4 2021
@c-po does not work on 1.4-rolling-202103040218
vyos@vyos# sudo ip -d link show dev vxlan241
7: vxlan241: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br241 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether fe:08:e3:3c:d4:ab brd ff:ff:ff:ff:ff:ff promiscuity 1 minmtu 68 maxmtu 65535
vxlan id 241 group 239.0.0.241 dev eth0 srcport 0 0 dstport 8472 tos inherit ttl auto ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrxOn the middle router in traffic dump I see TTL=1
18:59:29.029090 IP (tos 0x0, ttl 1, id 24806, offset 0, flags [none], proto UDP (17), length 100)
10.1.2.2.52948 > 239.0.0.241.8472: OTV, flags [I] (0x08), overlay 0, instance 241There is a bug exactly with client-ip-pool range, config generated with the mistake
[ip-pool] gw-ip-address=10.1.1.1 10.1.1.100-10.1.1.111
but expected
10.1.1.100-111
Mar 1 2021
Yes, sure. It will work only if one vlan-id defined, e.g. if you configure a couple vlan-id you will get wrong syntax"
set service pppoe-server interface eth1 vlan-id '50' set service pppoe-server interface eth1 vlan-id '60'
In generated config
vlan-mon=eth1,50,60 interface=eth1.50,60
Expected:
vlan-mon=eth1,50,60 interface=eth1.50 interface=eth1.60
Feb 28 2021
Good job! I think there exists one remark. If we set set service pppoe-server interface eth1 vlan-id '50' that means you want to listen to pppoe client on eth1.50, but in config you have
vlan-mon=eth1,50 interface=re:eth1\.\d+
e.g. eth1\.\d+ mean all vlans in eth1, even eth1.50.50.50 will fit for this regular expression
I propose do not to use a regular expression for vlan-id, as an example:
- set service pppoe-server interface eth1 vlan-id '50'
vlan-mon=eth1,50 interface=eth1.50
Yes, agree it works by show interfaces vrrp, but behavior in 1.2.x also displayed VIP by command show interfaces
I think this is a bug and need to fix it.
Feb 26 2021
Tested in the lab the following simple topology on 1.2.6-S1 and 1.3-beta, behavior the same and GARP works by default.
VyOS1 config
set high-availability vrrp group eth1 hello-source-address '100.64.0.1' set high-availability vrrp group eth1 interface 'eth1' set high-availability vrrp group eth1 peer-address '100.64.0.2' set high-availability vrrp group eth1 rfc3768-compatibility set high-availability vrrp group eth1 virtual-address '100.64.0.50/24' set high-availability vrrp group eth1 vrid '1' set interfaces ethernet eth0 address 'dhcp' set interfaces ethernet eth0 duplex 'auto' set interfaces ethernet eth0 hw-id '50:00:00:01:00:00' set interfaces ethernet eth0 speed 'auto' set interfaces ethernet eth1 address '100.64.0.1/24' set interfaces ethernet eth1 duplex 'auto' set interfaces ethernet eth1 hw-id '50:00:00:01:00:01' set interfaces ethernet eth1 speed 'auto'
VyOS2 config
set high-availability vrrp group eth1 hello-source-address '100.64.0.2' set high-availability vrrp group eth1 interface 'eth1' set high-availability vrrp group eth1 peer-address '100.64.0.1' set high-availability vrrp group eth1 virtual-address '100.64.0.50/24' set high-availability vrrp group eth1 vrid '1' set interfaces ethernet eth0 address 'dhcp' set interfaces ethernet eth0 duplex 'auto' set interfaces ethernet eth0 hw-id '50:00:00:02:00:00' set interfaces ethernet eth0 speed 'auto' set interfaces ethernet eth1 address '100.64.0.2/24' set interfaces ethernet eth1 duplex 'auto' set interfaces ethernet eth1 hw-id '50:00:00:02:00:01' set interfaces ethernet eth1 speed 'auto'
In traffic dump on VyOS3 we can see traffic when BACKUP node switched to MASTER state
14:02:34.152959 50:00:00:02:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 100.64.0.50 (ff:ff:ff:ff:ff:ff) tell 100.64.0.50, length 28 14:02:34.153042 50:00:00:02:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 100.64.0.50 (ff:ff:ff:ff:ff:ff) tell 100.64.0.50, length 28 14:02:34.153086 50:00:00:02:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 100.64.0.50 (ff:ff:ff:ff:ff:ff) tell 100.64.0.50, length 28 14:02:34.153090 50:00:00:02:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 100.64.0.50 (ff:ff:ff:ff:ff:ff) tell 100.64.0.50, length 28 14:02:34.153092 50:00:00:02:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 100.64.0.50 (ff:ff:ff:ff:ff:ff) tell 100.64.0.50, length 28 14:02:34.153467 50:00:00:02:00:01 > 50:00:00:01:00:01, ethertype IPv4 (0x0800), length 54: 100.64.0.2 > 100.64.0.1: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20 14:02:35.153544 50:00:00:02:00:01 > 50:00:00:01:00:01, ethertype IPv4 (0x0800), length 54: 100.64.0.2 > 100.64.0.1: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20 14:02:36.154117 50:00:00:02:00:01 > 50:00:00:01:00:01, ethertype IPv4 (0x0800), length 54: 100.64.0.2 > 100.64.0.1: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20 14:02:37.154233 50:00:00:02:00:01 > 50:00:00:01:00:01, ethertype IPv4 (0x0800), length 54: 100.64.0.2 > 100.64.0.1: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20 14:02:38.154470 50:00:00:02:00:01 > 50:00:00:01:00:01, ethertype IPv4 (0x0800), length 54: 100.64.0.2 > 100.64.0.1: VRRPv2, Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 20
The same behavior with rfc3768-compatibility option.
I think we don't need to change behavior because it should be suitable for all cases.
Feb 25 2021
Feb 24 2021
@c-po , it works properly
Welcome to VyOS 1.4-rolling-202102240218 (sagitta)!
Feb 23 2021
PR https://github.com/vyos/vyos-build/pull/147
Output on the local stand
Welcome to VyOS 1.4 (sagitta)!
Feb 21 2021
On 1.3-beta-202102210443 and 1.4-rolling-202102202002 all work properly and don't require any changes, mark as resolved.
I found a similar issue related to this topic in 1.2.6-S1, script on-dhcp-event.sh can't to determine pdns_recursor PID
vyos@vyos# ps ax | grep pdns 6626 ? Ssl 0:00 /usr/sbin/pdns_recursor --daemon=no --write-pid=no --disable-syslog --log-timestamp=no [edit] vyos@vyos# pgrep "pdns_recursor" [edit] vyos@vyos# pgrep pdns_recursor [edit] vyos@vyos#
We need to use pgrep pdns
vyos@vyos# pgrep pdns 6626 [edit]
Feb 19 2021
Feb 17 2021
SolarFlare modules present in the kernel for 1.3 and 1.4
vyos@vyos:~$ sudo modinfo sfc filename: /lib/modules/5.10.14-amd64-vyos/kernel/drivers/net/ethernet/sfc/sfc.ko license: GPL description: Solarflare network driver author: Solarflare Communications and Michael Brown <mbrown@fensystems.co.uk> alias: pci:v00001924d00001B03sv*sd*bc*sc*i* alias: pci:v00001924d00000B03sv*sd*bc*sc*i* alias: pci:v00001924d00001A03sv*sd*bc*sc*i* alias: pci:v00001924d00000A03sv*sd*bc*sc*i* alias: pci:v00001924d00001923sv*sd*bc*sc*i* alias: pci:v00001924d00000923sv*sd*bc*sc*i* alias: pci:v00001924d00001903sv*sd*bc*sc*i* alias: pci:v00001924d00000903sv*sd*bc*sc*i* alias: pci:v00001924d00000813sv*sd*bc*sc*i* alias: pci:v00001924d00000803sv*sd*bc*sc*i* alias: pci:v000010EEd00001100sv*sd*bc*sc*i* alias: pci:v000010EEd00000100sv*sd*bc*sc*i* depends: mdio retpoline: Y intree: Y name: sfc vermagic: 5.10.14-amd64-vyos SMP mod_unload modversions parm: vf_max_tx_channels:Limit the number of TX channels VFs can use (uint) parm: max_vfs:Reduce the number of VFs initialized by the driver (int) parm: mcdi_logging_default:Enable MCDI logging on newly-probed functions (bool) parm: rx_refill_threshold:RX descriptor ring refill threshold (%) (uint) parm: irq_adapt_low_thresh:Threshold score for reducing IRQ moderation (uint) parm: irq_adapt_high_thresh:Threshold score for increasing IRQ moderation (uint) parm: interrupt_mode:Interrupt mode (0=>MSIX 1=>MSI 2=>legacy) (uint) parm: rss_cpus:Number of CPUs to use for Receive-Side Scaling (uint) parm: efx_separate_tx_channels:Use separate channels for TX and RX (bool) parm: phy_flash_cfg:Set PHYs into reflash mode initially (bool) parm: debug:Bitmapped debugging message enable value (uint)
Feb 16 2021
As a solution proposed to use TTL by default equivalent 16, but also add the possibility to change it via VyOS CLI
Feb 15 2021
Feb 12 2021
Feb 11 2021
Feb 9 2021
We need to change this and for CRUX
vyos@RTR1# run show version | match Version Version: VyOS 1.2.6-S1 [edit] # Log Feb 9 15:12:16 RTR1 ipsec_starter[2036]: # unknown keyword 'disableuniqreqids'
Feb 8 2021
@ajgnet which exactly version used in this case?
Feb 7 2021
Emergency recovery procedure:
grub> ls (hd0,msdos1)/boot/ #Figure out directory name, in this case, this is 1.4-rolling-202102040221
Feb 6 2021
Feb 5 2021
PR https://github.com/vyos/vyos-1x/pull/722
Added sort command which provides some clarification on what the XML definition file will first in the list. It sorts by name.
So, in this case, the first XML file will be bcast-relay.xml
Feb 4 2021
Own build crux version from 13 Jan 2021 19:08 UTC - works properly
1.2.6-S1 - works properly
1.2.6 - affected (does not works)
1.4-rolling-202102040221 - works properly
1.3-beta-202102040443 - works properly
Jan 30 2021
I think we definitely need to try because this reproducible. @Viacheslav did you reproduce this on the ESXi hypervisor?
Jan 29 2021
Jan 28 2021
PR with smoketest check https://github.com/vyos/vyos-1x/pull/706
Jan 27 2021
Jan 26 2021
Tested on 1.4-rolling-202101240218, works as expected.
Jan 25 2021
@jack9603301 follow forum topic, all data randomized.
Jan 23 2021
Jan 15 2021
@GregGreg you describe definitely another issue that needs another topic. Will be better to discuss troubleshooting on the forum.
As for this topic, I pan to add some checks in the verify function.
Jan 11 2021
Jan 10 2021
Why not add this by default?
Jan 7 2021
Jan 6 2021
Jan 4 2021
@victorhooi try to build a stable version for yourself, on the stable version is defined by udev rules https://github.com/vyos/vyos-build/blob/crux/tools/vendors_udev/64-vyos-SAF51015I-net.rules
Or you can use way with binding hw-id as noticed @jack9603301 (but not mac)
Dec 31 2020
So we have configured option max-mtu this means
ppp-max-mtu=n Set the maximum MTU value that can be negotiated for PPP over L2TP sessions.
But I think we need to provide possibility set min-mtu
[ppp] min-mtu=n
