For feedback and comments:
documentation.feedback@alcatel-lucent.com

Table of Contents Previous Next PDF


OMCR Configuration Commands
oversubscription-domain
Syntax
oversubscription-domain domain-name color 1..10
no oversubscription-domain
Context
configure>service>vprn>sub-if>grp-if>srrp
configure>service>ies>sub-if>grp-if>srrp
Description
This command associates the instance with a domain that groups multiple SRRP instances together for the coloring purposes in case of resource contention. A SRRP instance can belong only to one domain. This command has only effect when multiple SRRP instances whose subscriber hosts contend for the same resources on the central standby node switch at the same or at approximately the same time. An SRRP domain should group SRRP instances that are tied to an oversubscribed IOM or port. Once the multiple failures occur at the same or at approximately the same time, only the subscriber-hosts from SRRP instance with the highest color will be instantiated in the forwarding plane. Subscriber-host instantiation on a SRRP instances with a lower color will not be attempted. This command is designed to prevent partial subscriber-host instantiation and geographical coloring in case of multiple simultaneous failures tied to the same resource (IOM or port) on the central standby node.
The assumption is that partial subscriber host instantiation would be hard to troubleshoot and for that reason, the operator can chose not to recover any subscriber on an SRRP instance in case of a lack of resources in the central standby node.
Note that preemption is not allowed. In other words, once the subscriber host instantiation commence for one SRRP-instance, the other instances cannot preempt the already started process. In case that multiple SRRP instances have the same color, their subscriber host instantiation will be treated equally.
An SRRP instance must be in a shut-down state before it is placed in a domain. However, moving the SRRP instance out of the domain does not require it to be in shut-down state.
Default
No description associated with the configuration context.
Parameters
domain-name
Specifies the name of the domain that groups SRRP instance contending for the same resources.
warm-standby
Syntax
warm-standby
Context
configure>redundancy> multi-chassis>peer
Description
This command enables Oversubscribed Multi-Chassis Redundancy (OMCR) model where subscriber hosts are synchronized between the two chassis only in the control plane and are kept there (as part of the Multi-Chassis Synchronization (MCS) state) until the switchover occurs. Link or nodal failure will trigger the switchover at which point the subscriber hosts are being fully instantiated in the control and the forwarding plane. This approach allows oversubscription of the resources in the central standby (or protecting) node that is backing-up a number of other active nodes. The total number of protected subscribers in the OMCR cluster exceeds the forwarding capacity of the protecting node. This is achievable by not fully occupying the resources for the subscriber hosts until the failure occurs.
The restoration times depend on the amount of the subscriber hosts that are affected by the switchover and it is related to the time needed for the full instantiation of the subscribers in the forwarding plane.
Although this command is configured on a peer level, the warm-standby property is a nodal characteristic. In other words, mixing of N:1 and 1:1 (hot standby) mode in the central standby node is not supported. Consequently all peers on the central standby node must be configured for warm-standby (N:1), or all peers must be configured for hot-standby (1:1) by omitting the warm-standby keyword from the configuration.
The peer of the central-backup node is not aware of the redundancy model supported. In in other words, the peer of the central-backup node does not know whether it peers with a warm-standby peer or host-standby-peer. All nodes participating in this protection model must run SR OS R12.0 or higher.
Default
no warm-standby