This should now work aswell with the latest vyos 1.3 versions!
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
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.
Your rolling release so old. As I remember it was a bug with FRR, which was fixed.
Try more latest versions or vyos-1.3.0-rc1 https://community.vyos.net/get/snapshots/
@c-po confirmed, works OK in vyos-1.3-beta-202102250443-amd64.iso. Thanks a lot!
Put in a PR for this, https://github.com/vyos/vyos-1x/pull/744
Feb 25 2021
This should have been fixed in the latest 1.3 beta - please try again
It seems the same problem (lack of "ethtool -g" support) happens also with "veth" interfaces.. ref T2516
I'm seeing the same problem with Xen HVM guests, where the paravirtualized nic-driver "xen_netfront" doesn't seem to support "ethtool -g".. ref T3347
Please ignore this task, it works fine!
Feb 24 2021
I can confirm this bug is still present in the latest 1.3-rolling-202101 snapshot as well as the latest stable release. (1.2.6-S1)
Better not touch crux ;)
ok, I'll do it
@craterman can you check this feature in the latest rolling or beta?
PR for equuleus | extended smoketest
https://github.com/vyos/vyos-1x/pull/743
@dmbaturin @c-po Hi, I have basically completed the T3116 draft implementation, test, I only inspect the ipvsadm rules, seems to work properly, the draft only for ipvsadm, to set up some rules, now, you and @c-po can achieve the preliminary examination of the draft (about smoke tests, I currently only normal execution of the command line configuration program testing, has not yet been configured efficacy)
VyOS is still on the ancient shell-based diagnostic file generator spaghetti inherited from Vyatta. First of all, I'm going to dike out {show,generate} tech-support from vyatta-op and write a rudimentary stub as a replacement in Python/XML. Then we'll need to discuss what exactly needs to go in there.
@c-po , it works properly
Welcome to VyOS 1.4-rolling-202102240218 (sagitta)!
Feb 23 2021
PR https://github.com/vyos/vyatta-cfg-quagga/pull/71
Can be "cherry-picked" to equuleus
PR for equuleus for bgp and ospf https://github.com/vyos/vyatta-cfg-quagga/pull/70
PR for equuleus for rip https://github.com/vyos/vyos-1x/pull/741
If commit is not initiated from a 'live' session (for example, on boot), then redirected stdout/err should go to a file.
Yes, radius is used for login.
If that works out wihtout an issue I would like to have it backported into 1.3 just to be more "fancy".
PR https://github.com/vyos/vyos-build/pull/147
Output on the local stand
Welcome to VyOS 1.4 (sagitta)!
I can't reproduce it
@Viacheslav
I guess the logs are from the dhcp-server and not from the client...
@tuxnet Can you describe the steps to reproduce?
also having lots of NAT rules makes the vyos config handling and boot time very slow..