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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 23 2019
Fix applied in this commit:
https://github.com/vyos/vyatta-cfg-op-pppoe/commit/4330d41fcda30553ca1b3e2588d05eebdd59fc80
Apr 22 2019
@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.
suspend shouldn't be supported at all?
@c-po @hagbard @dmbaturin you thoughts on that?
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).
Apr 21 2019
Attempt two of the fix, so disregard everything in above attempt.
I want to set this ticket back to "Needs testing" or even "Open", I have downloaded and tested vyos-rolling-2019-04-16 and it seems it is not properly fixed.
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 $ ls -al ../ethtool_4.19-1_amd64.* -rw-r--r-- 1 vyos_bld vyos_bld 992 Apr 21 08:32 ../ethtool_4.19-1_amd64.changes -rw-r--r-- 1 vyos_bld vyos_bld 113986 Apr 21 08:32 ../ethtool_4.19-1_amd64.deb
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.
Apr 20 2019
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.
1.1.8
vyos@vyos# show service dhcp-server disabled false shared-network-name foo { authoritative enable subnet 10.10.10.0/24 { default-router 10.10.10.254 lease 86400 start 10.10.10.10 { stop 10.10.10.50 } } }
This can not be backported easily to 1.2 (crux) b/c of jumps in the system@ config version string.
Its already in 1.2.1
@spectre3500 Now that I think of it, did you build it with build-ami or the AWS target of the vyos-build scripts?
...oh, and remove "disable-password-authentication" from the SSH settings of course.
I wonder if this issue will ever stop re-occuring. Every time it happens, it's for some new reason. I think this time it may be related to ongoing work of @Unicron.
Related task: T1334
Here's a commented reference config from Vyatta 6.5 for testing: