Greetings operators, A few days ago, support for VRRP (Virtual Router Redundancy Protocol) was merged into master. VRRP is used to provide router redundancy on LANs. FRRouting supports versions 2 and 3 of the protocol. Our next release will not have this new protocol. It will ship in the subsequent release, around September/October. In the meantime it is available in our master Git branch. RFCs: https://tools.ietf.org/html/rfc5798 <https://tools.ietf.org/html/rfc5798> https://tools.ietf.org/html/rfc3768 <https://tools.ietf.org/html/rfc3768> FRRouting documentation: http://docs.frrouting.org/en/latest/vrrp.html <http://docs.frrouting.org/en/latest/vrrp.html> Big thanks to everyone who worked with me on this new protocol daemon! Quentin
Am 20.05.2019 um 22:23 schrieb Quentin Young:
Greetings operators,
A few days ago, support for VRRP (Virtual Router Redundancy Protocol) was merged into master. VRRP is used to provide router redundancy on LANs. FRRouting supports versions 2 and 3 of the protocol.
Our next release will not have this new protocol. It will ship in the subsequent release, around September/October. In the meantime it is available in our master Git branch.
RFCs: https://tools.ietf.org/html/rfc5798 https://tools.ietf.org/html/rfc3768
FRRouting documentation: http://docs.frrouting.org/en/latest/vrrp.html
Dear Quentin, that is good new, thanks for the hard work! In the docs Kernel 5.1+ is mentioned, what about the possibilities to get this also into FreeBSD? There are many ppl out there using FRR via OPNsense/pfSense and it would be a smooth integration if advertising of VRRP VIPs would be possible. Currently the HA process is stopping FRR on the backup unit. Thanks, Michael -- www.muenz-it.de - Cisco, Linux, Networks
Dear Quentin, Am 21.05.19 um 06:35 schrieb Muenz, Michael:
Am 20.05.2019 um 22:23 schrieb Quentin Young:
Greetings operators,
A few days ago, support for VRRP (Virtual Router Redundancy Protocol) was merged into master. VRRP is used to provide router redundancy on LANs. FRRouting supports versions 2 and 3 of the protocol.
Our next release will not have this new protocol. It will ship in the subsequent release, around September/October. In the meantime it is available in our master Git branch.
RFCs: https://tools.ietf.org/html/rfc5798 https://tools.ietf.org/html/rfc3768
FRRouting documentation: http://docs.frrouting.org/en/latest/vrrp.html
what's the reason behind the kernel module? Why is it needed? Isn't VRRP just multicast which can be send in userspace? And the IP up down stuff is managed by the macvlan module. Or it is just 5.1+ because the proto up / down patch for macvlan got merged into 5.1? Greets, Stefan
what about the possibilities to get this also into FreeBSD? There are many ppl out there using FRR via OPNsense/pfSense and it would be a smooth integration if advertising of VRRP VIPs would be possible. Currently the HA process is stopping FRR on the backup unit.
I’d love to support BSD, but currently VRRP uses macvlan devices[0] to do the virtual MAC stuff. BSD doesn’t implement those. However, I know BSD implements what amounts to their own version of VRRP, called CARP[1], which uses the same protocol number and MAC addresses as VRRP, and describes itself as "a secure, free alternative" to VRRP. I think BSD has a special interface type to support this protocol - maybe VRRP could use those or something? I haven’t looked at it in depth. If anyone wants to work with me on this to add support I'd be happy to do so.
what's the reason behind the kernel module? Why is it needed?
No kernel module is needed, I don't know what you’re referring to.
Isn't VRRP just multicast which can be send in userspace?
Yes - which is what we do.
And the IP up down stuff is managed by the macvlan module. Or it is just 5.1+ because the proto up / down patch for macvlan got merged into 5.1?
That’s correct, Cumulus Networks added the kernel patches to set macvlan devices into protodown to support this VRRP implementation[2], which will ship in kernel 5.1. The docs explain this[3]. [0] https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfac... <https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking/> [1] https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol <https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b58996795dc4> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e8b4ba64676> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8f1af75df3a7> [3] http://docs.frrouting.org/en/latest/vrrp.html <http://docs.frrouting.org/en/latest/vrrp.html>
On May 21, 2019, at 2:11 AM, Stefan Priebe - Profihost AG <s.priebe@profihost.ag> wrote:
Dear Quentin,
Am 21.05.19 um 06:35 schrieb Muenz, Michael:
Am 20.05.2019 um 22:23 schrieb Quentin Young:
Greetings operators,
A few days ago, support for VRRP (Virtual Router Redundancy Protocol) was merged into master. VRRP is used to provide router redundancy on LANs. FRRouting supports versions 2 and 3 of the protocol.
Our next release will not have this new protocol. It will ship in the subsequent release, around September/October. In the meantime it is available in our master Git branch.
RFCs: https://tools.ietf.org/html/rfc5798 https://tools.ietf.org/html/rfc3768
FRRouting documentation: http://docs.frrouting.org/en/latest/vrrp.html
what's the reason behind the kernel module? Why is it needed? Isn't VRRP just multicast which can be send in userspace? And the IP up down stuff is managed by the macvlan module. Or it is just 5.1+ because the proto up / down patch for macvlan got merged into 5.1?
Greets, Stefan
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
participants (3)
-
Muenz, Michael -
Quentin Young -
Stefan Priebe - Profihost AG