In T128#2209, @UnicronNL wrote:

As it is now it can not break the config, that is why "wontfix".
If we block it then configs that have non existent interfaces in them (due to breakage or removed and forgot to remove from dns forwarding) will fail at boot.

As it is now it can not break the config, that is why "wontfix".
If we block it then configs that have non existent interfaces in them (due to breakage or removed and forgot to remove from dns forwarding) will fail at boot.

In T128#2194, @dmbaturin wrote:

As @UnicronNL says, lines about nonexistent interfaces have no effect on dnsmasq functionality.

But what's worse, is that making it a commit fail will break the configs of those people who carelessly left a nonexistent interface in their DNS forwarding config, it will fail to load at boot time after upgrade.

As much as I hate generating configs that make no sense, leaving those people with potentially inaccessible systems after they upgrade (DNS loads before SSH AFAIR) is not an acceptable cost of somewhat tidier generated configs.

As @UnicronNL says, lines about nonexistent interfaces have no effect on dnsmasq functionality.

I see no reference to all lowercase squidguard.conf at all in the source???

persistent net rules is not used in vyos? where do you get that from?
it uses hw-id from config file.

I can suggest trying to do fork() on before line 139 and exit this forked child later - this should keep parent daemon's memory footprint constant.

https://github.com/vyos/vyatta-vrrp/commit/86a3e32d367c6936fe424d6aace06ea7262f4300

@dmbaturin is about unsaved changes indication
@jeffbearer system loads last saved config

Can you push your recent changes to github?

Changing the priorities, I managed to make it work and it's loaded fine on reboot.

You need "create" section in your templates/policy/route-map/node.tag/rule/node.tag/set/src/node.def to make things survive reboots, I think.

@dmbaturin can you checkout this

