Quentin Young [Fri, 15 Mar 2019 19:54:37 +0000 (19:54 +0000)]
vrrpd: tweak startup criteria for v6 VRRP router
* Remove check for having at least 2 IPv6 addresses on the macvlan
device; this was only taking place in v6, and breaking the ability to
start VRRP on an IPv6 macvlan that was already set to protodown on
* Improve log messaging indicating that we cannot start because we
haven't got any VIPs configured
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Thu, 14 Mar 2019 19:51:32 +0000 (19:51 +0000)]
zebra: don't protodown a NULL interface
We were running into some problems where VRRP is trying to protodown
interfaces that no longer exist. While this is a minor bug in its own
right, this was crashing Zebra because Zebra was not doing a null check
after its ifindex lookup.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Wed, 13 Mar 2019 18:37:48 +0000 (18:37 +0000)]
vrrpd: fix v2 master_down_interval computation
VRRPv2 uses the configured advertisement interval to compute the master
down timer, whereas VRRPv3 uses the one advertised by the master. Fix
computation to use the configured in in v2.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Wed, 13 Mar 2019 17:18:36 +0000 (17:18 +0000)]
vrrpd: include auth fields in v2 packet
Based on looking at other vendors, seems I misinterpreted the RFC - type
0 auth (no authentication) still requires the authentication fields to
be present, just set to all zero.
This should fix VRRPv2 interop with other vendors.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Tue, 12 Mar 2019 17:31:39 +0000 (17:31 +0000)]
vrrpd: allow centisecond precision for vrrpv2
The RFC is not clear about how precise the skew time calculation should
be in VRRPv2. The advertisement interval is given in seconds, and the
field in the advertisement packet only supports non-fractional seconds,
so I was following this for calculating skew time as well. However the
skew time formula in vrrpv2 always yields a fractional amount of seconds
in the range (0-1), which right now means we always truncate to 0
seconds. I doubt this is what the RFC wanted so I'm allowing centisecond
precision for skew time.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Fri, 8 Mar 2019 18:52:56 +0000 (18:52 +0000)]
vrrpd: display primary address in json output
And also, fill in the non-json output with a :: for the v6 primary since
we're letting the operating system select which one it wants to use and
we don't actually know what our primary address is. Another thing to
revisit in the future...
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Fri, 8 Mar 2019 18:35:04 +0000 (18:35 +0000)]
Revert "Revert "vrrpd: protodown mvlans when shutting down""
Now that the requirement of knowing our VRRP IPv6 primary address in
advance is lifted, it's no problem for us that the macvlans could be
down when we get them. We can handle this in both the v4 and v6 case
now, so we don't need to behave as if they should always be left up.
Quentin Young [Fri, 8 Mar 2019 18:30:03 +0000 (18:30 +0000)]
vrrpd: allow OS to choose VRRP IPv6 src address
Under IPv6, Linux will look at our destination address and select the
source address with the smallest scope that covers the destination. For
the VRRP multicast address ff02::12, Linux will always select a link
local address.
We can take advantage of this behavior to avoid a subtle and complicated
class of bugs caused by Zebra's semantics around inoperative interfaces.
As far as Zebra is concerned, an inoperative interface has no addresses
assigned to it. This is a real bummer for VRRP because it's quite
possible that the IPv6 VRRP macvlan device is down when we attach to it,
and we would really like to be able to know in advance which address we
will be transmitting IPv6 advertisements from without having to bring an
interface up to convince Zebra to tell us its address list.
In the future, though, it would be better to be explicit about selecting
the link local we want. This will require adding the ability to Zebra to
read and send us address information for inoperative interfaces.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Wed, 6 Mar 2019 18:34:34 +0000 (18:34 +0000)]
vrrpd: disallow setting priority = 255
Assuming we fix our automatic detection method in the future, we won't
be able to revert this back to disallowing 255 without breaking user
configs. Let's just disallow it now, there's no functional difference
still.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Tue, 5 Mar 2019 20:33:27 +0000 (20:33 +0000)]
vrrpd: fix broken reads when reinitializing
When a VRRP router was shut down - either due to an administrative
event, or its interface getting deleted, or some other reason - it was
forgetting to cancel its read task. When it was started again, the read
task was still around, and so it wasn't getting scheduled again with the
new socket fd's. This caused our socket to queue ingress packets but
never read them, resulting in the restarted router always electing
itself to Master (since it wasn't listening to any other advertisements,
even though the kernel was delivering them).
The t_write cancellation call doesn't matter here, but I'm putting it in
there because it doesn't hurt and this way I won't forget about it if it
becomes necessary in the future.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Mon, 4 Mar 2019 20:15:25 +0000 (20:15 +0000)]
vrrpd: delay sending advert/garp/una for ifup pt 2
Pt 2: When transitioning directly into Master (because we are the
address owner), wait until Zebra sets the macvlan device to protodown
off before transmitting advertisements, gratuitous ARPs, or Unsolicited
Neighbor Advertisements.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Mon, 4 Mar 2019 18:46:08 +0000 (18:46 +0000)]
vrrpd: delay sending adverts/garp/una for iface up
When transitioning to Master from Backup, wait until Zebra sets the
macvlan device to protodown off before transmitting advertisements,
gratuitous ARPs, or Unsolicited Neighbor Advertisements.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Mon, 4 Mar 2019 17:27:55 +0000 (17:27 +0000)]
vrrpd: allow user to set priority = 255
Too many problems with implicit ownership determination via duplicate
address assignment. Will revisit that in the future. For now, allow user
to specify 255 as a priority value. This is functionally no different
than any other priority value; it just serves as a self-documenting way
of saying you want one router to always be master.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Thu, 28 Feb 2019 23:13:20 +0000 (23:13 +0000)]
vrrpd: fix autoconfig of protodown'd interfaces
When autoconfiguring VRRP, interfaces that are protodown'd should be
automatically brought up. Otherwise Zebra won't send us their interface
addresses and we'll sit in Initialize forever.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Thu, 28 Feb 2019 19:00:26 +0000 (19:00 +0000)]
vrrpd: use parent interface LLA for advert tx
Interface MACs for v6 macvlan devices are the same, so the link local
address will be the same, which breaks mastership election based on
primary address comparison. Use the parent interface link local address.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Thu, 28 Feb 2019 18:25:39 +0000 (18:25 +0000)]
vrrpd: only update one vrrp_router list at a time
When using an autoconfigured VRRP instance, when an interface address
was added or deleted we were trying to update the address list for both
v4 and v6 vrrp_router's which sometimes would cause all the addresses to
get deleted off of one of them and result in an automatic shutdown.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Wed, 27 Feb 2019 22:46:24 +0000 (22:46 +0000)]
vrrpd: set autoconfed VRRP ifaces protodown off
If we just detected a macvlan and used it to automatically create an
interface, set that interface into protodown off. This way users don't
have to manually bring the interface back up in order to get autoconfig
to work again.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Wed, 27 Feb 2019 20:46:35 +0000 (20:46 +0000)]
vrrpd: be less smart about interface state
Stop caring about interface state so much. It's screwing up autoconfig
because Zebra's message semantics are pretty much absolute nonsense when
it comes to indicating interface state.
This change will cause us to do things like attempt to transmit
advertisements on a down interface, but I'd rather have the user see
those error messages in the log file than force them to fight vrrpd to
convince it that, yes, they actually do want a VRRP instance created.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Tue, 19 Feb 2019 22:36:34 +0000 (22:36 +0000)]
vrrpd: don't update interface addrs on ifup
Updating interface addresses on autoconfigured VRRP instances when we
receive notification that an interface is up will cause us to delete
that VRRP instance because Zebra deletes all interface addresses when an
interfaces goes down so when it comes back up it has no addresses which
causes us to delete the instance, then Zebra subsequently sends us the
addresses which causes the instance to get recreated, however in a
non-owner scenario this will merely cause us to start in Backup, wait a
while, transition to Master, protodown off our interface, get an
interface up notification, delete all our ip addresses, destroy
ourselves, receive address notifications, recreate ourselves, reenter
Backup and cycle through it all over again.
So we just have to assume that no addresses went away since this
interface was last up.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Tue, 19 Feb 2019 22:01:35 +0000 (22:01 +0000)]
vrrpd: use if_is_operative()
Checks for interface usability instead of admin state, which is what I
wanted anyway. Also removes the operstate check when binding interfaces.
This way we can bind currently inoperative interfaces, won't start until
they're at least admin up, but *will* start if they're carrier down,
because we can fix that (and probably caused it :)
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Fri, 15 Feb 2019 19:32:08 +0000 (19:32 +0000)]
vrrpd: tweak interface tracking on ifdown
Change the interface tracking code to react to an interface down by
automatically transitioning to Backup, instead of shutting down the
session. This is because we get ZEBRA_INTERFACE_DOWN messages when we
set an interface to protodown as part of transitioning to Backup; if we
shut down the session in response to these messages, we end up shutting
ourselves down every time we try to transition to Backup.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Thu, 14 Feb 2019 22:28:51 +0000 (22:28 +0000)]
vrrpd: interface tracking
* Dynamically bind interfaces when they become available
* Automatically start VRRP sessions when their interfaces are added or
come up
* Automatically shut down VRRP sessions when their interfaces are
deleted or go down
* Automatically unbind interfaces when they are deleted
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Wed, 13 Feb 2019 22:16:56 +0000 (22:16 +0000)]
vrrpd: skip binding interface after create
When automatically creating new VRRP instances, we don't need to try to
bind them to macvlan interfaces again. We only need to do that when we
got notified that a new interface came up and want an existing VRRP
instance to update its interface bindings.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Tue, 12 Feb 2019 21:22:20 +0000 (21:22 +0000)]
vrrpd: properly retrieve pkt src address
* Fix null dereference when retrieving IPv6 source address
* Change IPv4 code path to use system-specified source address instead
of the one delivered in the IPv4 raw header
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Mon, 11 Feb 2019 16:36:09 +0000 (16:36 +0000)]
vrrpd: allow creation of adverts with no addresses
Fuzz testing revealed a crash in which VRRPD tries to create an
advertisement packet with no IP addresses. Should never occur under
normal use but might as well patch.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Fri, 8 Feb 2019 19:47:55 +0000 (19:47 +0000)]
vrrpd: properly find iface in manual cfg mode
As a crutch, interface search when manually configuring VRRP on an
interface did a prefix match on the name of macvlan interfaces,
comparing its name to the name of the interface VRRP was configured on
in order to determine if the interface under question was a subinterface
of the configured interface. This is obviously fragile and prone to
failure. We now pass up parent interface info from Zebra so use that
instead to correctly deduce parent-child relationships.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Fri, 1 Feb 2019 18:49:16 +0000 (18:49 +0000)]
vrrpd: cleanup vrrp packet crafting code
* Prefix all packet functions with 'vrrp_pkt'
* Break out checksum computation into separate function
* Accept version field when building advertisements
* Update doc comments
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Do nothing if user tries to add the same IP twice
* Implement deletion of IPs
* Deactivate virtual router if all IPs are deleted
* Deduplicate add / remove code
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
projects / mirror_frr.git / log