VRRP

The Virtual Router ID (VRID) must be configured with the same value on each virtual router associated with the redundant IP addresses. It is placed in all VRRP advertisement messages sent by each virtual router.

The priority value affects the interaction between this VRID and the same VRID of other virtual routers participating on the same LAN. A higher-priority value defines a greater priority in becoming the virtual router master for the VRID. The priority value can only be configured when the defined IP address on the IP interface is different from the virtual router IP address (non-owner mode).

When the IP address on the IP interface matches the virtual router IP address (owner mode), the priority value is fixed at 255, the highest value possible. This virtual router member is considered the owner of the virtual router IP address. There can only be one owner of the virtual router IP address for all virtual router members.

The priority value 0 is reserved for VRRP advertisement message purposes. It is used to tell other virtual routers in the same VRID that this virtual router is no longer acting as master, triggering a new election process. When this happens, each backup virtual router sets its master down timer equal to the skew time value. This shortens the time until one of the backup virtual routers becomes master.

The current master virtual router must transmit a VRRP advertisement message immediately upon receipt of a VRRP message with priority set to 0. This prevents another backup from becoming master for a short period of time.

Non-owner virtual routers may be configured with a priority of 254 through 1. The default value is 100. Multiple non-owners can share the same priority value. When multiple non-owner backup virtual routers are tied (transmit VRRP advertisement messages simultaneously) in the election process, all attempts to become master simultaneously. The one with the best priority wins the election. If the priority value in the message is equal to the master’s local priority value, the primary IP address of the local master and of the message is evaluated as the tie breaker. The higher IP address becomes master. (The primary IP address is the source IP address of the VRRP advertisement message.)

The priority is also used to determine when to preempt the existing master. If the preempt mode value is true, VRRP advertisement messages from inferior (lower- priority) masters are discarded, causing the master down timer to expire and the transition to master state.

The priority value also dictates the skew time added to the master timeout period.

Each virtual router with the same VRID should be defined with the same set of IP addresses. These are the IP addresses being used by hosts on the LAN as gateway addresses. Multinetting supports 16 IP addresses on the IP interface; up to 16 addresses can be assigned to a specific virtual router instance.

Each virtual router is configured with a message interval per VRID within which it participates. This command option must be the same for every virtual router on the VRID.

For IPv4, the default advertisement interval is 1 s and can be configured between 100 ms and 255 s 900 ms. For IPv6, the default advertisement interval is 1 s and can be configured between 100 ms and 40 s 950 ms.

As specified in the RFC, the advertisement interval field in every received VRRP advertisement message must match the locally configured advertisement interval. If a mismatch occurs, depending on the inherit configuration, the current master's advertisement interval setting can be used to operationally override the locally configured advertisement interval setting. If the current master changes, the new master setting is used. If the local virtual router becomes master, the locally configured advertisement interval is enforced.

If a VRRP advertisement message is received with an advertisement interval set to a value different from the local value and the inherit command option is disabled, the message is discarded without processing.

The master virtual router on a VRID uses the advertisement interval to load the advertisement timer, specifying when to send the next VRRP advertisement message. Each backup virtual router on a VRID uses the advertisement interval (with the configured local priority) to determine the master down timer value.

VRRP advertisement messages that are fragmented, or contain IP options (IPv4), or contain extension headers (IPv6) require a longer message interval to be configured.

The skew time is used to add a time period to the master down interval. This is not a configurable command option. It is determined from the current local priority of the virtual router’s VRID. To calculate the skew time, the virtual router evaluates the following formula:

For IPv4: Skew Time equals ((256 - priority) / 256) seconds

For IPv6: Skew Time equals (((256 - priority) * Master_Adver_Interval) / 256) centiseconds

The higher the priority value, the shorter the skew time is. This means that virtual routers with a lower priority transition to master slower than virtual routers with a higher priority.

The master down interval is a calculated value used to load the master down timer. When the master down timer expires, the virtual router enters the master state. To calculate the master down interval, the virtual router evaluates the following formula:

Master Down Interval = (3 ✕ Operational Advertisement Interval) + Skew Time