Ok, so the main issue is that the route-map is only applied to routes installed _after_ it's been setup ... so you have to remove / readd all the static routes which obviously doesn't work when you reboot :(

This is my attempt :

vyos@r1-80001# run sh ver

[ policy route PPPOE_CLAMPING ]
iptables: Invalid argument. Run `dmesg' for more information.
Use of uninitialized value $rule_strs[1] in join or string at /opt/vyatta/sbin/vyatta-firewall.pl line 734.
Use of uninitialized value $rule_strs[2] in join or string at /opt/vyatta/sbin/vyatta-firewall.pl line 734.
Use of uninitialized value $rule_strs[3] in join or string at /opt/vyatta/sbin/vyatta-firewall.pl line 734.
Use of uninitialized value $rule_strs[4] in join or string at /opt/vyatta/sbin/vyatta-firewall.pl line 734.
Use of uninitialized value $rule_strs[5] in join or string at /opt/vyatta/sbin/vyatta-firewall.pl line 734.
iptables error: No such file or directory - -m comment --comment "PPPOE_CLAMPING-10" -p tcp -m tcp --tcp-flags SYN SYN -m iprange ! --dst-range 192.168.20.0-192.168.30.255 -j TCPMSS --clamp-mss-to-pmtu at /opt/vyatta/sbin/vyatta-firewall.pl line 734.

Unfortunately, I'm traveling right now, so I'll have to try out a newer image and give you the output from 'sudo blkid' in three weeks. I'll look forward to some good progress when I return!

Can you please post the corresponding iptables error?

to what version did you upgrade? (vyos) squeeze 1.7 or debian jessie?

/opt/vyatta/sbin/vyos-persistpath Is used for an other type of install, not for add system image.

It actually looks worse than it is!
The first message is a pain in the ass :( it is live boot trying to find persistence.. it should not be verbose, but somehow it is.

I was thinking of just updating the ssh service

Would this be a setting in the SSH service or rather system login. Because the former allows you to employ wildcards: VYOS-* while the latter feels more correct otherwise. Or you could have both, default the SSHd setting to no-one, and whitelist per user || employ the wildcard solution.

Seems sensible to combine them both are similar changes and will be managed by same cfg scripts/templates.

Good point,
not sure if we can combine this with T110 task as they are both about SSH

@higebu seems correct.
It will be a good start

We need this? https://github.com/hiroyuki-sato/vyos-cfg-zabbix-agent

I found the original task, this one is a duplicate of https://phabricator.vyos.net/T91

Multiple inbound-interfaces was going to be the next task I raised for wan load-balancing :). We should probably change the name of the option to something more descriptive of what it does. exclude-traffic-from-interfaces or similar.

Once we have device specific images, this will be solved,
but hardcoded values if they exist not great at all :)

@UnicronNL @EwaldvanGeffen @dmbaturin @afics @mickvav
How would we treat that all devices?
@dmbaturin proposed to build per device images with customizations required
As @UnicronNL already doing that for ClearFog we just need to agree common way maybe

I wonder if we can even extend groups even further into the NAT rules as well.

Ah, good to know. So if we add a switch like transport ipv4/ipv6 to the cli which is only valid for VRRPv3 (add a switch for that too) and then exclude either all v4 or all v6 addresses, would that work?

virtual_ipaddress_excluded is basically a list of lines that keepalived passes to ip addr add / ip addr del when the main VRRP state changes. Typically, it's used to manage more than 20 addresses with keepalived (only the first 20 go in virtual_ipaddress, which is in the actual VRRP packet; the rest are failed over through this out-of-band configuration). According to that thread (and past experience), it should work for this case.

Does it work, if you use virtual_ipaddress_excluded? Also I don't really understand how this would solve the problem? Could you please explain it?

If I make a patch to use virtual_ipaddress_excluded, do you prefer an arcanist diff or a github pull request?

Oh man, that's going to be a disaster for all the companies out there relying on mixed v4/v6 blocks (which is extremely common in v6 setups).

@jbrown This only works for you because your keepalived versions are old enough.
This got "fixed" (well, at least they're standards compliant now ;)) in 1.2.20 I believe.
See https://github.com/acassen/keepalived/issues/375#issuecomment-230148110 for more information.

Also, here's the config that I'm running on my VyOS test VMs (with R33:5bccce5948cc44e76f8c9da93f1a1cf8f1212bca ):

Try it with vrrp_version 2; I believe that will work. It seems to default to standards-compliant behavior (that is to say, no mixed-virtual-addresses) in v3. Not sure if there's a way to turn that off or not. Here's what the config at my current employer looks like

[root@test ~]# cat /etc/keepalived/keepalived.conf 
vrrp_instance VI_1 {
    state MASTER
    interface ens3
    virtual_router_id 51
    priority 200
    advert_int 1
    vrrp_version 3
    native_ipv6
    authentication {
        auth_type ah
        auth_pass 1111
    }
    virtual_ipaddress {
        3ffa::1/64
        192.168.100.200/24 
    }
}

Does only work for the v6 address with this configuration.

I tested with keepalived version 1.2.22 on Fedora and it didn't seem to work. I'll test again.

We need extra VRRP instances for IPv4 and IPv6, keepalived can only have virtual_addresses of the instances native address family.

Yep... And really, I understood that all hosts with shared-network-name prefix are static mapped.

so this mean, that problem can be in static mapping

Update:
I added one more Cisco SPA8000 to my network, at beginning it was added normally, but when i make it static-mapping, i got:
cat /etc/hosts
10.11.3.12 AdrSPA8000-3.voip.adriatika.local #on-dhcp-event d0:c7:89:78:fb:f0 - it was DHCP
10.11.3.7 VoIP_spa8000-3.voip.adriatika.local #on-dhcp-event d0:c7:89:78:fb:f0 - it's DHCP+static-mapping

As you can see: Hostname Option 12, length 12: "AdrSPA8000-1"
But:
cat /etc/hosts | grep spa8000-1
10.11.3.5 VoIP_spa8000-1.voip.adriatika.local #on-dhcp-event 20:aa:4b:57:f4:80

May be you can run tcpdump -nvvv port bootps on your host to catch your client's requests to make sure that clients request hostnames without prefixes?

I didn't edit it.
That's it http://pastebin.com/8BcPLgkn

@EwaldvanGeffen it can be that we have issue with dhcp event script
it looks like that output of tools used in that script changed
and now that script produce a mess in /etc/hosts

@EwaldvanGeffen take a look,
maybe you can provide estimates
Thanks!

Hello,
this placed on the wishlist,
expect it in 1.2.x

Are there any updates to this ticket?

Merged, closing.

Commited into current, separate patch available for 117 users if needed be.

@EwaldvanGeffen
It would be great if you could help us with this issue. So I can continue testing this version.

No problem with the updates for OpenVPN going into 1.2.0.