Vyatta NOS documentation

Learn how to install, configure, and operate Vyatta Network Operating System (Vyatta NOS), which helps to drive our virtual networking and physical platforms portfolio.

interfaces <interface> vrrp vrrp-group <group-id> rfc-compatibility

Creates a VRRP interface, which enables RFC-compliant MAC address behavior.

set interfaces interface vrrp vrrp-group group-id rfc-compatibility
delete interfaces interface vrrp vrrp-group group-id rfc-compatibility
show interfaces interface vrrp vrrp-group group-id rfc-compatibility

If this option is not configured, the system uses legacy (non-RFC 3768-compliant) MAC address behavior when a new master is elected. For details, refer to Virtual MAC Address.

The type keyword and identifier of an interface. For detailed keywords and arguments that can be specified as interfaces, refer to Supported Dataplane Interfaces.
The identifier of a VRRP group to which the interface belongs. The identifier ranges from 1 through 255.

In addition to the parameters shown here, a VRRP interface can be configured in the same way as the parent interface.

Configuration mode

interfaces interface {
    vrrp {
        vrrp-group group-id {

Use this command to enable RFC 3768-compliant MAC address behavior when a new master router is elected. Setting this option defines a VRRP interface for the VRRP group that you are configuring.

RFC 3768 defines a specific 48-bit MAC address that is to be associated with each VRRP virtual router. The ARP translation of the IPv4 or IPv6 address for the virtual router points to this MAC address.

The master router uses this well-defined MAC address as the source MAC address of VRRP packets that it sends, in this way teaching switches to send packets for that MAC address to itself. If one master router fails and another router takes over as the master, it acts in the same way.

When a VRRP interface is configured for a VRRP group, the system assigns the well-defined MAC address to the VRRP interface according to RFC 3768. Using the well-defined MAC address ensures quick failover of traffic for that MAC address. In addition, the ARP translations of the other hosts and routers on the network do not need to change when a new router takes over as master router. This configuration is recommended.

When configured, the system automatically assigns the VRRP virtual MAC address to the VRRP interface. When a new master router is elected, the system uses the procedure described in RFC 3768 to have the new master take over the virtual MAC address. The VRRP interface remains on the system as long as the configuration does, independent of whether the VRRP instance is in a backup or master state.

The system automatically generates a name for the VRRP interface by appending vrrpn (where n is an arbitrary number starting from 1) to the physical interface prefix, for example, dp0vrrp1.

The interface name is based on the highest existing interface; for a scenario in which you configure three groups (dp0vrrp1, dp0vrrp2, and dp0vrrp3), then delete dp0vrrp2 and create another group, the interface name for the new group is dp0vrrp4.

The VRRP interface remains on the system as long as the rfc3768-compatibility option is set, and remains on the system independent of the state of the VRRP instance (backup or master).

The VRRP interface that is created by the VRRP process operates in a special “pass-through” mode. The pass-through mode allows the router to receive packets addressed to the well-known VRRP MAC address for a given VRID on the parent interface. The VRRP interface is used only to send VRRP advertisement packets when its associated VRRP group is acting as the master router for the group.

Use the set form of this command to direct the system to use RFC 3768-compliant MAC address handling when a new master is elected and create a VRRP interface.

Use the delete form of this command to remove the VRRP interface and restore the legacy (non-compliant) VRRP MAC address behavior.

Use the show form of the command to view VRRP interface configuration.

Note: The default behavior of nonRFC‐compliant MACs is necessary for any environment in which VMware provides Layer 2 services because the vSwitch product does not support true MAC learning and blocks traffic when virtual MAC addresses move ports unless the vSwitch is in promiscuous mode. For the latest product support information, refer to VMware documentation.