The operational advertisement interval is dependent upon the state of the inherit command option. When the inherit command option is enabled, the operational advertisement interval is determined from the current master’s advertisement interval field in the VRRP advertisement message. When inherit is disabled, the operational advertisement interval must be equal to the locally configured advertisement interval.

The master down timer is only operational when the local virtual router is operating in backup mode.

Preempt mode is a true or false configured value that controls whether a specific backup virtual router preempts a lower-priority master. The IP address owner always becomes master when available. Preempt mode cannot be set to false on the owner virtual router. The default value for preempt mode is true.

When the preempt mode is true, a master non-owner virtual router only allows itself to be preempted when the incoming VRRP advertisement message priority field value is one of the following:

• Greater than the virtual router in-use priority value

• Equal to the in-use priority value, and the source IP address (primary IP address) is greater than the virtual router instance primary IP address

A backup router only attempts to become the master router if the preempt mode is true and the received VRRP advertisement priority field is less than the virtual router in-use priority value.

The authentication type command option defines the type of authentication used by the virtual router in VRRP advertisement message authentication. VRRP message authentication is applicable to IPv4 only. The current master uses the configured authentication type to indicate any egress message manipulation that must be performed in conjunction with any supporting authentication command options before transmitting a VRRP advertisement message.

The configured authentication type value is transmitted in the message authentication type field with the appropriate authentication data field filled in. Backup routers use the authentication type message field value in interpreting the contained authentication data field within received VRRP advertisement messages.

VRRP supports three message authentication methods that provide varying degrees of security. The supported authentication types are:

• 0 – No Authentication

• 1 – Simple Text Password

• 2 – IP Authentication Header

This feature is different from the VRRP advertisement message field with the same name. This uses any required authentication information that is pertinent to the configured authentication type. The type of authentication data used for each authentication type is described in the following table.

The MAC address can be used instead of an IP address in ARP responses when the virtual router instance is master. The MAC address configuration must be the same for all virtual routers participating as a virtual router, or indeterminate connectivity by the attached IP hosts results. All VRRP advertisement messages are transmitted with ieee-mac-address as the source MAC.

VRRP advertisement messages contain an IP address count field that indicates the number of IP addresses listed in the sequential IP address fields at the end of the message.

The implementation always logs mismatching events. The decision on where and whether to forward the generated messages depends on the configuration of the event manager.

To facilitate the sending of mismatch log messages, each virtual router instance keeps the mismatch state associated with each source IP address in the VRRP master table. Whenever the state changes, a mismatch log message is generated indicating the source IP address within the message, the mismatch or match event, and the time of the event.

With secondary IP address support, multiple IP addresses may be found in the list and should match the IP address on the virtual router instance. Owner and non-owner virtual router instances have the supported IP addresses explicitly defined, making mismatched supported IP address within the interconnected virtual router instances a provisioning issue.

The virtual router instance can inherit the master VRRP router’s advertisement interval timer, which is used by backup routers to calculate the master down timer.

The inheritance is only configurable in the non-owner nodal context. The inheritance is used to allow the current virtual router instance master to dictate the master down timer for all backup virtual routers.

After the 7750 SR or 7950 XRS IPv6 virtual router is configured with a minimum of one link-local backup address, the parent interface’s router advertisement must be configured to use the virtual MAC address for the virtual router to be considered operationally up.

Policies can be configured to control VRRP priority with the virtual router instance. VRRP priority control policies can be used to override or adjust the base priority value, depending on events or conditions within the chassis.

The policy can be associated with more than one virtual router instance. The priority events within the policy override or diminish the base priority dynamically affecting the in-use priority. As priority events clear in the policy, the in-use priority can eventually be restored to the base priority value.

Policies can only be configured in the non-owner VRRP context. For non-owner virtual router instances, if policies are not configured, then the base priority is used as the in-use priority.

Hold-set timers are used to dampen the effect of a flapping event. A flapping event is where the event continually transitions between clear and set. The hold-set value is loaded into a hold-set timer that prevents a set event from transitioning to the cleared state until it expires.

Each time an event transitions from cleared to set, the timer is loaded and begins to count down to zero. If the timer reaches zero, the event is allowed to enter the cleared state again. Entering the cleared state is always dependent on the object controlling the event conforming to the requirements defined in the event. It is possible, on some event types, to have a further set action reload the hold-set timer. This extends the amount of time that must expire before entering the cleared state.

See LAG degrade priority event for an example of a hold-set timer setting.

The port down priority event is assigned to either a physical port or a SONET/SDH channel for the 7750 SR and 7450 ESS. The port or channel operational state is evaluated to determine a port down priority event or event clear.

When the port or channel operational state is up, the port down priority event is considered false or cleared. When the port or channel operational state is down, the port down priority event is considered true or set.

The LAG degrade priority event is tied to an existing LAG. The LAG degrade priority event is conditional on the percentage of available port bandwidth on the LAG. Multiple bandwidth percentage thresholds may be defined, each with its own priority value.

If the LAG transitions from one threshold to the next, the previous threshold priority value is subtracted from the total delta sum while the new threshold priority value is added to the sum. The new sum is then subtracted from the base priority and compared to the delta in-use priority limit to derive the new in-use priority on the virtual router instance.

The following example illustrates a LAG priority event and interaction with the hold- set timer in changing the in-use priority.

The following state and timer settings are used for the LAG events shown in the following table:

• User-defined thresholds: 2 ports down, 4 ports down, 6 ports down

• LAG configured ports: 8 ports

• hold-set timer (hold-set): 5 seconds

The host unreachable priority event creates a continuous ping task that is used to test connectivity to a remote host. The path to the remote host and the remote host must be capable and configured to accept ICMP echo request and replies for the ping to be successful.

The ping task is controlled by interval and size parameters that define how often the ICMP request messages are transmitted and the size of each message. A historical missing reply parameter defines when the ping destination is considered unreachable.

When the host is unreachable, the host unreachable priority event is considered true or set. When the host is reachable, the host unreachable priority event is considered false or cleared.

The route unknown priority event defines a task that monitors the existence of a route prefix in the system routing table.

The route monitoring task can be constrained by a condition that allows a prefix that is less specific than the defined prefix to be considered as a match. The source protocol can be defined to indicate which protocol the installed route must be populated with. To further define match criteria when multiple instances of the route prefix exist, an optional next-hop command option can be defined.

When a route prefix exists within the active route table that matches the defined match criteria, the route unknown priority event is considered false or cleared. When a route prefix does not exist within the active route table that matches the defined criteria, the route unknown priority event is considered true or set.

Configure the lead VRRP instance with timer intervals for the wanted detection time. The key addition is the inclusion of the oper-group command to the configuration. The following example shows the lead VRRP instance configuration.

[ex:/configure router "Base"]
A:admin@node-2# info
    interface "base-1-1" {
        port 1/1/3:1
        ipv6 {
            link-local-address {
                address fe80::1
                duplicate-address-detection false
            }
            address 2500::1 {
                prefix-length 64
                duplicate-address-detection false
            }
            vrrp 1 {
                backup [2500::10 fe80::1:1]
                message-interval 5
                mac 00:00:5e:00:02:01
                priority 130
                ping-reply true
                oper-group "op-v6LI-1"
                bfd-liveness {
                    dest-ip 2000::2
                    service-name "100"
                    interface-name "bfd-1-1"
                }
            }
        }
    }

A:node-2>config>router# info
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
        interface "base-1-1"
            port 1/1/3:1
            ipv6
                address 2500::1/64 dad-disable
                link-local-address fe80::1 dad-disable
                vrrp 1
                    backup 2500::10
                    backup fe80::1:1
                    priority 130
                    ping-reply
                    message-interval 5
                    mac 00:00:5e:00:02:01
                    oper-group "op-v6LI-1"
                    bfd-enable name "100" interface "bfd-1-1" dst-ip 2000::2
                exit
            exit
            no shutdown
        exit
---------------------------------------------

To configure VRRP instances with slower timer intervals include the monitor-oper-group command for MD-CLI and the oper-group command for classic CLI in the configuration. The following example shows VRRP instance configuration with slower timer intervals.

[ex:/configure router "Base"]
A:admin@node-2# interface base-1-2
     interface "base-1-2" {
        port 1/1/3:2
        ipv6 {
            link-local-address {
                address fe80::2
                duplicate-address-detection false
            }
            address 2500:0:1::1 {
                prefix-length 64
                duplicate-address-detection false
            }
            vrrp 1 {
                backup [2500:0:1::10 fe80::1:2]
                message-interval 40
                mac 00:00:5e:00:02:01
                priority 130
                ping-reply true
                monitor-oper-group "op-v6LI-1"
                bfd-liveness {
                    dest-ip 2000::2
                    service-name "100"
                    interface-name "bfd-1-1"
                }
            }
        }
    }

A:node-2>config>router# info
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
        interface "base-1-2"
            port 1/1/3:2
            ipv6
                address 2500:0:1::1 dad-disable
                link-local-address fe80::1 dad-disable
                vrrp 1
                    backup 2500:0:1::10
                    backup fe80::1:2
                    message-interval 40
                    priority 130
                    ping-reply
                    mac 00:00:5e:00:02:01
                    oper-group "op-v6LI-1"
                    bfd-enable name "100" interface "bfd-1-1" dst-ip 2000::2
                exit
            exit
            no shutdown
        exit

Configuring VRRP policies:

VRRP policies must be configured before they can be applied to an interface or IES/VPRN VRRP instance. VRRP policies are configured in the configure vrrp context.

Configuring VRRP on an IES or VPRN service interface:

• The service customer account must be created before configuring an IES or VPRN VRRP instance.

• The interface address must be specified in the both the owner and non-owner IES, VPRN, or router interface instances.

Configuring and applying VRRP policies are optional. There are no default VRRP policies. Each policy must be explicitly defined. A VRRP configuration must include the following:

• policy ID

• at least one of the following priority events:

  • port down

  • LAG port down

  • host unreachable

  • route unknown

[ex:/configure vrrp policy 100]
A:admin@node-2# info
    delta-in-use-limit 50
    priority-event {
        host-unreachable "10.10.24.4" {
            drop-count 25
        }
        lag-port-down "lag-1" {
            number-down 3 {
                priority {
                    priority-level 50
                    event-type explicit
                }
            }
        }
        port-down 4/1/2 {
            hold-set 43200
            priority {
                priority-level 100
                event-type delta
            }
        }
        port-down 4/1/3 {
            priority {
                priority-level 200
                event-type explicit
            }
        }
        route-unknown 10.10.0.0/32 {
            priority {
                priority-level 50
                event-type delta
                }
        }
    }

A:node-2>config>vrrp>policy# info
----------------------------------------------
            delta-in-use-limit 50
            priority-event
                port-down 4/1/2
                    hold-set 43200
                    priority 100 delta
                exit
                port-down 4/1/3
                    priority 200 explicit
                exit
                lag-port-down 1
                    number-down 3
                        priority 50 explicit
                    exit
                exit
                host-unreachable 10.10.24.4
                    drop-count 25
                exit
                route-unknown 10.10.0.0/32
                    priority 50 delta
                    exit
            exit
----------------------------------------------

[ex:/configure vrrp policy 100]
A:admin@node-2# info
    delta-in-use-limit 50
    priority-event {
        host-unreachable "10.10.24.4" {
            drop-count 25
        }
        port-down 4/1/2 {
            hold-set 43200
            priority {
                priority-level 100
                event-type delta
            }
        }
        port-down 4/1/3 {
            priority {
                priority-level 200
                event-type explicit
            }
        }
        route-unknown 10.10.0.0/32 {
            protocol [bgp]
            priority {
                priority-level 50
                event-type delta
            }
        }
    }

A:node-2>config>vrrp>policy# info
----------------------------------------------
            delta-in-use-limit 50
            priority-event
                port-down 4/1/2
                    hold-set 43200
                    priority 100 delta
                exit
                port-down 4/1/3
                    priority 200 explicit
                exit
                lag-port-down 1
                    number-down 3
                        priority 50 explicit
                    exit
                exit
                host-unreachable 10.10.24.4
                    drop-count 25
                exit
                route-unknown 10.10.0.0/32
                    priority 50 delta
                    protocol bgp
                exit
            exit
----------------------------------------------

VRRP command options are configured within an IES service with two contexts: owner or nonowner. The user specifies the status when creating the VRRP configuration. When configured as owner, the virtual router instance owns the backup IP addresses. All other virtual router instances participating in this message domain must have the same VRID configured, and cannot be configured as owner.

