- User Since
- Feb 7 2016, 4:09 PM (171 w, 2 d)
Tue, May 7
Fri, May 3
There are things that should be simply incorrect grammar, and this is one of them, as of me.
Tue, Apr 23
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.
Apr 21 2019
Apr 20 2019
@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:
Apr 16 2019
Apr 15 2019
Apr 14 2019
Apr 11 2019
Apr 7 2019
Apr 6 2019
Mar 31 2019
Mar 27 2019
Mar 26 2019
Curiously, I can't reproduce it in the latest rolling, even though the code hasn't changed. We need to test in latest crux builds.
The packages were out of sync with reality for some time. Should be fine now.
The packages were out of sync with reality, it should work as expected now.
@tomjepp Could you share the patch or tell us what and where you had to modify?
Mar 24 2019
Mar 23 2019
Mar 17 2019
Mar 16 2019
Feb 28 2019
Feb 23 2019
@danhusan IPv6 should not be affected. Workaround for IPv4:
Feb 21 2019
Feb 14 2019
Feb 2 2019
@primoz Adding staticd to the daemons config fixes the issue reproducibly on affected systems, even after reboot?
Feb 1 2019
@jmlccdmd Ok, I'll re-test with in/out then.
Jan 27 2019
Since this is a trivial cosmetic issue, we are about to freeze 1.2.0, and the installer is due for a rework in 1.3.0, I'm going to ignore this for now.
Works for me in the latest build.
vyos@vyos-test-2# set protocols static route6 ::/0 blackhole distance 10  vyos@vyos-test-2# commit  vyos@vyos-test-2# run show ipv6 route ::/0 Routing entry for ::/0 Known via "static", distance 10, metric 0, best Last update 00:00:10 ago * unreachable (blackhole)
Jan 26 2019
Looks like the issue with the same host displayed multiple times is fixed in the latest FRR.
Ok, I've re-tested everything one more time to be sure. I can confirm the somewhat strange (though technically correct) behaviour of blackhole routes: they become ECMP routes if there's another route of the same distance. I would expect normal routes to override them in that case, but the kernel is following its hard and fast rule that two routes with the same distance automatically become ECMP routes, that behaviour is counter-intuitive but consistent.
@jmlccdmd I've been testing it with EPA3 and friday's nightly build.
I've built lldpd 1.0.3, much newer than that from jessie. Luckily, the maintainer keep Debian packaging in the official repository, so it wasn't much effort to do.
Ok, more interesting than that. In the latest image, the setup just works as described with RFC-compliant VRRP:
This problem is specific to RFC-compliant VRRP setups. Firewall design in VyOS is rather unfortunate in that rulesets are bound to interfaces. If you assign it to eth0, a rule with -i eth0 -j MyRuleset is created. RFC-compliant (shared MAC) VRRP uses those eth0v1 etc. interfaces, but since from netfilter's point of view eth0 and eth0v1 are different interfaces, those rules are never reached.
This issue uncovered more. The parser was written under an assumption that "bare" leaf and tag nodes at the top level are not allowed. In fact, while VyOS config never have them, it's by convention rather than by design, if you create a command definition for one (set foo bar), it works just fine. So, to be consistent with the original parser, the new parser should allow them.
I've removed the restriction on the grammar to allow them (see https://github.com/vyos/libvyosconfig/commit/1dd05b330f3adfe828ba3ca4c71db2e12b8968f6), and now run show configuration commands seems to work with "partial" configs just fine. The change appears to have no ill effects on parsing "normal" config, according to my testing.
Jan 25 2019
Jan 23 2019
I suppose I can port the fix for |commands to it.
Jan 14 2019
Jan 12 2019
Jan 5 2019
Jan 3 2019
I noticed the issue but didn't get to fixing it, applied your fix now.