This command configures an IPv4 filter ID that are applied to packets egressing the IES R-VPLS interface. The filter overrides existing egress IPv4 filter applied to VPLS service endpoints such as SAPs or SDPs, if configured.

The no form of this command removes the IPv4 routed override filter from the egress IES R-VPLS interface. When removed, egress IPv4 packets will use the IPv4 egress filter applied to the VPLS endpoint, if configured.

This command configures an IPv4 filter ID that is applied to all ingress packets entering the VPLS or I-VPLS service. The filter overrides any existing ingress IPv4 filter applied to SAPs or SDP bindings for packets associated with the routing IP interface. The override filter is optional and when it is not defined or it is removed. The IPv4 routed packets use any existing ingress IPv4 filter on the VPLS virtual port.

The no form of this command removes the IPv4 routed override filter from the ingress IP interface. When removed, the IPv4 ingress routed packets within a VPLS service attached to the IP interface use the IPv4 ingress filter applied to the packets virtual port, when defined.

This command configures an IPv4 filter ID that is applied to packets egressing the VPRN R-VPLS interface. The filter overrides the existing egress IPv4 filter applied to VPLS service endpoints such as SAPs or SDPs, if configured.

The no form of this command removes the IPv4 routed override filter from the egress VPRN R-VPLS interface. When removed, egress IPv4 packets will use the IPv4 egress filter applied to VPLS endpoint, if configured.

This command configures an IPv4 filter ID that is applied to all ingress packets entering the VPLS service. The filter overrides any existing ingress IPv4 filter applied to SAPs or SDP bindings for packets associated with the routing IP interface. The override filter is optional and when it is not defined or it is removed, the IPv4 routed packet’s will use the any existing ingress IPv4 filter on the VPLS virtual port.

The no form of this command removes the IPv4 routed override filter from the ingress IP interface. When removed, the IPv4 ingress routed packets within a VPLS service attached to the IP interface will use the IPv4 ingress filter applied to the packets virtual port, when defined.

This command enables reporting of IPv6 aggregated forwarded octet and packet counters using RADIUS VSAs. Disabled by default. It requires stat-mode v4-v6 for policers and queues for which the IPv6 aggregate forwarded packets should be counted.

The no form of this command reverts to the default.

This command enables and disables the insertion of the fragmentation header in an IPv6 packet when translating non-fragmented IPv4 packet with DF=0. This option is disabled by default and the size of the IPv6 packet is reduced by 8 bytes.

This command configures an IPv6 filter ID that is applied to packets egressing the IES R-VPLS interface. The filter overrides existing egress IPv6 filter applied to VPLS service endpoints such as SAPs or SDPs, if configured.

The no form of this command removes the IPv4 routed override filter from the egress IES R-VPLS interface. When removed, egress IPv6 routed packets uses the IPv6 egress filter applied to VPLS endpoint, if configured

This command configures an IPv6 filter ID that is applied to all ingress packets entering the VPLS or I-VPLS service. The filter overrides any existing ingress IPv6 filter applied to SAPs or SDP bindings for packets associated with the routing IP interface. The override filter is optional and when it is not defined or it is removed, the IPv6 routed packets use any existing ingress IPv6 filter on the VPLS virtual port.

The no v6-routed-override-filter command is used to remove the IPv6 routed override filter from the ingress IP interface. When removed, the IPv6 ingress routed packets within a VPLS service attached to the IP interface will use the IPv6 ingress filter applied to the packet’s virtual port, when defined.

This command configures an IPv6 filter ID that is applied to packets egressing the VPRN R-VPLS interface. The filter overrides existing egress IPv6 filter applied to VPLS service endpoints such as SAPs or SDPs, if configured.

The no form of the command removes the IPv4 routed override filter from the egress VPRN R-VPLS interface. When removed, egress IPv6 packets will use the IPv6 egress filter applied to the VPLS endpoint, if configured.

This command configures an IPv6 filter ID that is applied to all ingress packets entering the VPLS service. The filter overrides any existing ingress IPv6 filter applied to SAPs or SDP bindings for packets associated with the routing IP interface. The override filter is optional and when it is not defined or it is removed, the IPv6 routed packets use the any existing ingress IPv6 filter on the VPLS virtual port.

The no form of the command removes the IPv6 routed override filter from the ingress IP interface. When removed, the IPv6 ingress routed packets within a VPLS service attached to the IP interface uses the IPv6 ingress filter applied to the packet’s virtual port, when defined.

This command configures the DHCPv6 lease split valid lifetime (short lease time). DHCPv6 lease split is active when enabled and for all IA_NA and IA_PD options in the transaction the configured lease split valid lifetime (short lease time) is less than or equal to the renew time T1 committed by the server (long renew time) or 50 percent of the preferred lifetime committed by the server when T1 committed by the server equals zero.

The no form of this command reverts to the default value.

This command configured valid-lifetime for DHCPv6 lease (address/prefix).

The valid lifetime is the length of time an address/prefix remains in the valid state (for example, the time until invalidation). The valid lifetime must be greater than or equal to the preferred lifetime. When the valid lifetime expires, the address/prefix becomes invalid and must not be used in communications. RFC 2461, sec 6.2.1 recommends default value of 30 days.

Each address/prefix assigned to the client has associated preferred and valid lifetimes specified by the address assignment authority (DHCP server, RADIUS, ESM). To request an extension of the lifetimes assigned to an address, the client sends a Renew message to the addressing authority. The addressing authority sends a Reply message to the client with the new lifetimes, allowing the client to continue to use the address/prefix without interruption.

The lifetimes are transmitted from the addressing authority to the client in the IA option on the top level (not the address or prefix level).

The no form of this command reverts to the default.

This command configures the valid lifetime for the IPv6 prefix or address in the option.

The no form of this command reverts to the default.

This command configures the valid lifetime.

The no form of this command reverts to the default.

This command specifies the time for this prefix to remain valid.

The no form of this command reverts to the default.

This command configures the time, in seconds, that the prefix is valid.

The no form of this command reverts to the default value.

This command specifies the remaining time for this prefix to be valid for the purpose of on-link determination.

The no form of this command reverts to the default.

This command specifies the length of time in seconds that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity.

The address generated from an invalidated prefix should not appear as the destination or source address of a packet.

This command specifies the length of time in seconds that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity.

The address generated from an invalidated prefix should not appear as the destination or source address of a packet.

This command performs a validation on the license file pointed to by the command line argument. A validation ensures that the license is compatible with the current state of the target system but it does not change the existing license. Aspects that can cause a failure in the validation include:

Note: If the CLM tool is being used for license management, it shall perform the validation and activation and there is no need to enter these commands manually.

This command enables the NETCONF validate operation.

The no form of this command disables the operation.

This command enables or disables validation of received IPv4 and IPv6 FlowSpec routes that contain a destination-prefix subcomponent.

A FlowSpec route with a destination-prefix subcomponent is considered invalid if both of the following are true:

An invalid route is retained in the BGP but it is not used for filtering traffic or propagated to other BGP routers.

The no form of this command disables the validation procedure based on destination-prefix.

This command enables or disables validation of received IPv4 and IPv6 FlowSpec routes that contain a destination-prefix subcomponent.

A FlowSpec route with a destination-prefix subcomponent is considered invalid if both of the following are true:

An invalid route is retained in the BGP but it is not used for filtering traffic or propagated to other BGP routers.

The no form of this command disables the validation procedure based on destination-prefix.

This command configures a TCA for the counter capturing drops due to the validation of GTP tunnel check. A validate-gtp-tunnels drop TCA can be created for traffic generated from the subscriber side of AA (from-sub) or for traffic generated from the network toward the AA subscriber (to-sub). The create keyword is mandatory when creating a validate-gtp-tunnels TCA.

This command configures GTP tunnel validation. This allows for validation of TEIDs and is a prerequisite for sequence checking and UE IP address validation. This command applies only when AA GTP FW is deployed on S8/S5/Gp/Gn interfaces.

The gtpc-inspection command must be enabled before using this command.

The no form of this command disables GTP tunnel validation.

This optional command tracks the state of the next hop in the IPv4 ARP cache or IPv6 Neighbor Cache. When the next hop is not reachable and is removed from the ARP or Neighbor Cache, the next hop will no longer be considered valid and the associated static route state removed from the active route-table.

When the next hop is reachable again and present in the ARP/Neighbor Cache, the static route is considered valid and is subject to being placed into the active route-table.

This optional command tracks the state of the next-hop in the IPv4 ARP cache or IPv6 Neighbor Cache. When the next-hop is not reachable and is removed from the ARP or Neighbor Cache, the next-hop will no longer be considered valid and the associated static-route state removed from the active route-table.

When the next-hop is reachable again and present in the ARP/Neighbor Cache, the static route is considered valid and is subject to being placed into the active route-table.

This command enables procedures to validate the redirect-to-IPv4 action attached to FlowSpec-IPv4 routes received by the BGP instance.

The SR OS FlowSpec implementation supports the redirect-to-IPv4 action encoded as an IPv4-address-specific BGP extended community.

When this command is configured, a FlowSpec-IPv4 route is considered invalid and not installed as a filter rule if the FlowSpec-IPv4 route is deemed to have originated in a different AS than the IP route that resolves the redirection IPv4 address. The originating AS of a flow-spec route is determined from its AS path.

The no form of this command disables the check described above.

This command enables procedures to validate the redirect-to-IPv4 action attached to FlowSpec IPv4 routes received by the BGP instance.

The SR OS FlowSpec implementation supports the redirect-to-IPv4 action encoded as an IPv4-address-specific BGP extended community.

When this command is configured, a FlowSpec IPv4 route is considered invalid and not installed as a filter rule if the FlowSpec IPv4 route is deemed to have originated in a different AS than the IP route that resolves the redirection IPv4 address. The originating AS of a FlowSpec route is determined from its AS path.

The no form of this command disables the check described above.

This command configures a TCA for the counter capturing drops due to the GTP filter invalid GTP sequence number. A validate-sequence-number drop TCA can be created for traffic generated from the subscriber side of AA (from-sub) or for traffic generated from the network toward the AA subscriber (to-sub). The create keyword is mandatory when creating a validate-sequence-number TCA.

This command configures GTP sequence number checking. GTP packets that fail the sequence number check are discarded.

The validate-gtp-tunnels command must be enabled before using this command.

The no form of this command disables GTP sequence number checking.

This command configures the checking for spoofed or invalid UE IP addresses. Upstream GTP packets that contain invalid UE IP addresses are discarded. When a packet is dropped due to source-ip-address “invalid source IP add”, the statistics counter is updated.

The validate-gtp-tunnels command must be enabled before using this command.

The no form of this command disables the checking for spoofed or invalid UE IP addresses.

This command configures a TCA for the counter capturing drops due to the GTP filter anti-spoofing of the UE IP address check. A validate-src-ip-addr drop TCA can be created for traffic generated from the subscriber side of AA (from-sub). The create keyword is mandatory when creating a validate-src-ip-addr TCA.

This command configures the validity time for the interim credit allocated to rating groups of a Diameter Gy session when Extended Failure Handling (EFH) is active. When either the allocated interim credit is consumed or the validity time expires, a new attempt is made to establish a Diameter Gy session with the Online Charging Server (OCS).The validity time applies to all interim credit allocated via the config>subscr-mgmt>diam-appl-plcy application-policy-name>gy>extended-failure-handling>interim-credit>volume and config>subscr -mgmt>category-map category-map-name>category category-name>default-credit CLI commands.

A validity time value of 0 (zero) disables the validity time for the assigned interim credit.

The no form of this command resets the value to the default value.

This command modifies the default preference value used for the PE in the ES. An ES shutdown is not required to modify this value during maintenance operations.

This command configures a characteristic value.

The no form of this command removes the value for the characteristic.

This command configures the default preference option value. A DHCPv6 preference option with specified value is inserted in the DHCPv6 advertise message for DHCPv6 clients for which no per DHCPv6 server or per client-mac solicit delay or preference option value is configured.

The no form of this command removes the configuration.

This command configures the preference option value for DHCPv6 clients with an odd or an even source MAC address. A DHCPv6 preference option with specified value is inserted in the DHCPv6 advertise message for these DHCPv6 clients.

The no form of this command removes the configuration.

This command configures the preference option value. A DHCPv6 preference option with specified value is inserted in the DHCPv6 advertise message from the server.

The no form of this command removes the configuration.

This command configures a Value Added Service filter.

The no form of this command removes the VAS filter name from the configuration.

This command configures the type of a Value Added Service (VAS) facing interface. To change the vas-if-type, the shutdown command is required. The vas-if-type and loopback commands are mutually exclusive.

The no form of this command removes the VAS interface type configuration.

This command configures the type of a Value Added Service (VAS) facing interface. To change the vas-if-type, the shutdown command is required. The vas-if-type and loopback commands are mutually exclusive.

The no form of this command removes the VAS interface type configuration.