SR OS supports passive VRRP, which does not require multiple VRRP instances to achieve default gateway load-balancing. Passive VRRP is a VRRP setting in which the transmission and reception of keepalive messages is completely suppressed; and therefore, the VPRN interface always behaves as the active router. Passive VRRP is enabled by adding the passive keyword to the VRRP instance at creation. For passive VRRP, the convergence time for link or node failures is not affected by the VRRP convergence, as all nodes in the VRRP instance are acting as active routers.

For IPv4, the user can configure up to four VRIDs on an IES service interface, with each of the four VRIDs able to manage up to 16 backup IP addresses. For IPv6, the user can configure four VRIDs on an IES service interface for FP4 cards and later, with each VRID able to manage up to 10 backup IP addresses.

VRRP command options configured within an IES service must include the following:

• VRID

• backup IP addresses

[ex:/configure service ies "1"]
A:ex@node-2# info
    customer "1"
    interface "testing" {
        sap 1/1/55:0 {
        }
        ipv4 {
            primary {
                address 10.10.10.16
                prefix-length 24
            }
            vrrp 12 {
                authentication-key "z1rddawlDRZWzirCADyRv4MfzJVlDQsv hash2"
                backup [10.10.10.15]
                policy 1
            }
        }
    }
    interface "tuesday" {
        sap 7/1/1.2.2 {
        }
        ipv4 {
            primary {
                    address 10.10.36.2
                    prefix-length 24
                }
                vrrp 19 {
                    authentication-key "ungWv48Bz+pBQUDeXa4iI5Jsnw== hash2"
                    backup [10.10.36.2]
                    owner true
                }
            }
        }
    }

A:node-2>config>service# info
----------------------------------------------
...
        ies 1 name "1" customer 1 create
            interface "tuesday" create
                address 10.10.36.2/24
                sap 7/1/1.2.2 create
                vrrp 19 owner
                    backup 10.10.36.2
                    authentication-key "z1rddawlDRZWzirCADyRv4MfzJVlDQsv" hash2
                exit
            exit
            interface "testing" create
                address 10.10.10.16/24
                sap 1/1/55:0 create
                vrrp 12
                    backup 10.10.10.15 
                    policy 1
                    authentication-key "ungWv48Bz+pBQUDeXa4iI5Jsnw==" hash2
                exit
            exit
            no shutdown
----------------------------------------------

VRRP command options are configured on a router interface with two contexts: owner or nonowner. The user specifies the status is specified when creating the VRRP configuration. When configured as owner, the virtual router instance (VRID) owns the backed up IP addresses. All other virtual router instances participating in this message domain must have the same VRID configured and cannot be configured as owner.

SR OS supports passive VRRP, which does not require multiple VRRP instances to achieve default gateway load-balancing. Passive VRRP is a VRRP setting in which the transmission and reception of keepalive messages is completely suppressed; and therefore, the VPRN interface always behaves as the active router. Passive VRRP is enabled by adding the passive keyword to the VRRP instance at creation. For passive VRRP, the convergence time for link or node failures is not affected by the VRRP convergence, as all nodes in the VRRP instance are acting as active routers.

For IPv4, the user can configure up to four VRIDs on a router interface, with each VRID able to manage up to 16 backup IP addresses. For IPv6, the user can configure four VRIDs on a router interface for FP4 cards and later, with each VRID able to manage up to 10 backup IP addresses.

VRRP command options configured on a router interface must include the following:

• VRID

• backup IP addresses

