Now using the following config, unfortunately my routers don't have that much traffic:

This will be added with FRR integration

Hello c-po, here is a good description of the JUNOS SRX HA configuration, and how it works pretty general: https://kb.juniper.net/InfoCenter/index?page=content&id=KB21312&actp=METADATA

Could you please provide e.g. links to SRX docu/whitepapers?

Hi there,

It seems to be working now

@begetan could you please retest?

Duplicate of T495

Closing for now then, let's reopen if needed, or make a separate task for bridging openvpn with new interface types.

@mb300sd The reason we do not allo arbitrary names is that there's no easy way to find out exact interface type, so we forced them to begin with eth, br, tun etc. so that scripts can find out what it is and filter only compatible interfaces.
Relaxing the requirements to "starts with keyword" like eth-lan or tun-office would be an interesting idea, but I'm afraid only in the long run, since a number of scripts have regexes like eth\d+ hardcoded in them and it will take time to clean up.

Looks like it was merged, closing, thanks :)

https://github.com/vyos/vyos-1x/pull/24

Can please someone assign it to me, I was/am working on that one and opened a subtask since I can't assign this one here tom myself.

pending merge

pending merge

Problem happens in ln 27 in /opt/vyatta/share/vyatta-cfg/templates/interfaces/wireless/node.def, $VAR seems to be empty.

+1 for Constellations

As far as I could tell before, it was triggered by my unique attempt to bridge a vlan to openvpn.

Finally had some down time I could to use to debug this, but it appears to be fixed in the latest revisions. Going back to 201806151501 still breaks it though.

Wouldn't it be easier by just excluding 127.0.0.0/8 and ::/1?
I haven't checked, but how is it handled with IPv6 anyway? Like the link local adresses.
I see if I can find out, why it takes a reboot for the host_name.py script to function properly, I found in my tests yesterday it is always executed. hostnamectl sets /etc/hostname to "hostname.domain", shouldn't be done that way anyway.
It seems to be the culprit, but more testing is required, I won't have much time today.

i will propose three files
system - for system things
user - for static hosts mappings
DHCP - for DHCP generated entries

On a side note:

Just adding a note to confirm that RFC-compliant VRRP does work correctly provided the arp_filter settings are fixed. I am able to forward traffic through the routing using its virtual MAC as the next-hop and firewall policy remains correctly applied.

cat /etc/hosts
127.0.0.1 localhost debian <----
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

... and that is why you don't like systemd. hostnamectl is bailing out, why? No idea yet.
libnss-myhostname may fix that already, it modifies nsswitch.conf and myhostname is always being resolved regardless if its in /etc/hosts or not.
I'm still looking why it is not setting the hostname, but does when you reboot. The config is executed, I checked that.

In T750#17132, @hagbard wrote:

additionally in /etc/hosts each change adds the localhost line instead of replacing it.

127.0.1.1 vyos-hostnametest.localdomain # VyOS entry
127.0.1.1 vyos-hostnametest.localdomain # VyOS entry
127.0.1.1 vyos-hostnametest.localdomain # VyOS entry

additionally in /etc/hosts each change adds the localhost line instead of replacing it.

One note: I'm removing the "firewall" option. First, it's only relevant for RFC-compliant VRRP, and there's no checking for it. Second, it has no advantages over assigning the firewall directly to the parent interface in any case.
Third, it was implemented inconsistently: ethernet VIFs and non-ethernet interfaces (e.g. bond) lack it.

This is reproducible:

I have never attempted the non-RFC-compliant implementation but will test it Monday.

For the reference: https://github.com/acassen/keepalived/blob/master/doc/NOTE_vrrp_vmac.txt

Does the problem also exist with the other kind of VRRP?

This is for rfc3768-compatibility enabled

I'd need to check.

Thanks for getting back to us
@dmbaturin where we set this ?

In case you don't see the updates:

On a side note the reason I'm digging into this in 1.2 is that 1.1.8 currently has a bug where unicast ARP directed to a VRRP virtual IP is not responded to (while ARP sent to broadcast works fine).

Quick update that using the transition-script method does not work (I think because the script isn't run as root).

Moving this to critical because a router that won't respond to ARP is not very useful :-)

I started with vyos-1.2.0-rolling+201807050337-amd64.iso and it only occurs after the first reboot after a new image installation. The next reboot fixes it.

There was one or two 1.2.0 images that did have a hostname problem due to a problem in the new implementation of the system host-name command, but I fixed it. I wonder if your problem might be carried over from one of those images.

Hmm weird. Then I rather nuke the 1.2.0 installation and redo it completely.

Could you try updating some test machine from 1.1.8?

Don't remember how it was from 1.1.8 to 1.2.0 but within 1.2.0 always.

You get this when you upgrade from a previous rolling release, or from 1.1.8? If the former, which one?