Bugfix: Filter-ID -> Filter-Id
It will be good to have ability to configure followed GARP settings for individual VRRP groups or, at least for keepalived daemon overall, becouse in some situation switches can filter multiple ARP-packets, that is generated on transition.
In the process of migration to 1.2.1 we have discovered, that some GARP packets (we have 6 VRRP-groups on Interner interface) was filtered with ARP-spoofing filter by our ISP.
Problem was solved with VRRP-migration scripts, that execute some additional arping in ARP-Reply mode.
@c-po thanks for that. I changed my configs from postconfig script to new config syntax
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.
Fix applied in this commit:
@hagbard Can you please test the steps I mentioned mentioned here, to see if you can reproduce: https://phabricator.vyos.net/T1028#35591
Without any modifications to any scripts, it will bring the interface into permanent down state after suspend and resume.
It should work, at least it does for me. ether-resume is my script, it just makes sure that dhcp is called when it was configured, if not is just call the interface up and reapplies the IP address. Routes should be in frr anyway and with the interface up again, these would become active again as well. Netplugd calls scripts on event, up and down and doesn't call anything within open-vm-tools.
Please test with latest rolling image before VyOS 1.2.2 is released
To complete this, the corresponding changes need to be made in vyatta-cfg-system; these are straightforward and will be pushed to current. However, there is another mechanism whereby the console speed is explicitly being set to 9600: the vyatta-config-migrate script, called during system initialization, is invoking migrate/system/3-to-4, which sets the console speed; this will require some discussion as to how to best address.
Thank you for providing the necessary clarity that was lacking in your very misleading first response.
You have not provided a procedure on how to reproduce the issue and there are no other reports on such problem, therefore this task has low priority.
Either it's something specific to your environment or you have issues with upstream DNS and/or network
I don't understand "needs testing" here at all? What testing? How can I help? For me this is obviously high priority, in fact it's a deal-breaker, it's a problem I need to solve. As I think it would be for you if you had the bug on your network. I thought maybe the vyos team would also consider it high. Why low? Seems important that dns fails regularly. Why isn't it? (I have a solution that works but it's a selfish one that doesn't help vyos).
Sun, Apr 21
ok, that was a test for new statuses
so we can track backport process better
Backport is done already by me
I can not test it due to lacking KVM environment. All good on ESXi.
The new syntax will be:
Package now included in VyOS builds - please test
How to build:
$ git clone https://salsa.debian.org/kernel-team/ethtool.git $ cd ethtool $ git checkout debian/1%4.19-1 $ dpkg-buildpackage -uc -us -tc -b
Using ethtool 4.19 results in:
vyos@vyos# sudo /sbin/ethtool -K eth0 gso off
We use ethtool provided by Debian Jessie (3.16) which is bound to 3.16 Linux Kernel.
Sat, Apr 20
EdgeOS uses this node.def file:
Proposing a Cisco like interface:
Already in 1.2.1
I wasn't aware that there was an aws target for the vyos-build scripts.
This can not be backported easily to 1.2 (crux) b/c of jumps in the system@ config version string.