[ex:/configure router "Base"]
A:admin@node-2#
...
    interface "system" {
    ipv4 {
            primary {
                address 10.10.0.4 {
                prefix-length 32
            }
        }
    }
    interface "test1" {
        ipv4 {
            primary {
                address 10.10.14.1
                prefix-length 24
            }
            secondary 10.10.16.1 {
                prefix-length 24
            }
            secondary 10.10.17.1 {
                prefix-length 24
            }
            secondary 10.10.18.1 {
                prefix-length 24
            }
        }
    }
    interface "test2" {
        ipv4 {
            primary {
                address 10.10.10.23
                prefix-length 24
            }
            vrrp 1 {
                authentication-key "V+mMCSI1pnX+5dHDE729xj4E3YCngRQ= hash2"
                backup [10.10.10.23]
                owner true
            }
        }
    }

A:node-2>config>router# info
#------------------------------------------
echo "IP Configuration "
#------------------------------------------
        interface "system"
            address 10.10.0.4/32
        exit
        interface "test1"
            address 10.10.14.1/24
            secondary 10.10.16.1/24
            secondary 10.10.17.1/24
            secondary 10.10.18.1/24
        exit
        interface "test2"
            address 10.10.10.23/24
            vrrp 1 owner
                backup 10.10.10.23
                authentication-key "V+mMCSI1pnX+5dHDE729xj4E3YCngRQ=" hash2
            exit
        exit
#------------------------------------------

If multiple subnets are configured on an Ethernet interface, VRRP can be configured on each subnet.

The following example shows an IP interface configuration.

[ex:/configure router "Base"]
A:admin@node-2# info
    router-id 10.10.0.1
    interface "system" {
    ipv4 {
            primary {
                address 10.10.0.1 {
                prefix-length 32
            }
        }
    }
    interface "testA" {
        ipv4 {
            primary {
                address 10.123.123.123
                prefix-length 24
            }
        }
    }
     interface "testB" {
        ipv4 {
            primary {
                address 10.10.14.1
                prefix-length 24
            }
            secondary 10.10.16.1 {
                prefix-length 24
            }
            secondary 10.10.17.1 {
                prefix-length 24
            }
            secondary 10.10.18.1 {
                prefix-length 24
            }
        }
    }

A:node-2>config>router# info
#------------------------------------------
echo "IP Configuration "
#------------------------------------------
        interface "system"
            address 10.10.0.1/32
        exit
        interface "testA"
            address 10.123.123.123/24
        exit
        interface "testB"
            address 10.10.14.1/24
            secondary 10.10.16.1/24
            secondary 10.10.17.1/24
            secondary 10.10.18.1/24
        exit
        router-id 10.10.0.1
#------------------------------------------

VRRP command options can be configured on an interface in a service to provide virtual default router support, which allows traffic to be routed without relying on a single router in case of failure. VRRP can be configured in the following two ways.

VRRP command options can be configured on an interface in an interface to provide virtual default router support, which allows traffic to be routed without relying on a single router in case of failure. VRRP can be configured in following two ways.

VRRP policies are only applied to non-owner VRRP instances. A VRRP policy cannot be deleted if it is applied to an interface or to an IES service. Each instance in which the policy is applied must be deleted.

Use the following command to show where VRRP policies are applies to an entity.

show vrrp policy

The following example shows where VRRP policies are applied to an entity.

===============================================================================
VRRP Policies
===============================================================================
Policy    Current             Current      Current      Delta Applied Svc
Id        Priority & Effect   Explicit     Delta Sum    Limit         Context
-------------------------------------------------------------------------------
1         200 Explicit        200          100          50          Yes
15        254                 None         None         1           No
32        100                 None         None         1           No
===============================================================================

===============================================================================
VRRP Policies
===============================================================================
Policy    Current             Current      Current      Delta       Applied    
Id        Priority & Effect   Explicit     Delta Sum    Limit                  
-------------------------------------------------------------------------------
1         200 Explicit        200          100          50          Yes
15        254                 None         None         1           No
32        100                 None         None         1           No
===============================================================================

*[ex:/configure vrrp]
A:admin@node-2# delete policy 1

*[ex:/configure vrrp]
A:admin@node-2# commit

*A:node-2>config>vrrp# no policy 1

After a VRRP instance is created as non-owner, it cannot be modified to the owner state. The VRID must be deleted, then recreated with the owner keyword, to invoke IP address ownership.

After a VRRP instance is created as owner, it cannot be modified to the non-owner state. The VRID must be deleted, then recreated without the owner keyword, to remove IP address ownership.

Entering the owner command option is optional when entering the VRID for modification purposes.

The VRID does not need to be shut down to remove the virtual router instance from an interface or service.

Use the following command to remove the virtual router instance:

• MD-CLI

  configure service ies interface ipv4 delete vrrp

• classic CLI

  configure service ies interface vrrp shutdown
  configure service ies interface no vrrp