This command configures the type of a Value Added Service (VAS) facing interface. To change the vas-if-type, the shutdown command is required. The vas-if-type and loopback commands are mutually exclusive.

The no form of this command removes the VAS interface type configuration.

This command specifies the VC-ID for the L2TPv3 session.

The no form of this command deletes the VC-ID configuration.

This command determines the VC-IDs associated with the virtual Ethernet Segment on a specific SDP based on the following considerations:

The no form of the command removes the configured range. Only the first VC-ID value is required to remove the range.

This command configures the egress VC label.

This command configures the ingress VC label.

This command configures the static MPLS VC label used by this device to send packets to the far-end device in this service via this SDP.

This command configures the static MPLS VC label used by the far-end device to send packets to this device in this service via this SDP.

This command configures the egress and ingress VC label.

The actual maximum value that can be configured is limited by the config>router>mpls-labels>static-label-range command.

This command configures the egress and ingress VC label.

The no version of this command removes the VC label.

This command configures the egress and ingress VC label.

The no version of this command removes the VC label.

This command configures the spoke SDP egress VC label.

The no form of this command removes the egress VC label value from the configuration.

This command configures the spoke SDP ingress VC label.

This command configures the egress VC label for the PW representing the PW-port.

This command configures the ingress VC label used for the PW representing the PW port.

Note that the maximum value of the vc-label that may be configured is limited by the config>router>mpls-labels>static-label-range command.

This command configures ATM Virtual Circuit ranges and is supported only in max16k-vc ATM MDA mode. An ATM MDA supports a number of passive (or listening) VCs, of which a subset can be simultaneously active.

The no form of this command reverts to the default.

This command configures the ATM port VC threshold.

This command sets the forwarding mode for the pseudowire port. The vc-type is signaled to the peer, and must be configured consistently on both ends of the pseudowire. vc-type VLAN is only configurable with dot1q encapsulation on the pseudowire port. The tag with vc-type vlan only has significance for transport, and is not used for service delineation or ESM. The top (provider tag) is stripped while forwarding out of the pseudowire, and a configured vlan-tag (for vc-type vlan) is inserted when forwarding into the pseudowire. With vc-type ether, the tags if present (max 2), are transparently preserved when forwarding in our out of the pseudowire.

The no form of the command reverts to the default value.

This command overrides the default VC type signaled for the binding to the far end SDP. The VC type is a 15 bit-quantity containing a value which represents the type of VC. The actual signaling of the VC type depends on the signaling parameter defined for the SDP. If signaling is disabled, the vc-type command can still be used to define the dot1q value expected by the far-end provider equipment. A change of the bindings VC type causes the binding to signal the new VC type to the far end when signaling is enabled. VC types are derived according to IETF draft-martini-l2circuit-trans-mpls.

This command configures a Virtual Circuit Connectivity Verification (VCCV) ping test. A vccv-ping test checks connectivity of a VLL inband. It checks to verify that the destination (target) PE is the egress for the Layer 2 FEC. It provides for a cross-check between the dataplane and the control plane. It is inband which means that the vccv-ping message is sent using the same encapsulation and along the same path as user packets in that VLL. The vccv-ping test is the equivalent of the lsp-ping test for a VLL service. The vccv-ping reuses an lsp-ping message format and can be used to test a VLL configured over both an MPLS and a GRE SDP.

Note that VCCV ping can be initiated on T-PE or S-PE. If initiated on the S-PE, the reply-mode parameter must be used with the ip-routed value The ping from the T-PE can have either values or can be omitted, in which case the default value is used.

If a VCCV ping is initiated from T-PE to neighboring a S-PE (one segment only), then it is sufficient to only use the spoke-sdp-fec-id parameter. However, if the ping is across two or more segments, at least the spoke-sdp-fec-id, src-ip-address ip-addr, dst-ip-address ip-addr, ttl vc-label-ttl parameters are used where:

Note that VCCV ping is a multi-segment pseudowire. For a single-hop pseudowire, only the peer VCCV CC bit of the control word is advertised when the control word is enabled on the pseudowire.

VCCV ping on multi-segment pseudowires require that the control word be enabled in all segments of the VLL. If the control word is not enabled on a spoke SDP, it is signaled peer VCCV CC bits to the far end, consequently the vccv-ping cannot be successfully initiated on that specific spoke SDP.

If the saii-type-2 and taii-type-2 parameters are specified by the user of this command for a FEC129 pseudowire, then these values are used by the vccv-ping echo request message instead of the saii and taii of the spoke-sdp indexed by the spoke-sdp-fec parameter, or any saii and taii received in a switching point TLV for the pseudowire. Furthermore, the user must enter the saii and taii in accordance with the direction of the pseudowire as seen from the node on which the vccv-ping command is executed. However, the values of the saii and taii sent in the echo request message are swapped with respect to the user-entered values to match the order in the installed FEC on the targeted node. The output of the command for FEC129 type 2 pseudowire reflects the order of the saii and taii stored on the targeted node.

This command, when used with the static option, configures a Virtual Circuit Connectivity Verification (VCCV) ping test for static MPLS-TP pseudowires used in a VLL service. It checks to verify that the destination (target) PE is the egress for the Static PW FEC. It provides for a cross-check between the dataplane and the configuration. The vccv-ping static command reuses an lsp-ping message format and can be used to test an MPLS-TP pseudowire VLL configured over an MPLS SDP. VCCV Ping for MPLS-TP pseudowires always uses the VCCV control word (associated channel header) with either an IPv4 channel type (0x0021) or on-demand CV message channel type (0x0025).

Note that vccv-ping static can only be initiated on a T-PE. Both the echo request and reply messages are send using the same, in-band, encapsulation. If the target-fec-type option is not specified, then the target FEC stack contains a static PW FEC TLV. The contents of this TLV are populated based on the source node ID, source global ID, and destination global ID and destination node ID in the vccv-ping command (or taken from the pseudowire context if omitted from the command).

The target-fec-type option allows the user to test a segment of a MS-PW that does not have the same FEC type as the local segment from the T-PE where the vccv-ping command is issued. This is applicable for performing VCCV ping on an MS-PW comprised of static PW FEC segments and dynamically signaled PW ID FEC segments.

The timestamp format to be sent, and to be expected when received in a PDU, is as configured by the config>test-oam>mpls-time-stamp-format command. If RFC 4379 (obsoleted by RFC 8029) is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.

This command configures a Virtual Circuit Connectivity Verification (VCCV) automated trace test. The automated VCCV-trace can trace the entire path of a PW with a single command issued at the T-PE or at an S-PE. This is equivalent to LSP-Trace and is an iterative process by which the source T-PE or S-PE node sends successive VCCV-Ping messages with incrementing the TTL value, starting from TTL=1. In each iteration, the T-PE builds the MPLS echo request message in a way like VCCV-Ping. The first message with TTL=1 has the next-hop S-PE T-LDP session source address in the Remote PE Address field in the PW FEC TLV. Each S-PE which terminates and processes the message includes in the MPLS echo reply message the FEC 128 TLV corresponding the PW segment to its downstream node. The source T-PE or S-PE node can then build the next echo reply message with TTL=2 to test the next-next hop for the MS-PW. It copies the FEC TLV it received in the echo reply message into the new echo request message. The process is terminated when the reply is from the egress T-PE or when a time out occurs.

The user can specify to display the result of the VCCV-trace for a fewer number of PW segments of the end-to-end MS-PW path. In this case, the min-ttl and max-ttl parameters are configured accordingly. However, the T-PE/S-PE node still probes all hops up to min-ttl to correctly build the FEC of the desired subset of segments.

Note that if the saii-type-2 and taii-type-2 parameters are specified this command for a FEC129 pseudowire, then these values are used by the vccv-ping echo request message instead of the saii and taii of the spoke SDP indexed by the spoke-sdp-fec parameter, or any saii and taii received in a switching point TLV for the pseudowire. Furthermore, the use must enter the saii and taii in accordance with the direction of pseudowire as seen from the node on which the vccv-trace command is executed. However, the values of the saii and taii sent in the echo request message are swapped with respect to the user-entered values to match the order in the installed FEC on the targeted node. The output of the command for a FEC129 type 2 pseudowire reflects the order of the saii and taii stored on the targeted node.

This command, when used with the static option, configures a VCCV-automated trace test for static MPLS-TP pseudowires used in a VLL service. VCCV trace for MPLS-TP pseudowires always uses the VCCV control word (associated channel header) with either an IPv4 channel type (0x0021) or on-demand CV message channel type (0x0025).

Note that vccv-trace static can only be initiated on a T-PE. Both the echo request and reply messages are send using the same, in-band, encapsulation. The target FEC stack contains a static PW FEC TLV. The contents of this TLV are populated based on the source Node ID, source global ID, and destination global ID and destination node ID taken from the pseudowire context.

The target-fec-type option allows the user to perform a vccv-trace to a segment of a MS-PW that does not have the same FEC type as the local segment from the T-PE where the vccv-trace command is issued. This is applicable for performing VCCV ping on an MS-PW comprised of static PW FEC segments and dynamically signaled PW ID FEC segments.

This command configures a ve-id for either the local VPWS instance when configured under the ve-name, or for the remote VPWS instance when configured under the remote-ve-name.

A single ve-id can be configured per ve-name or remote-ve-name. The ve-id can be changed without shutting down the VPWS instance. When the ve-name ve-id changes, BGP withdraws the previously advertised route and sends a route-refresh to all the peers which would result in reception of all the remote routes again. The old PWs are removed and new ones are instantiated for the new ve-id value.

When the remote-ve-name ve-id changes, BGP withdraws the previously advertised route and send a new update matching the new ve-id. The old pseudowires are removed and new ones are instantiated for the new ve-id value.

NLRIs received whose advertised ve-id does not match the list of ve-ids configured under the remote ve-id will not have a spoke SDP binding auto-created but will remain in the BGP routing table but not in the Layer 2 route table. A change in the locally configured ve-ids may result in auto-sdp-bindings either being deleted or created, based on the new matching results.

Each ve-id configured within a service must be unique.

The no form of this command removes the configured ve-id. It can be used just when the BGP VPWS status is shutdown. The no shutdown command cannot be used if there is no ve-id configured.

This command configures a ve-id. Just one ve-id can be configured per BGP VPLS instance. The VE-ID can be changed without shutting down the VPLS Instance. When the VE-ID changes, BGP is withdrawing its own previously advertised routes and sending a route-refresh to all the peers which would result in reception of all the remote routes again. The old pseudowires are removed and new ones are instantiated for the new VE-ID value.

The no form of this command removes the configured ve-id. It can be used just when the BGP VPLS status is shutdown. The no shutdown command cannot be used if there is no ve-id configured.

This command configures the name of the local VPWS instance in this service.

The no form of this command removes the ve-name.

This command creates or edits a ve-name. Just one ve-name can be created per BGP VPLS instance.

The no form of this command removes the configured ve-name from the bgp vpls node. It can be used only when the BGP VPLS status is shutdown. The no shutdown command cannot be used if there is no ve-name configured.

This command configures the vendor ID to be advertised.

The no form of this command reverts to the default value.

This command enables the Nokia vendor-specific sub-option of the DHCP relay packet.

The no form of this command reverts to the default.

This command configures the Nokia vendor specific suboption of the DHCP relay packet.

In a diameter peer policy, this command specifies the vendor support announced in the capability exchange. In a Gy diameter application policy, this command specifies the vendor specific attributes for the user sessions.

The no form of this command reverts to the default value.

This command configures the version of IGMP.

The no form of this command reverts to the default value.

This command specifies the version of IGMP which is running on an MSAP. This object can be used to configure a router capable of running either value. For IGMP to function correctly, all routers on a LAN must be configured to run the same version of IGMP on that LAN.

When the send-query command is configured, all type of queries generated are of the configured version. If a report of a version higher than the configured version is received, the report gets dropped and a new “wrong version” counter is incremented.

If the send-query command is not configured, the version command has no effect. The version used on that SAP or SDP is the version of the querier. This implies that, for example, when there is a v2 querier, a v3 group or group-source specific query when a host wants to leave a certain group will never be sent.

This command configures the MLD version.

The no form of this command reverts to the default.

This command configure the protocol version that is expected by the WPP portal.

The no form of this command reverts to the default.

This command configures the IMA version for the multilink bundle group. If there is a version mismatch between this IMA group and the far end IMA group, the IMA group becomes operationally down. Automatic version changing is not supported. To change the IMA version, all member links must be removed from the group first.

This command specifies the version of IGMP or MLD which is running on this SAP or SDP. This object can be used to configure a router capable of running either value. For IGMP or MLD to function correctly, all routers on a LAN must be configured to run the same version of IGMP or MLD on that LAN.

When the send-query command is configured, all type of queries generate ourselves are of the configured version. If a report of a version higher than the configured version is received, the report gets dropped and a new “wrong version” counter is incremented.

If the send-query command is not configured, the version command has no effect. The version used on that SAP or SDP is the version of the querier. This implies that, for example, when there is a v2 querier, a v3 group or group-source specific query when a host wants to leave a certain group will never be sent.

This command configures the version of IGMP.

The no form of this command removes the version.

This command specifies the IGMP version. If routers run different versions of IGMP, they will negotiate the lowest common version of IGMP that is supported by hosts on their subnet and operate in that version. For IGMP to function correctly, all routers on a LAN should be configured to run the same version of IGMP on that LAN.

For IGMPv3, a multicast router that is also a group member performs both parts of IGMPv3, receiving and responding to its own IGMP message transmissions as well as those of its neighbors.

This command specifies the MLD version. If routers run different versions, they will negotiate the lowest common version of MLD that is supported by hosts on their subnet and operate in that version. For MLD to function correctly, all routers on a LAN should be configured to run the same version of MLD on that LAN.

This command configures the accepted protocol version range.

This command specifies the IGMP version. If routers run different versions of IGMP, they will negotiate the lowest common version of IGMP that is supported by hosts on their subnet and operate in that version. For IGMP to function correctly, all routers on a LAN should be configured to run the same version of IGMP on that LAN.

For IGMPv3, a multicast router that is also a group member performs both parts of IGMPv3, receiving and responding to its own IGMP message transmissions as well as those of its neighbors.

This command specifies the MLD version. If routers run different versions of MLD, they will negotiate the lowest common version of MLD that is supported by hosts on their subnet and operate in that version. For MLD to function correctly, all routers on a LAN should be configured to run the same version of MLD on that LAN.

This command specifies the version of IGMP. This object can be used to configure a router capable of running either value. For IGMP to function correctly, all routers on a LAN must be configured to run the same version of IGMP on that LAN.

When the send-query command is configured, all type of queries generated are of the configured version. If a report of a version higher than the configured version is received, the report gets dropped and a new “wrong version” counter is incremented.

If the send-query command is not configured, the version command has no effect. The version used on that SAP or SDP is the version of the querier. This implies that, for example, when there is a v2 querier, a v3 group or group-source specific query when a host wants to leave a certain group will never be sent.

This command displays the version of an SR OS *.tim image file.

This command configures the SSH protocol version that is supported by the SSH server.

The no form of this command removes the SSH version from the configuration.

Edit files using the vi editor. For more information, refer to “VI Editor” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Basic System Configuration Guide.

This command configures the analyzer to check for a VID PID within the specified time interval.

Commands in this context configure video parameters.

This command configures an ISA video group.

This command assigns a video group ID to the channel.

This command creates a video interface policy context that correlates to the IP address assigned for a video interface. This interface is created in a subscriber service to which the multicast information policy is assigned. If the specified IP address does not correlate to a video interface ip address, the parameters defined within this context have no effect.

The no form of the command deletes the video interface policy context.

This command creates a video interface within the service. The video interface and associated IP addresses are the addresses to which clients within the service will send requests. The video interface must be associated with an ISA group using the video-sap command and have IP addresses for it to be functional.

The no form of the command deletes the video interface. The video interface must be administratively shut down before issuing the no video-interface command.

This command enables debugging for video interfaces.

The no form of the command disables the video interface debugging.

Commands in this context configure video interfaces and video services.

This command configures a service video interface association with a video group.

The no form of the command removes the video group association.

Commands in this context configure the video template for cflowd fields.

This command displays the candidate configuration along with line numbers that can be used for editing the candidate configuration.

This command displays the checkpoint.

The context to configure administrative system viewing parameters. Only authorized users can execute the commands in the admin context.

This command configures a view. Views control the accessibility of a MIB object within the configured MIB view and subtree. Object identifiers (OIDs) uniquely identify MIB objects in the subtree. OIDs are organized hierarchically with specific values assigned by different organizations.

Once the subtree (OID) is identified, a mask can be created to select the portions of the subtree to be included or excluded for access using this particular view. See the mask command.

The view(s) configured with this command can subsequently be used in read, write, and notify commands which are used to assign specific access group permissions to created views and assigned to particular access groups.

Multiple subtrees can be added or removed from a view name to tailor a view to the requirements of the user access group.

A subtree statement matches (covers) any OID that is a descendant of the specified OID value. For example, the subtree 1.3.6.1 matches 1.3.6.1.x (for any value of x), 1.3.6.1.x.y (for any values of x & y), and so on.

Subtrees that are not covered by view statements are not accessible in the view.

Per RFC 2575, View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP), each MIB view is defined by two sets of view subtrees, the included view subtrees, and the excluded view subtrees (see the included and excluded parameters of the mask command). Every such view subtree, both the included and the excluded ones, are defined in this table. To determine if a particular object instance is in a particular MIB view, compare the object instance’s OID with each of the MIB view’s active entries in this table. If none match, then the object instance is not in the MIB view. If one or more match, then the object instance is included in, or excluded from, the MIB view according to the value of vacmViewTreeFamilyType in the entry whose value of vacmViewTreeFamilySubtree has the most sub-identifiers.

The no view view-name command removes a view and all subtrees.

The no view view-name subtree oid-value removes a sub-tree from the view name.

This command specifies a virtual chassis identifier that can link two wlan-gws together.

The no form of this command removes the dual-homing-key.

This command configures a virtual link to connect area border routers to the backbone via a virtual link.

The router-id specified in this command must be associated with the virtual neighbor. The transit area cannot be a stub area or a Not So Stubby Area (NSSA).

The no form of this command deletes the virtual link.

This command configures a virtual link to connect area border routers to the backbone via a virtual link.

The router-id specified in this command must be associated with the virtual neighbor. The transit area cannot be a stub area or a Not So Stubby Area (NSSA).

The no form of this command deletes the virtual link.

By default, no virtual link is defined.

This command enables debugging for an OSPF virtual neighbor.

Commands in this context configure the virtual scheduler processing on the card. This is only applicable to queues and to policers parented to a scheduler.

This command enables a virtual-subnet for DHCPv4 hosts under the subscriber interface. With this command configured, the system will snoop and record the default router address in the DHCP ACK message for the DHCPv4 ESM host. The system could answer ping or traceroute request even if the default router address is not configured on the subscriber-interface.

The no form of this command reverts to the default.

This command specifies the VLAN tag of the SAP used for ring-node connectivity verification of this ring node. It is only meaningful if the value of is not zero.

The no form of this command reverts to the default.

This command enables matching on UEs, based on the VLAN tag within the tunnel, which typically used to indicate an SSID.

The no form of this command disables matching on the VLAN.

This command creates a mapping from a range of VLANs (appearing in the wlan-gw encapsulated Layer 2 frame) to a retail service ID.

The no form of this command removes the parameters from the configuration.

This command specifies the VLAN tag used for the Ring-node Connectivity Verification of this ring node. It is only meaningful if the value of service ID is not zero. A zero value means that no VLAN tag is configured.

This command configures the bridge identifier primary VLAN ID. This is informational only, and no verification is done to ensure MEPs on this association are on the configured VLAN.

The no form of this command reverts to the default value.

This command configures the service port VLAN ID to be used by application assurance to inject the syslog events inband. This VLAN ID needs also to be configured for application assurance interface.

This command configures the VLAN ID for captive redirect. Captive redirect uses the provisioned VLAN ID to send the HTTP response to subscribers; therefore this VLAN ID must be properly assigned in the same VPN as the subscriber.

This command configures the VLAN ID on which the ISA-AA is expected to be emitting traffic mapping to a pre-configured aa-interface.

This command configures the VLAN ID on which the AA ISA emits the traffic mapping to a preconfigured AA interface.

The no form of this command removes the VLAN ID configuration.

This command defines the Dot1Q VLAN ID to be used in the test Dot1Q header.

The no form of this command removes the VLAN ID value.

This command configures the VLAN ID on which the ISA-AA is expected to be emitting traffic.

The no form of this command removes the VLAN ID from the configuration.

This command configures the timeout value for the RADIUS proxy cache if a packet is received with a non-matching VLAN tag. The new timeout value is the lesser of the vlan-mismatch-timeout value and the currently remaining proxy cache timeout value.

The no form of this command disables the timeout behavior. The cache timeout value will remain unchanged.

This command specifies a range of VLANs associated with a certain mst-instance. This range applies to all SAPs of the M-VPLS.

Every VLAN range that is not assigned within any of the created config>service>vpls>stp mst-instance is automatically assigned to mst-instance 0. This instance is automatically maintained by the software and cannot be modified. Changing the VLAN range value can be performed only when the specified mst-instance is shutdown.

The no form of this command removes the vlan-range from the specified config>service>vpls>stp mst-instance.

This command allows the user to configure different ranges in the connection-profile-vlan. The ranges have the following characteristics:

Each connection-profile-vlan must be explicitly configured.

Commands in this context configure VLAN-to-retail-map parameters to map dot1q tags to the retail service ID. The WIFI AP inserts a dot1Q tag in the Layer 2 frame within the GRE tunnel to indicate the retail service provider for the subscriber.

This command configures ingress VLAN translation. If enabled with an explicit VLAN value, the preserved VLAN ID is overwritten with this value. This setting is applicable to dot1q encapsulated ports. If enabled with the copy-outer keyword, the outer VLAN ID is copied to inner position on QinQ encapsulated ports. The feature is not supported on:

The no version of the command disables VLAN translation.

This command configures the VLAN VC EtherType.

The no form of this command returns the value to the default.

This command specifies an explicit dot1q value used when encapsulating to the SDP far end. When signaling is enabled between the near and far end, the configured dot1q tag can be overridden by a received TLV specifying the dot1q value expected by the far end. This signaled value must be stored as the remote signaled dot1q value for the binding. The provisioned local dot1q tag must be stored as the administrative dot1q value for the binding.

When the dot1q tag is not defined, the default value of zero is stored as the administrative dot1q value. Setting the value to zero is equivalent to not specifying the value.

The no form of this command disables the command.

This command sets tag relevant for vc-type vlan mode. This tag is inserted in traffic forwarded into the pseudowire.

The no form of the command reverts to the default value.

This command specifies an explicit dot1q value used when encapsulating to the SDP far end. When signaling is enabled between the near and far end, the configured dot1q tag can be overridden by a received TLV specifying the dot1q value expected by the far end. This signaled value must be stored as the remote signaled dot1q value for the binding. The provisioned local dot1q tag must be stored as the administrative dot1q value for the binding.

When the dot1q tag is not defined, the default value of zero is stored as the administrative dot1q value. Setting the value to zero is equivalent to not specifying the value.

The no form of this command disables the command.

This command specifies an explicit dot1q value used when encapsulating to the SDP far end. When signaling is enabled between the near and far end, the configured dot1q tag can be overridden by a received TLV specifying the dot1q value expected by the far end. This signaled value must be stored as the remote signaled dot1q value for the binding. The provisioned local dot1q tag must be stored as the administrative dot1q value for the binding.

When the dot1q tag is not defined, the default value of zero is stored as the administrative dot1q value. Setting the value to zero is equivalent to not specifying the value.

The no form of this command disables the command.

This command configures or creates an ESA-VM instance.

The no form of this command removes the ESA-VM from the system.

This command enables the distribution of packets by IP address across virtual CPUs of a data plane VM. This allows support for AA subscribers whose bandwidth exceeds the processing throughput of a single vCPU.

The no form of this command enables traffic distribution by AA subscriber.

This command configures AA in VSR mode to load-balance traffic across different VM cores using TEID. Load-balancing is required when VSR is deployed on 3GPP S5/S8 (Gn/Gp) interfaces to provide GTP firewalling.

The no form of this command disables load-balancing of the traffic across the VM cores.

This command configures the type of ESA-VM instance.

The no form of this command removes the specified VM type.

Suppress eth-cfm PDUs based on level lower than or equal to configured Virtual MEP. This command is not supported under a B-VPLS context. This will also delete any MIP configured on the SAP or Spoke-SDP.

The no form of this command reverts to the default values.

Commands in this context configure the voice template for cflowd fields.

This command configures the default volume interim credit that is allocated to all rating groups of a Diameter Gy session when Extended Failure Handling (EFH) is active and for which no default credit is configured at the category map category level.

The no form of this command resets the value to the default value.

This command configures the cflowd volume export.

This command specifies whether volume quota is applied in the egress (downstream), ingress (upstream), or both directions. Configuration changes apply only to new DSM UEs and not to existing UEs.

This command enables the reporting of Layer 3 (IP) based subscriber host volume accounting data.

By default, subscriber host volume accounting data includes Layer 2 header octets and can be configured to include a fixed packet byte offset or last-mile encapsulation overhead.

The no form of this command reverts to the default.

This command enables the ATM VP shaper under the ATM port. The type of ATM shaper are CBR or rt/nrt-VBR as defined by the traffic descriptor. It cannot be a UBR service-type.

All VCs within the shaper degrades into a UBR type service class. For example, when a CBR type VC is associated with the shaper, it degrades into a UBR type VC. Scheduling traffic amongst VCs within the shaper is based on WRR using the weight parameter.

If the VP shaper is deleted, the VCs that were under it is restored to their original service category.

The VP shaper is statically configured and instantiated upon configuration.

A VP shaper can be seamlessly added to or removed from the active VCs in the system.

The no form of this command reverts to the default.

This command creates or edits a Virtual Private LAN Services (VPLS) instance. The vpls command is used to create or maintain a VPLS service. If the service-id does not exist, a context for the service is created. If the service-id exists, the context for editing the service is entered.

A VPLS service connects multiple customer sites together acting like a zero-hop, Layer 2 switched domain. A VPLS is always a logical full mesh.

When a service is created, the create keyword must be specified if the create command is enabled in the environment context. When creating a service, you must enter the customer keyword and specify a customer-id to associate the service with a customer. The customer-id must already exist, having been created using the customer command in the service context. The customer-id must already exist having been created using the customer command in the service context. Once a service has been created with a customer association, it is not possible to edit the customer association. The service must be deleted and re-created with a new customer association.

To create a management VPLS on the 7450 ESS, the m-vpls keyword must be specified. See section Hierarchical VPLS Redundancy for an introduction to the concept of management VPLS.

Once a service is created, the use of the customer customer-id is optional for navigating into the service configuration context. Attempting to edit a service with the incorrect customer-id specified will result in an error.

More than one VPLS service may be created for a single customer ID.

By default, no VPLS instances exist until they are explicitly created.

The no form of this command deletes the VPLS service instance with the specified service-id. The service cannot be deleted until all SAPs and SDPs defined within the service ID have been shut down and deleted, and the service has been shut down.

The vpls command, within the IP interface context, is used to bind the IP interface to the specified service name (VPLS or I-VPLS).

The system does not attempt to resolve the service name provided until the IP interface is placed into the administratively up state (no shutdown). Once the IP interface is administratively up, the system will scan the available VPLS services that have the allow-ip-int-bind flag set for a VPLS service associated with the name. If the service name is bound to the service name when the IP interface is already in the administratively up state, the system will immediately attempt to resolve the given name.

If a VPLS service is found associated with the name and with the allow-ip-int-bind flag set, the IP interface is attached to the VPLS service allowing routing to and from the service virtual ports once the IP interface is operational.

A VPLS service associated with the specified name that does not have the allow-ip-int-bind flag set or a non-VPLS service associated with the name is ignored and will not be attached to the IP interface.

If the service name is applied to a VPLS service after the service name is bound to an IP interface and the VPLS service allow-ip-int-bind flag is set at the time the name is applied, the VPLS service is automatically resolved to the IP interface if the interface is administratively up or when the interface is placed in the administratively up state.

If the service name is applied to a VPLS service without the allow-ip-int-bind flag set, the system will not attempt to resolve the applied service name to an existing IP interface bound to the name. To rectify this condition, the flag must first be set and then the IP interface must enter or reenter the administratively up state.

While the specified service name may be assigned to only one service context in the system, it is possible to bind the same service name to more than one IP interface. If two or more IP interfaces are bound to the same service name, the first IP interface to enter the administratively up state (if currently administratively down) or to reenter the administratively up state (if currently administratively up) when a VPLS service is configured with the name and has the allow-ip-int-bind flag set is attached to the VPLS service. Only one IP interface is allowed to attach to a VPLS service context. No error is generated for the remaining non-attached IP interfaces using the service name.

Once an IP interface is attached to a VPLS service, the name associated with the service cannot be removed or changed until the IP interface name binding is removed. Also, the allow-ip-int-bind flag cannot be removed until the attached IP interface is unbound from the service name.

Unbinding the service name from the IP interface causes the IP interface to detach from the VPLS service context. The IP interface may then be bound to another service name or a SAP or SDP binding may be created for the interface using the sap or spoke-sdp commands on the interface.

VPRN Hardware Dependency

When a service name is bound to a VPRN IP interface, all SAPs associated with the VPRN service must be on hardware based on the FlexPath2 forwarding plane. Currently, these include the IOM3-XP and the various IMM modules. If any SAPs are associated with the wrong hardware type, the service name binding to the VPRN IP interface fails. Once an IP interface within the VPRN service is bound to a service name, attempting to create a SAP on excluded hardware fails.

IP Interface MTU and Fragmentation

A VPLS service is affected by two MTU values; port MTUs and the VPLS service MTU. The MTU on each physical port defines the largest Layer 2 packet (including all DLC headers and CRC) that may be transmitted out a port. The VPLS itself has a service level MTU that defines the largest packet supported by the service. This MTU does not include the local encapsulation overhead for each port (QinQ, Dot1Q, TopQ or SDP service delineation fields and headers) but does include the remainder of the packet. As virtual ports are created in the system, the virtual port cannot become operational unless the configured port MTU minus the virtual port service delineation overhead is greater than or equal to the configured VPLS service MTU. Thus, an operational virtual port is ensured to support the largest packet traversing the VPLS service. The service delineation overhead on each Layer 2 packet is removed before forwarding into a VPLS service. VPLS services do not support fragmentation and must discard any Layer 2 packet larger than the service MTU after the service delineation overhead is removed.

IP interfaces have a configurable up MTU that defines the largest packet that may egress the IP interface without being fragmented. This MTU encompasses the IP portion of the packet and does not include any of the egress DLC header or CRC. This MTU does not affect the size of the largest ingress packet on the IP interface. If the egress IP portion of the packet is larger than the IP interface MTU and the IP header do not fragment flag is not set, the packet is fragmented into smaller packets that will not exceed the configured MTU size. If the do not fragment bit is set, the packet is silently discarded at egress when it exceeds the IP MTU.

When the IP interface is bound to a VPLS service, the IP MTU must be at least 18 bytes less than the VPLS service MTU. This allows for the addition of the minimal Ethernet encapsulation overhead; 6 bytes for the DA, 6 bytes for the SA, 2 bytes for the Etype and 4 bytes for the trailing CRC. Any remaining egress virtual port overhead (Dot1P, Dot1Q, QinQ, TopQ or SDP) required above the minimum is known to be less than the egress ports MTU since the virtual port would not be operational otherwise.

If the IP interface IP MTU value is too large based on the VPLS service MTU, the IP interface will enter the operationally down state until either the IP MTU is adequately lowered or the VPLS service MTU is sufficiently increased.

The no form of this command on the IP interface is used to remove the service name binding from the IP interface. If the service name has been resolved to a VPLS service context and the IP interface has been attached to the VPLS service, the IP interface will also be detached from the VPLS service.

Commands in this context configure SHCV behavior in VPLS services. Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL, VPLS, PBB, and EVPN for VPLS service command syntax and descriptions.

This command defines a vpls-group index. Multiple vpls-group commands can be specified to allow the use of different VPLS and SAP templates for different ranges of service ids. A vpls-group can be deleted only in shutdown state. Multiple commands under different vpls-group ids can be issued and can be in progress at the same time.

This command configures the VPLS ID component that is signaled in one of the extended community attributes (ext-comm).

Values and format (6 bytes, other 2 bytes of type-subtype is automatically generated)

Commands in this context configure MSAP VPLS properties.

This is the command used to create a SAP template to be used in a vpls-template. Only certain existing VPLS SAP attributes can be changed in the vpls-sap-template, not in the instantiated VPLS SAP

The following SAP attributes are set in the instantiated saps (no configuration allowed):

description: “Sap <sap-id> controlled by MVRP service <svc id>” – auto generated

shutdown: no shutdown

This command is used to create a vpls-template to be used to auto-instantiate a range of VPLS services. Only certain existing VPLS attributes specified in the command reference section can be changed in the vpls-template, not in the instantiated VPLS. The following attributes are automatically set in the instantiated VPLSs (no template configuration necessary) and the operator cannot change these values.

vpn-id: none

description: “Service <svc id> auto-generated by control VPLS <svc-id>”

service-name: “Service <svc id>” (Auto-generated)

shutdown: no shutdown

Following existing attributes can be set by the user in the instantiated VPLSs:

[no] sap

All the other VPLS attributes are not supported.

This command configures the binding to a VPLS template to be used to instantiate pre-provisioned data VPLS using as input variables the service IDs generated by the vid-range command.

The no form of this command removes the binding and deletes the related VPLS instances. The command will fail if any of the affected VPLS instances have either a provisioned SAP or an active MVRP declaration/registration or if the related vpls-group id is in no shutdown state. Any changes to the vpls-template-binding require the vpls-group to be in shutdown state.

This command causes the base instance BGP export route policies to be applied to vpn-ipv4/6, mvpn-ipv4/6, l2-vpn, mdt-safi, mcast-vpn-ipv4, and evpn routes.

The no form of this command disables the application of the base instance BGP route policies to vpn-ipv4/6, mvpn-ipv4/6, l2-vpn, mdt-safi, mcast-vpn-ipv4, and evpn routes.

This command causes the base instance BGP import route policies to be applied to vpn-ipv4/6, mvpn-ipv4/6, l2-vpn, mdt-safi, mcast-vpn-ipv4, and evpn routes.

The no form of this command disables the application of the base instance BGP import route policies to vpn-ipv4/6, mvpn-ipv4/6, l2-vpn, mdt-safi, mcast-vpn-ipv4, and evpn routes.

This command specifies type of the extended community attribute exchanged using BGP to carry the OSPF VPN domain ID. This applies to VPRN instances of OSPF only. An attempt to modify the value of this object will result in an inconsistent value error when is not a VPRN instance. The parameters are mandatory and can be entered in either order. This command is not applicable in the config>service>vprn>ospf3 context.

This command is not supported in OSPF3.

This command specifies the VPN family policy that is applied when filtering routes for consideration for next-hop resolution process for EVPN and IP-VPN families.

This policy is supported by the following families:

In a VPN family policy:

The no form of this command removes the VPN family policy.

This command configures a single system-wide alternate source IPv4 address of the GRE tunnels in all VPRN services using the auto-bind-tunnel or an explicit SDP binding (config>service>vprn>spoke-sdp) with a tunnel of encapsulation GRE.

A change to the value of the vpn-gre-source-ip parameter can be performed without disabling the service. Once the new value is configured, the system address is not used in services which bind to the GRE tunnel.

The primary IPv4 address of any local network IP interface, loopback or otherwise, may be used.

The address of the following interfaces are not supported, and the configuration is rejected:

The vpn-gre-source-ip parameter value adheres to the following rules:

The no form of the command reverts to the default value.

This command configures the add-paths capability for VPN-IPv4 routes. By default, add-paths is not enabled for VPN-IPv4 routes.

The maximum number of paths per VPN-IPv4 NLRI to send is the configured send-limit, which is a mandatory parameter. The capability to receive multiple paths per prefix from a peer is configurable using the receive keyword, which is optional. If the receive keyword is not included in the command the receive capability is enabled by default.

The no form of this command disables add-paths support for VPN-IPv4 routes, causing sessions established using add-paths for VPN-IPv4 to go down and come back up without the add-paths capability.

This command configures the add-paths capability for VPN-IPv6 routes. By default, add-paths is not enabled for VPN-IPv6 routes.

The maximum number of paths per VPN-IPv6 NLRI to send is the configured send-limit, which is a mandatory parameter. The capability to receive multiple paths per prefix from a peer is configurable using the receive keyword, which is optional. If the receive keyword is not included in the command the receive capability is enabled by default.

The no form of this command disables add-paths support for VPN-IPv6 routes, causing sessions established using add-paths for VPN-IPv6 to go down and come back up without the add-paths capability.

This command specifies the route tag for an OSPF VPN on a PE router. This field is set in the tag field of the OSPF external LSAs generated by the PE. This is mainly used to prevent routing loops. This applies to VPRN instances of OSPF only. An attempt to modify the value of this object will result in an inconsistent value error when is not a VPRN instance.

This command is not supported in OSPF3.

This command configures a scheduling node, referred to as virtual port, within the context of an egress Ethernet port. The Vport scheduler operates either like a port scheduler with the difference that multiple Vport objects can be configured on the egress context of an Ethernet port, or it can be an aggregate rate when an egress port-scheduler policy is applied to the port.

The Vport is always configured at the port level even when a port is a member of a LAG.

When a port scheduler policy is applied to a Vport the following command is used:

The CLI will not allow the user to apply a port scheduler policy to a Vport if one has been applied to the port. Conversely, the CLI will not allow the user to apply a port scheduler policy to the egress of an Ethernet port if one has been applied to any Vport defined on the access egress context of this port. The agg-rate, along with an egress port-scheduler, can be used to ensure that a given Vport does not oversubscribe the port’s rate.

SAP and subscriber host queues can be port-parented to a Vport scheduler in a similar way they port-parent to a port scheduler or can be port-parented directly to the egress port-scheduler if the agg-rate is used.

When the Vport uses an aggregate rate, the following command is used:

configure>port>ethernet>access>egress>vport>agg-rate-limit

The no form of this command removes the Vport name from the configuration.