Refer to the 7450 ESS, 7750 SR, and 7950 XRS System Management Guide for information about configuring event and accounting logs.
The ntp-server command is not supported in the vprn ntp context. Then NTP is configured in a VPRN service, the NTP server mode is assumed and is not optional.
Refer to the Layer 2 Services Guide for more information.
This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.
The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.
Services are created in the administratively down (shutdown) state. When a no shutdown command is entered, the service becomes administratively up and then tries to enter the operationally up state. Default administrative states for services and service entities is described below in Special Cases.
The no form of this command places the entity into an administratively enabled state.
If the AS number was previously changed, the BGP AS number inherits the new value.
A service is regarded as operational providing that one IP Interface SAP and one SDP is operational.
This command creates a text description stored in the configuration file for a configuration context.
The description command associates a text string with a configuration context to help identify the content in the configuration file.
The no form of this command removes the string from the configuration.
no description
This command creates or edits a Virtual Private Routed Network (VPRN) service instance.
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.
VPRN services allow the creation of customer-facing IP interfaces in the same routing instance used for service network core routing connectivity. VPRN services require that the IP addressing scheme used by the subscriber must be unique between it and other addressing schemes used by the provider and potentially the entire Internet.
IP interfaces defined within the context of an VPRN service ID must have a SAP created as the access point to the subscriber network.
When a service is created, the customer keyword and customer-id must be specified and associates the service with a customer. The customer-id must already exist having been created using the customer command in the service context. When a service is 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.
When a service is created, the use of the customer customer-id is optional to navigate into the service configuration context. If attempting to edit a service with the incorrect customer-id results in an error.
Multiple VPRN services are created to separate customer-owned IP interfaces. More than one VPRN service can be created for a single customer ID. More than one IP interface can be created within a single VPRN service ID. All IP interfaces created within an VPRN service ID belongs to the same customer.
The no form of the command deletes the VPRN service instance with the specified service-id. The service cannot be deleted until all the IP interfaces and all routing protocol configurations defined within the service ID have been shutdown and deleted.
n/a — No VPRN service instances exist until they are explicitly created.
service-id: | 1 to 2147483648 |
svc-name: | 64 characters maximum |
This command creates an aggregate route.
Use this command to automatically install an aggregate in the routing table when there are one or more component routes. A component route is any route used for forwarding that is a more-specific match of the aggregate.
The use of aggregate routes can reduce the number of routes that need to be advertised to neighbor routers, leading to smaller routing table sizes.
Overlapping aggregate routes may be configured; in this case a route becomes a component of only the one aggregate route with the longest prefix match. For example if one aggregate is configured as 10.0.0.0/16 and another as 10.0.0.0/24, then route 10.0.128/17 would be aggregated into 10.0.0.0/16, and route 10.0.0.128/25 would be aggregated into 10.0.0.0/24. If multiple entries are made with the same prefix and the same mask the previous entry is overwritten.
A standard 4-byte BGP community may be associated with an aggregate route in order to facilitate route policy matching.
By default aggregate routes are not installed in the forwarding table, however there are configuration options that allow an aggregate route to be installed with a black-hole next hop or with an indirect IP address as next hop.
The no form of the command removes the aggregate.
no aggregate
ipv4-prefix | a.b.c.d (host bits must be 0) |
ipv4-prefix-length | 0 to 32 |
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
ipv6-prefix-length | 0 to 128 |
To remove the summary-only option, enter the same aggregate command without the summary-only parameter.
comm-id | asn:comm-val | well-known-comm |
asn | 0 to 65535 |
comm-val | 0 to 65535 |
well-known-comm | no-advertise, no-export, no-export-subconfed |
ipv4-prefix | a.b.c.d |
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D |
This command causes the vrf-export and vrf-target functions of the VPRN to include BGP-VPN routes installed in the VPRN route table. For split–horizon reasons, these routes are normally not re-advertisable as VPN-IP routes.
When a BGP-VPN route is re-exported, the route-distinguisher and label values are rewritten per the configuration of the re-exporting VPRN.
Caution: Ensure that routing updates do not loop back to the source when this command is used, otherwise the routes could become unstable. |
no allow-export-bgp-vprn
This command enables the context to configure automatic binding of a VPRN service using tunnels to MP-BGP peers.
The auto-bind-tunnel node is simply a context to configure the binding of VPRN routes to tunnels. The user must configure the resolution option to enable auto-bind resolution to tunnels in TTM. If the resolution option is explicitly set to disabled, the auto-binding to tunnel is removed.
If resolution is set to any, any supported tunnel type in VPRN context will be selected following TTM preference. If one or more explicit tunnel types are specified using the resolution-filter option, then only these tunnel types will be selected again following the TTM preference.
The following tunnel types are supported in a VPRN context in order of preference: RSVP, LDP, Segment Routing (SR), and GRE. The BGP tunnel type is not explicitly configured and is thus implicit. It is always preferred over any other tunnel type enabled in the auto-bind-tunnel context.
The ldp value instructs BGP to search for an LDP LSP with a FEC prefix corresponding to the address of the BGP next-hop.
The rsvp value instructs BGP to search for the best metric RSVP LSP to the address of the BGP next-hop. This address can correspond to the system interface or to another loopback used by the BGP instance on the remote node. The LSP metric is provided by MPLS in the tunnel table. In the case of multiple RSVP LSPs with the same lowest metric, BGP selects the LSP with the lowest tunnel-id.
When the sr-isis (sr-ospf) value is enabled, a SR tunnel to the BGP next-hop is selected in the TTM from the lowest numbered ISIS (OSPF) instance.
The sr-te value instructs BGP to search for the best metric SR-TE LSP to the address of the BGP next-hop. The LSP metric is provided by MPLS in the tunnel table. In the case of multiple SR-TE LSPs with the same lowest metric, BGP selects the LSP with the lowest tunnel-id.
The user must set resolution to filter to activate the list of tunnel-types configured under resolution-filter.
When an explicit SDP to a BGP next-hop is configured in a VPRN service (configure>service>vprn>spoke-sdp), it overrides the auto-bind-tunnel selection for that BGP next-hop only. There is no support for reverting automatically to the auto-bind-tunnel selection if the explicit SDP goes down. The user must delete the explicit spoke-sdp in the VPRN service context to resume using the auto-bind-tunnel selection for the BGP next-hop.
This command configures the resolution mode in the automatic binding of a VPRN service to tunnels to MP-BGP peers.
This command configures the subset of tunnel types which can be used in the resolution of VPRN prefixes within the automatic binding of VPRN service to tunnels to MP-BGP peers.
The following tunnel types are supported in a VPRN context in order of preference: RSVP, LDP, Segment Routing (SR), and GRE. The BGP tunnel type is not explicitly configured and is thus implicit. It is always preferred over any other tunnel type enabled in the auto-bind-tunnel context.
This command defines the autonomous system (AS) to be used by this VPN routing/forwarding (VRF). This command defines the autonomous system to be used by this VPN routing
The no form of the command removes the defined AS from this VPRN context.
no autonomous-system
This command enables the computation and use of a backup path for IPv4 and/or IPv6 BGP-learned prefixes belonging to the base router or a particular VPRN. Multiple paths must be received for a prefix in order to take advantage of this feature. When a prefix has a backup path and its primary path(s) fail the affected traffic is rapidly diverted to the backup path without waiting for control plane re-convergence to occur. When many prefixes share the same primary path(s), and in some cases also the same backup path, the time to failover traffic to the backup path is independent of the number of prefixes. In some cases prefix independent convergence may require use of FP2 or later IOMs/IMMs/XMAs.
By default, IPv4 and IPv6 prefixes do not have a backup path installed in the IOM.
no backup-path
This command configures a VPRN service to support a Carrier Supporting Carrier model. It should be configured on a network provider’s CSC-PE device.
This command cannot be applied to a VPRN unless it has no SAP or spoke-SDP interfaces. Once this command has been entered one or more MPLS-capable CSC interfaces can be created in the VPRN.
The no form of the command removes the Carrier Supporting Carrier capability from a VPRN.
no carrier-carrier-vpn
This command configures the VPRN BGP instance to participate in a BGP confederation. BGP confederations can be used to reduce the number of IBGP sessions required within an AS.
When a VPRN BGP instance is part of a confederation, it can form confederation-EBGP sessions with CE router peers in a different sub-autonomous systems of the same confederation as well as regular EBGP sessions with CE router peers outside the confederation. A VPRN BGP instance that is part of a confederation cannot import or export its routes to the base router instance (as VPN-IP routes).
The no form of the command deletes the specified member AS from the confederation. When members are not specified in the no statement, the entire list is removed and confederations is disabled. When the last member of the list is removed, confederations is disabled.
No confederations are defined.
This command enables the context to configure domain name servers.
The no form of the command disables DNS for this service.
This command configures the IPv4 address of the default secondary DNS server for the subscribers using this interface. Subscribers that cannot obtain an IPv4 DNS server address by other means, can use this for DNS name resolution.
The ipv4-address value can only be set to a nonzero value if the value of VPRN type is set to subscriber-split-horizon.
The no form of the command reverts to the default.
n/a
This command configures the IPv6 address of the default secondary DNS server for the subscribers using this interface. Subscribers that cannot obtain an IPv6 DNS server address by other means, can use this for DNS name resolution.
The ipv6-address value can only be set to a nonzero value if the value of VPRN type is set to subscriber-split-horizon.
The no form of the command reverts to the default.
n/a
This command configures the primary DNS server used for DNS name resolution. DNS name resolution can be used when executing ping, traceroute, and service-ping, and also when defining file URLs. DNS name resolution is not supported when DNS names are embedded in configuration files.
The no form of the command removes the primary DNS server from the configuration.
no primary-dns — No primary DNS server is configured.
ipv4-address -a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x[-interface] |
x:x:x:x:x:x:d.d.d.d[-interface] | |
x: [0..FFFF]H | |
d: [0..255]D | |
interface - 32 characters max, for link local addresses. |
This command configures the secondary DNS server for DNS name resolution. The secondary DNS server is used only if the primary DNS server does not respond.
DNS name resolution can be used when executing ping, traceroute, and service-ping, and also when defining file URLs. DNS name resolution is not supported when DNS names are embedded in configuration files.
The no form of the command removes the secondary DNS server from the configuration.
no secondary-dns — no secondary DNS server is configured
ipv4-address -a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x[-interface] |
x:x:x:x:x:x:d.d.d.d[-interface] | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
interface - 32 characters max, for link local addresses. |
This command configures the tertiary DNS server for DNS name resolution. The tertiary DNS server is used only if the primary DNS server and the secondary DNS server do not respond.
DNS name resolution can be used when executing ping, traceroute, and service-ping, and also when defining file URLs. DNS name resolution is not supported when DNS names are embedded in configuration files.
The no form of the command removes the tertiary DNS server from the configuration.
no tertiary-dns — No tertiary DNS server is configured.
ipv4-address -a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x[-interface] |
x:x:x:x:x:x:d.d.d.d[-interface] | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
interface - 32 characters max, for link local addresses. |
This command enables equal-cost multipath (ECMP) and configures the number of routes for path sharing. For example, the value of 2 means that 2 equal cost routes will be used for cost sharing.
ECMP groups form when the system routes to the same destination with equal cost values. Routing table entries can be entered manually (as static routes), or they can be formed when neighbors are discovered and routing table information is exchanged by routing protocols. The system can balance traffic across the groups with equal costs.
ECMP can only be used for routes learned with the same preference and same protocol. See the discussion on preferences in the application6 command.
When more ECMP routes are available at the best preference than configured by the max-ecmp-routes parameter, then the lowest next-hop IP address algorithm is used to select the number of routes configured.
The no form of the command disables ECMP path sharing. If ECMP is disabled and multiple routes are available at the best preference and equal cost, the newly updated route is used.
no ecmp
This command is used to specify route policies that control how routes are exported from the local VRF route table to the base router (GRT) route table. The leaked routes show as protocol VPN-Leak in the GRT and allow traffic to ingress on a GRT interface and egress on a VPRN interface.
The export-grt command can reference up to 5 objects, where each object is either a policy logical expression or the name of a single policy. The objects are evaluated in the specified order to determine final action to accept or reject the route.
Only one of the 5 objects referenced by the export-grt command can be a policy logical expression consisting of policy names (enclosed in square brackets) and logical operators (AND, OR, NOT). The first of the 5 objects has a maximum length of 255 characters while the remaining 4 objects have a maximum length of 64 characters each.
When multiple export-grt commands are issued, the last command entered overrides the previous command.
The no form of the command removes all route policy names from the export-grt list.
no export-grt
This command allows the best BGP route learned by a VPRN to be exported as a VPN-IP route even when that BGP route is inactive in the route table due to the presence of a preferred BGP-VPN route from another PE. In order for the BGP route to be exported, it must be accepted by the VRF export policy.
This “best-external” type of route advertisement is useful in active/standby multi-homing scenarios because it can ensure that all PEs have knowledge of the backup path provided by the standby PE.
By default, an inactive BGP route cannot be exported from a VPRN.
no export-inactive-bgp
This command specifies the FIB priority for VPRN.
This command enables the context to configure flowspec-related parameters for the specified routing instance.
This command configures the maximum number of flowspec routes or rules that can be embedded into an ingress IP filter policy for a specified routing instance. Flowspec filter entries embedded in a filter policy in this routing instance will use filter entries from the range between the embedding offset and “offset + ip-filter-max-size – 1”.
The sum of the ip-filter-max-size value parameter and the highest offset in any IPv4 filter that embeds IPv4 flowspec rules from this routing instance (excluding filters that embed at offset 65536) must not exceed 65536.
The ip-filter-max-size configuration can be adjusted up or down at any time. If the number of IPv4 flowspec rules that are currently installed is M, and the new limit is N, where N<M, then the last set of rules from N to M (by flowspec order) are immediately removed, but are retained in the BGP RIB. If the limit is increased, new rules are programmed only as they are received again in new BGP updates.
ip-filter-max-size default
This command configures the maximum number of IPv6 flowspec routes or rules that can be embedded into an ingress IPv6 filter policy for a specified routing instance. Flowspec filter entries embedded in a filter policy in this routing instance will use filter entries from the range between the embedding offset and “offset + ip-filter-max-size – 1”.
The sum of the ip-filter-max-size value parameter and the highest offset in any IPv6 filter that embeds IPv6 flowspec rules from this routing instance (excluding filters that embed at offset 65536) must not exceed 65536.
The ip-filter-max-size configuration can be adjusted up or down at any time. If the number of IPv6 flowspec rules that are currently installed is M, and the new limit is N, where N<M, then the last set of rules from N to M (by flowspec order) are immediately removed, but are retained in the BGP RIB. If the limit is increased, new rules are programmed only as they are received again in new BGP updates.
ipv6-filter-max-size default
This command provides the context under which all Global Route Table (GRT) leaking commands are configured. If all the supporting commands in the context are removed, this command will also be removed.
This command enables the functions required for looking up routes in the Global Route Table (GRT) when the lookup in the local VRF fails. If this command is enabled without the use of a static-route option (as subcommand to this parent), a lookup in the local VRF is preferred over the GRT. When the local VRF returns no route table lookup matches, the result from the GRT is preferred.
The no form of this command disables the lookup in the GRT when the lookup in the local VRF fails.
no enable-grt
Enables the support of specific management protocols over VPRN interfaces that terminate on Base routing context IPv4 and IPv6 interface addresses, including Base loopback and system addresses. Global Routing Table (GRT) leaking is used to enable visibility/access of the Base interface addresses in the VPRN. The supported protocols are Telnet, FTP, SNMP, and SSH (including applications that ride over SSH such as scp, sftp, and NETCONF).
Ping and traceroute responses from the Base router interfaces are supported and are not configurable.
The allow-local-management command does not control the support for management protocols terminating on VPRN interfaces directly. See the configure>service>vprn>snmp>access CLI command for SNMP support on VPRN interface addresses.
This command uses route policy to determine which routes are exported from the VRF to the GRT along with all the forwarding information. These entries will be marked as BGP-VPN routes in the GRT. Routes must be in the GRT in order for proper routing to occur from the GRT to the VRF.
no export-grt
This command provides the ability to limit the total number of routes exported from the VRF to the GRT. The value zero (0) provides an override that disables the maximum limit. Setting this value to zero (0) will not limit the number of routes exported from the VRF to the GRT. Configuring a range of one (1) to 1000 will limit the number of routes to the specified value.
The no form of the command sets the export-limit to a default of five (5).
export-limit 5
The export-limit range provides the ability to limit the total number of IPv6 routes exported from the VPRN to the GRT. The value “0” provides an override that disables the maximum limit. Setting this value to “0” will not limit the number of routes exported from the VPRN to the GRT. Configuring a range of 1-1000 will limit the number of routes to the specified value.
The no form of the command sets the export-limit to a default of 5.
export-v6-limit 5
This command enables the context to configure GSMP connections maintained in this service.
not enabled
This command specifies a GSMP name. A GSMP group name is unique only within the scope of the service in which it is defined.
This command configures ANCP parameters for this GSMP group.
This command enables the ANCP dynamic topology discovery capability.
The no form of this command disables the feature.
This command specifies whether or not the GSMP ANCP OAM capability should be negotiated at startup of the GSMP connection.
The no form of this command disables the feature.
This command configures the hold-multiplier for the GSMP connections in this group.
This command when applied will filter out new subscriber’s ANCP messages from subscriber with “DSL-line-state” IDLE.
no idle-filter
This command configures keepalive values for the GSMP connections in this group.
This command adds or removes a neighbor in this group.
This command configures the source ip-address used in the connection towards the neighbor.
This command configures the type of priority marking to be used.
This command enables the system to store DSL line information in memory. If the GSMP connection terminates, the DSL line information will remain in memory and accessible for Radius authentication and accounting.
no persistency-database
This command enables the context to configure L2TP parameters. L2TP extends the PPP model by allowing Layer 2 and PPP endpoints to reside on different devices interconnected by a packet-switched network.
This command configures Attribute Value Pair (AVP) hiding. This capability can be used to avoid the passing of sensitive data, such as user passwords, as clear text in an AVP.
The no form of the command returns the value to never allow AVP hiding.
no avp-hiding
This command what string to put in the Calling Number AVP, for L2TP control messages related to a session in this L2TP protocol instance.
ascii-spec | char-specification ascii-spec | |||
char-specification | ascii-char | char-origin | |||
ascii-char | a printable ASCII character | |||
char-origin | %origin | |||
origin | S | c | r | s | l | |||
S | - system name, the value of TIMETRA-CHASSIS-MIB::tmnxChassisName | |||
c | - Agent Circuit Id | |||
r | - Agent Remote Id | |||
s | - SAP ID, formatted as a character string | |||
l | - Logical Line ID |
This command configures the use of challenge-response authentication.
The no form of the command reverts to the default never value.
no challenge
This command configures the period of time that the data of a disconnected tunnel will persist before being removed.
The no form of the command removes the value from the configuration.
no destruct-timeout
This command configures the L2TP AVPs to exclude.
Enables IPCP negotiation for PPPoE hosts. If not enabled (default setting), the current behavior will apply even if subnet is allocated to the host. Enables IPCP negotiation for PPPoE hosts. If not enabled (default setting), the current behavior will apply even if subnet is allocated in the host.
This command configures the reaction to a change of tunnel peer address in this router.
This command configures the L2TP receive window size.
This command configures the L2TP session limit of this router.
This command configures an L2TP tunnel group.
This command configures the L2TP session limit for the router. L2TP is connection-oriented. The L2TP Network Server (LNS) and LAC maintain state for each call that is initiated or answered by an LAC. An L2TP session is created between the LAC and LNS when an end-to-end PPP connection is established between a remote system and the LNS. Datagrams related to the PPP connection are sent over the tunnel between the LAC and LNS. There is a one to one relationship between established L2TP sessions and their associated calls.
no session-limit
This command configures Attribute Value Pair (AVP) hiding. This capability can be used to avoid the passing of sensitive data, such as user passwords, as clear text in an AVP.
The no form of the command returns the value to never allow AVP hiding.
no avp-hiding
This command configures the use of challenge-response authentication.
The no form of the command reverts to the default never value.
no challenge
This command configures the period of time that the data of a disconnected tunnel will persist before being removed.
The no form of the command removes the value from the configuration.
no destruct-timeout
This command configures the time interval between two consecutive tunnel Hello messages. The Hello message is an L2TP control message sent by either peer of a LAC-LNS control connection. This control message is used as a keepalive for the tunnel.
The no form of the command removes the interval from the configuration.
no hello-interval
This command configures the period of time that an established tunnel with no active sessions will persist before being disconnected.
Enter the no form of the command to maintain a persistent tunnel.
The no form of the command removes the idle timeout from the configuration.
no idle-timeout
This command enables the context to configure L2TPv3 parameters.
n/a
This command configures the length of the optional cookie field.
The no form of the command returns the cookie-length to a default of none.
no cookie-length
This command configures the hashing algorithm used to calculate the message digest.
The no form of the command returns the digest-type to none.
no digest-type
This command configures the length for the local L2TPv3 nonce (random number) value used in the Nonce AVP.
The no form of the command returns the nonce-length to a default of none.
no nonce-length
This command configures the IP address that should be used within the Remote Router-ID AVP.
The no form of this command removes the configured IP address.
no rem-router-id
This command configures the allowable pseudowire capability list that is advertised to the far end. An empty list results in both pseudowire capabilities being advertised.
The no form of this command removes the list and advertises both pseudowire capabilities to the far end.
no pw-cap-list
This command enables tracking of password changes, allowing password tunnel passwords to be changed without bringing down active tunnels or sessions. This is only supported with L2TPv3.
The no form of the command disables password change tracking.
no track-password-change
This command configures the transport type to be used to carry the L2TPv3 tunnel. Currently, only IP transport is supported.
The no form of this command returns the transport-type to the default value.
no transport-type
This command configures the ISA LNS group.
This command configures the local address.
This command creates the local host name used by this system for the tunnels in this L2TP group during the authentication phase of tunnel establishment. It can be used to distinguish tunnels.
The no form of the command removes the name from the configuration.
no local-name
This command configures the number of retries allowed for this L2TP tunnel while it is established, before its control connection goes down.
The no form of the command removes the value from the configuration.
no max-retries-estab
This command configures the number of retries allowed for this L2TP tunnel while it is not established, before its control connection goes down.
The no form of the command removes the value from the configuration.
no max-retries-not-estab
This command configures the password between L2TP LAC and LNS
The no form of the command removes the password.
no password
This command configures PPP for the L2TP tunnel group.
This command configures the PPP authentication protocol to negotiate.
This command configures the authentication policy.
This command configures the default group interface.
This command configures the PPP keepalive interval and multiplier.
This command configures the maximum PPP MTU size.
This command configures the use of the authentication AVPs received from the LAC.
This command configures the use of the proxy LCP AVPs received from the LAC.
This command configures the local user database to use for PPP PAP/CHAP authentication.
This command specifies how new sessions are assigned to one of the set of suitable tunnels that are available or could be made available.
session-assign-method existing-first
This command configures the session limit. The value controls how many L2TP session will be allowed within a given context (system, group, tunnel).
The no form of the command removes the value from the configuration.
no session-limit
This command configures an L2TP tunnel. A tunnel exists between a LAC-LNS pair and consists of a Control Connection and zero or more L2TP sessions. The tunnel carries encapsulated PPP datagrams and control messages between the LAC and the L2TP Network Server (LNS).
This command specifies if this tunnel is to be automatically set up by the system.
no auto-establish
This command configures Attribute Value Pair (AVP) hiding. This capability can be used to avoid the passing of sensitive data, such as user passwords, as clear text in an AVP.
Caution: Nokia recommends that sensitive information not be sent in clear text. |
The no form of the command removes the parameter of the configuration and indicates that the value on group level will be taken.
no avp-hiding
This command configures the use of challenge-response authentication.
The no form of the command removes the parameter from the configuration and indicates that the value on group level will be taken.
no challenge
This command configures the number of seconds between sending Hellos for a L2TP tunnel.
The no form removes the parameter from the configuration and indicates that the value on group level will be taken.
This command configures the idle timeout to wait before being disconnect.
The no form indicates that the parameter will be removed from the configuration and that the value specified on group level will be taken.
This command configures the peer address.
The no form of the command removes the IP address from the tunnel configuration.
no peer
This command configures a preference number that indicates the relative preference assigned to a tunnel when using a weighted session assignment.
The no form of the command removes the preference value from the tunnel configuration.
no preference
This command configures a string to be compared to the host name used by the tunnel peer during the authentication phase of tunnel establishment.
This command enables the context to configure DHCP parameters.
This command enables the context to configure DHCP6 parameters.
This command instantiates a local DHCP server. A local DHCP server can serve multiple interfaces but is limited to the routing context it was which it was created.
n/a
This command enables the context to configure failover parameters.
With this flag enabled, the ‘remote’ IP address/prefix can be taken over immediately upon entering the PARTNER-DOWN state of the intercommunication link, without having to wait for the MCLT to expire. By setting this flag, the lease times of the existing DHCP clients, while the intercommunication link is in the PARTNER-DOWN state, will still be reduced to the MCLT over time and all new lease times will be set to MCLT this behavior remain the same as originally intended for MCLT.
Some deployments require that the ‘remote’ IP address/prefix range starts delegating new IP addresses/prefixes upon the failure of the intercommunication link, without waiting for the intercommunication link to transition from the COMM-INT state into the PARTNER-DOWN state and the MCLT to expire while in PARTNER-DOWN state.
This can be achieved by enabling the ignore-mclt-on-takeover flag and by configuring the partner-down-delay to 0.
Enabling this functionality must be exercised with caution. One needs to keep in mind that the partner-down-delay and MCLT timers were originally introduced to prevent IP address duplication in cases where DHCP redundant nodes transition out-of-sync due to the failure of intercommunication link. These timers (partner-down-delay and MCLT) would ensure that during their duration, the new IP addresses/prefixes are delegated only from one node – the one with local IP address-range/prefix. The drawback is of course that the new IP address delegation is delayed and thus service is impacted.
But if one could ensure that the intercommunication link is always available, then the DHCP nodes would stay in sync and the two timers would not be needed. This is why it is of utmost importance that in this mode of operation, the intercommunication link is well protected by providing multiple paths between the two DHCP nodes. The only event that should cause intercommunication link to fail is the entire nodal failure. This failure is acceptable since in this case only one DHCP node is available to provide new IP addresses/prefixes.
no ignore-mclt-on-takeover
The maximum-client-lead-time (MCLT) is the maximum time that a DHCP server can extend client’s lease time beyond the lease time currently known by the DHCP partner node. In dual-homed environment, the initial lease time for all DHCP clients is by default restricted to MCLT. Consecutive DHCP renews are allowed to extend the lease time beyond the MCLT.
The MCLT is a safeguard against IP address/prefix duplication in cases of a lease synchronization failure when local-remote failover model is deployed
Once the intercommunication link failure between the redundant DHCP servers is detected, the DHCP IP address range configured as remote will not be allowed to start delegating new leases until the MCLT + partner-down-delay intervals expire. This is to ensure that the new lease that was delegated from the ‘local’ IP address-range/prefix on one node, but was never synchronized due to the intercommunication link failure, will expire before the same IP address/prefix is allocated from the remote IP address-range/prefix on the other node.
However, the already existing (and synchronized) lease times can be renewed from the remote IP address range at any time, regardless of the state of the intercommunication link (operational or failed).
Lease synchronization failure can be caused either by a node failure, or a failure of the link over which the DHCP leases are synchronized (intercommunication link). Synchronization failure detection can take up to 3 seconds.
During the failure, the DHCP lease time for the new clients will be restricted to MCLT while for the existing clients the lease time will over time (by consecutive DHCP renews) be gradually reduced to the MCLT.
10 minutes
Since the DHCP lease synchronization failure can be caused by the failure of the intercommunication link (and not necessary the entire node), there is a possibility the redundant DHCP servers become isolated in the network. In other words, they can serve DHCP clients but they cannot synchronize the lease. This can lead to duplicate assignment of IP addresses, since the servers have configured overlapping IP address ranges but they are not aware of each other’s leases.
The purpose of the partner-down-delay is to prevent the IP lease duplication during the intercommunication link failure by not allowing new IP addresses to be assigned from the remote IP address range. This timer is intended to provide the operator with enough time to remedy the failed situation and to avoid duplication of IP addresses/prefixes during the failure.
During the partner-down-delay time, the prefix designated as remote will be eligible only for renewals of the existing DHCP leases that have been synchronized by the peering node. Only after the sum of the partner-down-delay and the maximum-client-lead-time will the prefix designated as remote be eligible for delegation of the new DHCP leases. When this occurs, we say that the remote IP address range has been taken over.
It is possible to expedite the takeover of a remote IP address range so that the new IP leases can start being delegated from that range shortly after the intercommunication failure is detected. This can be achieved by configuring the partner-down-delay timer to 0 seconds, along with enabling the ignore-mclt-on-takeover CLI flag. Caution must be taken before enabling this functionality. It is safe to bypass safety timers (partner-down-delay + MCLT) only in cases where the operator is certain that the intercommunication between the nodes has failed due to the entire node failure and not due to the intercommunication (MCS) link failure. Failed intercommunication due to the nodal failure would ensure that only one node is present in the network for IP address delegation (as opposed to two isolated nodes with overlapping IP address ranges where address duplication can occur). For this reason, the operator MUST ensure that there are redundant paths between the nodes to ensure uninterrupted synchronization of DHCP leases.
In access-driven mode of operation, partner-down-delay has no effect.
23 hours, 59 minutes, and 59 seconds.
DHCP leases can be synchronized per DHCP server of DHCP pool. The pair of synchronizing servers or pools is identified by a tag. The synchronization information is carried over the Multi-Chassis Synchronization (MCS) link between the two peers. MCS link is a logical link (IP, or MPLS).
MCS runs over TCP, port 45067 and it is using either data traffic or keepalives to detect failure on the communication link between the two nodes. In the absence of any MCS data traffic for more than 0.5sec, MCS will send its own keepalive to the peer. If a reply is NOT received within 3sec, MCS will declare its operation state as DOWN and the DB Sync state as out-of-sync. MCS will consequently notify its clients (DHCP Server being one of them) of this. It can take up to 3 seconds before the DHCP client realizes that the inter-chassis communication link has failed.
The inter-chassis communication link failure does not necessarily assume the same failed fate for the access links. In other words the two redundant nodes can become isolated from each other in the network. This would occur in cases where only the intercommunication (MCS) link fails. It is of utmost importance that this MCS link be highly redundant.
This command enables startup-wait-time during which each peer waits after the initialization process before assuming the active role for the prefix designated as local or access-driven. This is to avoid transient issues during the initialization process.
2 minutes
This command specifies whether the Rapid Commit Option (RCO) sent by the DHCPv6 client is processed.
If enabled and the client has included an RCO in the solicit, the server ignores the option and processes the remainder of the message as if no RCO were present.
The no form of the command disables ignore-rapid-commit.
This command configures the time to remember this lease.
days: | [0 to 3650] |
hours: | [0 to 23] |
minutes: | [0 to 59] |
seconds: | [0 to 59 |
This command enables the sending of sending force-renew messages.
The no form of the command disables the sending of force-renew messages.
no force-renews
This command configures a DHCP address pool on the router.
n/a
This command configures the maximum lease time.
The no form of the command returns the value to the default.
10 days
days : | 0 to 3650 |
hours | 0 to 23 |
minutes: | 0 to 59 |
seconds | 0 to 59 |
This command configures the minimum lease time.
The no form of the command returns the value to the default.
10 minutes
days : | 0 to 3650 |
hours | 0 to 23 |
minutes: | 0 to 59 |
seconds | 0 to 59 |
This command configures the minimum number of free addresses.
The no form of the command reverts to the default.
1
This command configures the offer time.
The no form of the command returns the value to the default.
1 minute
This command enables the context to configure pool options. The options defined here can be overruled by defining the same option in the local user database.
n/a
This command configures specific DHCP options. The options defined here can overrule options in the local user database.
The no form of the removes the option from the configuration.
n/a
This command configures the IP address of the DNS server.
n/a
This command configures the default domain for a DHCP client that the router uses to complete unqualified hostnames (without a dotted-decimal domain name).
The no form of the command removes the name from the configuration.
n/a
This command configures the renew-timer (T1), the time at which the client contacts the server from which the addresses in the IA_NA or IA_PD were obtained to extend the lifetimes of the addresses or prefixes assigned to the client.
1800
This command configures the rebind-timer (T2), the time at which the client contacts any available server to extend the lifetimes of the addresses or prefixes assigned to the client.
2880
days | 0 to 3650 |
hours | 0 to 23 |
minutes | 0 to 59 |
seconds | 0 to 59 |
This command allows a list of prefixes (using the prefix command multiple times) to be routed to hosts associated with this pool. Each prefix will be represented in the associated FIB with a reference to the pool. Prefixes are defined as being for prefix delegation (pd) or use on a WAN interface or host (wan-host).
failover local
The IPv6 prefix configured as local on one node can only be configured as remote on the other node. No other combination is allowed between the two nodes for an IPv6 prefix that is configured as local.
The dhcpv6 relay could point to both IPv6 DHCP server addresses— the one hosting the local IPv6 prefix and the one hosting the corresponding remote IPv6 prefix. Under normal circumstances the new lease will always be allocated from the local IPv6 prefix while the leases can be renewed from either IPv6 prefix (local or remote). Under network failure, the remote IPv6 prefix can be taken over according to the intercommunication link state transitions and associated timers.
To ensure faster takeover, the partner-down-delay can be set to 0 and the MCLT time can be ignored. Extra caution should be exercised when enabling this mode of operation, as described in the configuration guides.
The IPv6 prefix configured as remote on one node can only be configured as local on the other node. No other combination is allowed between the two nodes for an IP address ranges that is configured as remote.
The IPv6 prefix configured as access-driven on one node can only be configured as access-driven on the other node. No other combination is allowed between the two nodes for an IPv6 prefix that is configured as access-driven.
There MUST be no crosslinks between the DHCPv6 servers that have IPv6 address ranges configured in access-driven failover mode. In other words, each node must have the dhcp-relay pointing to the IPv6 address of the local DHCPv6 server. This IPv6 address must be the same on both nodes. For example, both DHCPv6 servers should have a loopback address configured with the same IPv6 address (IPv4 or IPv6) and a DHCPv6 server associated with this loopback address. Those IPv6 addresses MUST not be advertised outside of each box. The DHCPv6 relay in each node would point to its local DHCPv6 server via this loopback IPv6 address.
The preferred lifetime for the IPv6 prefix or address in the option, expressed in units of seconds. When the preferred lifetime expires, any derived addresses are deprecated.
3600
days | 0 to 3650 |
hours | 0 to 23 |
minutes | 0 to 59 |
seconds | 0 to 59 |
The valid lifetime for the IPv6 prefix or address in the option, expressed in units of seconds.
86,400
days | 0 to 3650 |
hours | 0 to 23 |
minutes | 0 to 59 |
seconds | 0 to 59 |
This command specifies whether the GI address selects a single subnet or a pool.
The no form of the command reverts to the default.
subnet
This command specifies which method is used by the local DHCP server to uniquely identify a user.
The no form of the command reverts to the default.
user-ident duid
This command configures the time the client transitions to a rebinding state.
The no form of the command removes the time from the configuration.
n/a
days | 0 to 3650 |
hours | 0 to 23 |
minutes | 0 to 59 |
seconds | 0 to 59 |
This command configures the time the client transitions to a renew state.
The no form of the command removes the time from the configuration.
n/a
days | 0 to 3650 |
hours | 0 to 23 |
minutes | 0 to 59 |
seconds | 0 to 59 |
This command configures the amount of time that the DHCP server grants to the DHCP client permission to use a particular IP address.
The no form of the command removes the lease time parameters from the configuration.
n/a
days | 0 to 3650 |
hours | 0 to 23 |
minutes | 0 to 59 |
seconds | 0 to 59 |
This command configures up to four Network Basic Input/Output System (NetBIOS) name server IP addresses.
n/a
This command configures the Network Basic Input/Output System (NetBIOS) node type.
n/a
This command designates a local DHCPv4 server for local pools management where IPv4 addresses for PPPoXv4 clients will be allocated without the need for the internal DHCP relay-agent. Those addresses will be tied to PPPoX sessions and they will be de-allocated when the PPPoX session is terminated.
n/a
This command enables local DHCP Server pool management for PPPoXv4 clients. A pool of IP addresses can be shared between IPoE clients that rely on DHCP protocol (lease renewal process) and PPPoX clients where address allocation is not dependent on DHCP messaging but instead an IP address allocation within the pool is tied to the PPPoX session.
n/a
This command references a default DHCP address pool for local PPPoX pool management in case that the pool-name is not returned via Radius or LUDB.
n/a
This command will render the subscriber-interface non operation for the given amount of time once the node is rebooted or once the interface is enabled (no-shutdown). The purpose of this timer is to stall the operation of the subscriber-interface until the MCS database is synchronized.
A typical use case for this timer would be to prevent IP lease duplication for PPPoE clients using local PPPoXv4/v6 pools in redundant DHCPv4/v6 server configuration. Since there is no classical DHCP lease state maintained for local PPPoXv4/v6 pools, the IP addresses will not be synchronized via DHCP Server. Instead they will be synchronized via PPPoX clients whose state is maintained in the router. Once the PPPoX subscriber host is synchronized between the two nodes, the respective IP address lease will be updated in the respective local pool.
One artifact of this behavior (IP address assignment in local DHCP pools is synchronized via PPPoX clients and not via DHCP server synchronization mechanism) is that during the node boot, the DHCP server must wait for the completion of PPPoX subscriber synchronization via MCS so that it learns which addresses/prefixes are already allocated on the peering node. Since the DHCP server can theoretically start assigning IP addresses before the PPPoX sync is completed, a duplicate address assignment my occur. For example an IP address lease can be granted via DHCP local pools while PPPoX sync is still in progress. Once the PPPoX sync is completed, the DHCP server may discover that the granted IP lease has already been allocated by the peering node. The most recent lease will be kept and the other will be removed from both systems. To prevent this scenario, a configurable timer is set to an arbitrary value that will render sub-if non-operational until the timer expires. The purpose of this timer is to allow the PPPoX sync to complete before subscribers under the sub-intf can be served.
n/a
This command creates a subnet of IP addresses to be served from the pool. The subnet cannot include any addresses that were assigned to subscribers without those addresses specifically excluded. When the subnet is created no IP addresses are made available until a range is defined.
n/a
This command configures a range of IP addresses to be served from the pool. All IP addresses between the start and end IP addresses will be included (other than specific excluded addresses).
The only two valid failover combinations between the two redundant DHCP nodes are:
failover local
The IP address range configured as local on one node can only be configured as remote on the other node. No other combination is allowed between the two nodes for an IP address ranges that is configured as local.
The dhcp relay could point to both IP DHCP server addresses—the one hosting the local IP address range and the one hosting the corresponding remote IP address range. Under normal circumstances the new lease will always be allocated from the local IP address range while the leases can be renewed from either IP address range (local or remote). Under network failure, the remote IP address range can be taken over according to the intercommunication link state transitions and associated timers.
To ensure faster takeover, the partner-down-delay can be set to 0 and the MCLT time can be ignored. Extra caution should be exercised when enabling this mode of operation, as described in the configuration guides.
The IP address range configured as remote on one node can only be configured as local on the other node. No other combination is allowed between the two nodes for an IP address ranges that is configured as remote.
The IP address range configured as access-driven on one node can only be configured as access-driven on the other node. No other combination is allowed between the two nodes for an IP address ranges that is configured as access-driven.
There MUST be no crosslinks between the DHCP servers that have IP address ranges configured in access-driven failover mode. In other words, each node must have the dhcp-relay pointing to the IP address of the local DHCP server. This IP address must be the same on both nodes. For example, both DHCP servers should have a loopback address configured with the same IP address (IPv4 or IPv6) and a DHCP server associated with this loopback address. Those IP addresses MUST not be advertised outside of each box. The DHCP relay in each node would point to its local DHCP server via this loopback IP address.
This command subnet draining which means no new leases can be assigned from this subnet and existing leases are cleaned up upon renew/rebind.
The no form of the command means the subnet is active and new leases can be assigned from it.
This command specifies a range of IP addresses that excluded from the pool of IP addresses in this subnet.
n/a
This command configures the maximum number of declined addresses allowed.
64
This command configures the minimum number of free addresses in this subnet. If the actual number of free addresses in this subnet falls below this configured minimum, a notification is generated.
1
This command configures the IP address of the default router for a DHCP client. Up to four IP addresses can be specified.
The no form of the command removes the address(es) from the configuration.
n/a
This command specifies the subnet-mask option to the client. The mask can either be defined (for supernetting) or taken from the pool address.
The no form of the command removes the address from the configuration.
n/a
This command enables the use of gi-address matching. If the gi-address flag is enabled, a pool can be used even if a subnets is not found. If the local-user-db-name is not used, the gi-address flag is used and addresses are handed out by GI only. If a user must be blocked from getting an address the server maps to a local user database and configures the user with no address.
A pool can include multiple subnets. Since the GI is shared by multiple subnets in a subscriber-interface the pool may provide IP addresses from any of the subnets included when the GI is matched to any of its subnets. This allows a pool to be created that represents a sub-int.
no use-gi-address
This command specifies if the IP address pool to be used by this server is the pool indicated by the vendor-specific sub-option 13 of the DHCP Option 82.
When enabled, the pool indicated by the sub-option 13 is to be used.
The no form of the command indicates that the pool selection is specified by the value of use-gi-address setting.
This command configures a local user database for authentication.
no user-db
This command enables the context to configure IGMP parameters.
The no form of the command disables IGMP.
disabled
This command configures IGMP group interfaces.
The no form of the command reverts to the default.
n/a
This command enables the IGMP router alert check option.
The no form of the command disables the router alert check.
This command specifies the policy that is to be applied on this interface.
This command configures the maximum number of groups for which IGMP can have local receiver information based on received IGMP reports on this interface. When this configuration is changed dynamically to a value lower than currently accepted number of groups, the groups that are already accepted are not deleted. Only new groups will not be allowed.
The no form of the command removes the value.
This command specifies the maximum number of sources for which IGMP can have local receiver information based on received IGMP reports on this interface. When this configuration is changed dynamically to a value lower than currently accepted number of sources, the sources that are already accepted are not deleted. Only new sources will not be allowed.
This command configures the maximum number of group sources for which IGMP can have local receiver information based on received IGMP reports on this interface. When this configuration is changed dynamically to a value lower than currently accepted number of group sources, the group sources that are already accepted are not deleted. Only new group sources will not be allowed.
The no form of the command reverts to the default.
0
This command configures multicast CAC policy and constraints for this interface.
n/a
This command assigns existing MCAC interface policy to this interface.
The no form of the command removes the MCAC interface policy association.
no if-policy
This command enables the context to configure multicast CAC constraints.
n/a
This command configures interface levels and associated bandwidth for multicast CAC policy.
This command configures the number of ports down and level for interface’s multicast CAC policy.
not enabled
This command enables port weight to be used when determining available bandwidth per level when LAG ports go down/come up. The command is required for proper operation on mixed port-speed LAGs and can be used for non-mixed port-speed LAGs as well.
no use-lag-port-weight - port number is used when determining available bandwidth per level when LAG ports go down/come up.
This command references the global channel bandwidth definition policy that is used for HMCAC and HQoS Adjust.
HQoS Adjustment is supported with redirection enabled or per-host-replication disabled. In other words, the policy from the redirected interface is used for HQoS Adjustment.
Hierarchical MCAC (HMCAC) is supported with redirection enabled or per-host-replication disabled. In HMCAC, the subscriber is checked first against its bandwidth limits followed by the check on the redirected interface against the bandwidth limits defined under the redirected interface. In the HMCAC case, the channel definition policy must be referenced under the redirected interface level.
No policy is referenced.
This command configures the mulitcast CAC policy name.
This command configures the bandwidth for the interface's multicast CAC policy traffic. When disabled (no unconstrained-bw) there will be no checking of bandwidth constraints on the interface level. When enabled and a policy is defined, enforcement is performed. The allocated bandwidth for optional channels should not exceed the unconstrained-bw minus the mandatory-bw and the mandatory channels have to stay below the specified value for the mandatory-bw. After this interface check, the bundle checks are performed.
If the bandwidth value is 0, no mandatory channels are allowed. If bandwidth is not configured, then all mandatory and optional channels are allowed.
If the value of mandatory-bw is equal to the value of bandwidth, then all the unconstrained bandwidth on a given interface is allocated to mandatory channels configured through multicast CAC policy on that interface and no optional groups (channels) are allowed.
The value of mandatory-bw should always be less than or equal to that of bandwidth, An attempt to set the value of mandatory-bw greater than that of bandwidth, will result in inconsistent value error.
This command configures the query source IP address for the group interface. This IP address overrides the source IP address configured at the router level.
The no form of the command removes the IP address.
n/a
This command enables the IGMP traffic from known hosts only.
The no form of the command disable the IGMP traffic from known hosts only
This command enables local subnet checking for IGMP.
The no form of the command disables local subnet checking for IGMP.
This command configures the version of IGMP.
The no form of the command removes the version.
This command configures the query source IP address for all group interfaces.
The no form of the command removes the IP address.
n/a
This command enables the context to configure IGMP interface parameters.
This command imports a policy to filter IGMP packets. The no form of the command removes the policy association from the IGMP instance.
no import — No import policy specified.
The specified name(s) must already be defined.
This command specifies the maximum number of groups for which IGMP can have local receiver information based on received IGMP reports on this interface. When this configuration is changed dynamically to a value lower than the currently accepted number of groups, the groups that are already accepted are not deleted. Only new groups will not be allowed.
0, no limit to the number of groups
This command tests forwarding on an interface without a receiver host. When enabled, data is forwarded to an interface without receiving membership reports from host members.
n/a
This command adds a static multicast group either as a (*,G) or one or more (S,G) records. Use IGMP static group memberships to test multicast forwarding without a receiver host. When IGMP static groups are enabled, data is forwarded to an interface without receiving membership reports from host members.
When static IGMP group entries on point-to-point links that connect routers to a rendezvous point (RP) are configured, the static IGMP group entries do not generate join messages toward the RP.
n/a
This command specifies an IPv4 unicast address that sends data on an interface. This enables a multicast receiver host to signal a router the group is to receive multicast traffic from, and from the sources that the traffic is expected.
The source command is mutually exclusive with the specification of individual sources for the same group.
The source command in combination with the group is used to create a specific (S,G) static group entry.
Use the no form of the command to remove the source from the configuration.
n/a
This command adds a static (*,G) entry. This command can only be enabled if no existing source addresses for this group are specified.
Use the no form of the command to remove the starg entry from the configuration.
n/a
This command enables subnet checking for IGMP messages received on this interface. All IGMP packets with a source address that is not in the local subnet are dropped.
enabled
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.
3
This command specifies the frequency that the querier router transmits general host-query messages. The host-query messages solicit group membership information and are sent to the all-systems multicast group address, 224.0.0.1.
125
This command configures the frequency at which the querier sends group-specific query messages including messages sent in response to leave-group messages. The lower the interval, the faster the detection of the loss of the last member of a group.
1
This command specifies how long the querier router waits to receive a response to a host-query message from a host.
10
This command configures the robust count. The robust-count variable allows tuning for the expected packet loss on a subnet. If a subnet anticipates losses, the robust-count variable can be increased.
2
This command enables the context to configure group ranges which are translated to SSM (S,G) entries. If the static entry needs to be created, it has to be translated from a IGMPv1 IGMPv2 request to a Source Specific Multicast (SSM) join. An SSM translate source can only be added if the starg command is not enabled. An error message is generated if you try to configure the source command with starg command enabled.
This command is used to configure group ranges which are translated to SSM (S,G) entries.
This command specifies the source IP address for the group range. Whenever a (*,G) report is received in the range specified by grp-range start and end parameters, it is translated to an (S,G) report with the value of this object as the source address.
This command enables the context to configure IGMP host tracking parameters.
This command configures the time that the system continues to track inactive hosts.
The no form of the command removes the values from the configuration.
no expiry-time
This command associates an import policy to filter IGMP packets.
The no form of the command removes the values from the configuration.
no import
This command configures the maximum number of multicast groups allowed to be tracked.
The no form of the command removes the values from the configuration.
no max-num-groups
This command configures the maximum number of multicast sources allowed to be tracked per group.
The no form of the command disables the check.
no max-num-grp-sources
This command specifies the maximum number of multicast sources allowed to be tracked per group.
The no form of the command reverts to the default.
no max-num-sources
This command controls the method by which service labels are allocated to routes exported by the VPRN as BGP-VPN routes. The vrf option selects service label per VRF mode while the next-hop option selects service label per next-hop mode.
The no form of the command sets the mode to the default mode of service label per VRF.
no label-mode
This command specifies the maximum number of remote IPv6 routes that can be held within a VPN routing/ forwarding (VRF) context. The local, host, static and aggregate routes are not counted.
The VPRN service ID must be in a shutdown state in order to modify maximum-routes command parameters.
If the log-only parameter is not specified and the maximum-routes value is set below the existing number of routes in a VRF, then the offending RIP peer (if applicable) is brought down (but the VPRN instance remains up). BGP peering will remain up but the exceeding BGP routes will not be added to the VRF.
The maximum route threshold can dynamically change to increase the number of supported routes even when the maximum has already been reached. Protocols will resubmit their routes which were initially rejected.
The no form of the command disables any limit on the number of routes within a VRF context. Issue the no form of the command only when the VPRN instance is shutdown.
0 or disabled — The threshold will not be raised.
This command specifies the maximum number of remote routes that can be held within a VPN routing/ forwarding (VRF) context. The local, host, static and aggregate routes are not counted.
The VPRN service ID must be in a shutdown state in order to modify maximum-routes command parameters.
If the log-only parameter is not specified and the maximum-routes value is set below the existing number of routes in a VRF, then the offending RIP peer (if applicable) is brought down (but the VPRN instance remains up). BGP peering will remain up but the exceeding BGP routes will not be added to the VRF.
The maximum route threshold can dynamically change to increase the number of supported routes even when the maximum has already been reached. Protocols will resubmit their routes which were initially rejected.
The no form of the command disables any limit on the number of routes within a VRF context. Issue the no form of the command only when the VPRN instance is shutdown.
0 or disabled — The threshold will not be raised.
This command configures multicast information policy.
This command specifies the maximum number of multicast routes that can be held within a VPN routing/forwarding (VRF) context. When this limit is reached, a log and SNMP trap are sent. If the log-only parameter is not specified and the maximum-routes value is set below the existing number of routes in a VRF, then no new joins will be processed.
The no form of the command disables the limit of multicast routes within a VRF context. Issue the no form of the command only when the VPRN instance is shutdown.
no mc-maximum-routes
This command enables the context to configure network parameters for the VPRN service.
This command enables the context to configure network ingress parameters for the VPRN service.
This command configures a network ingress filter for IPv4 or IPv6 traffic arriving over explicitly defined spokes or auto-bind network interfaces for the VPRN service.
The no form of the command removes an IPv4, IPv6, or both filters.
no filter
This command enables the context to configure PTP parameters for the VPRN service.
This command specifies an upper limit to the number of discovered peers permitted within the routing instance. This can be used to ensure that a routing instance does not consume all the possible discovered peers and blocking discovered peers in other routing instances.
If it is desired to reserve a fixed number of discovered peers per router instance, then all router instances supporting PTP should have values specified with this command and the sum of all the peer-limit values must not exceed the maximum number of discovered peers supported by the system.
If the user attempts to specify a peer-limit, and there are already more discovered peers in the routing instance than the new limit being specified, the configuration will not be accepted.
no limit
This command configures a remote PTP peer. It provides the context to configure parameters for the remote PTP peer.
Up to 20 remote PTP peers may be configured.
The no form of the command deletes the specified peer.
If the clock-type is ordinary slave or boundary, and PTP is no shutdown, the last peer cannot be deleted. This prevents the user from having PTP enabled without any peer configured and enabled.
Peers are created within the routing instance associated with the context of this command. All configured PTP peers must use the same routing instance.
n/a
This command configures the message interval used for unicast event messages. It defines the message interval for both Sync and Delay_Resp messages that are requested during unicast negotiation to the specific peer. This controls the Sync and Delay_Resp message rate sent from remote peers to the local node. It does not affect the Sync or Delay_Resp packet rate that may be sent from the local node to remote peers. Remote peers may request a Sync or Delay_Resp packet rate anywhere within the acceptable grant range.
The log-sync-interval cannot be changed unless the peer is shutdown.
This command only applies to the 7450 ESS and 7750 SR.
-6 (64 packets per second) for 1588-2008 or
-6 (64 packets per second) for g8265dot1-2010 or
-4 (16 packets per second) for g8275dot1-2014
This command configures the local priority used to choose between PTP masters in the best master clock algorithm (BMCA). This setting is relevant when the profile is set to either g8265dot1-2010 or g8275dot1-2014. The parameter is ignored when any other profile is selected.
The value 1 is the highest priority and 255 is the lowest priority. The priority of a peer cannot be configured if the PTP profile is ieee1588-2008.
For g8265dot1-2010, this parameter configures the priority used to choose between master clocks with the same quality (see G.8265.1 for more details).
For g8275dot1-2014, this parameter sets the value of the localPriority associated with the Announce messages received from external clocks (ptp>peer or ptp>port), or the local clock (ptp). See G.8275.1 for more detailed information.
128
This command associate reassembly-group consisting of multiple ISAs with the
routing context in which the application requiring reassembly service resides.
no reassembly-group
This command sets the identifier attached to routes the VPN belongs to. Each routing instance must have a unique (within the carrier’s domain) route distinguisher associated with it. A route distinguisher must be defined for a VPRN to be operationally active.
Alternatively, the auto-rd option allows the system to automatically generate a Route Distinguisher (RD) based on the bgp-auto-rd-range command configured at the service level.
no route-distinguisher
This command sets the router ID for a specific VPRN context.
When configuring the router ID in the base instance of OSPF it overrides the router ID configured in the config>router context. The default value for the base instance is inherited from the configuration in the config>router context. If the router ID in the config>router context is not configured, the following applies:
If neither the router ID nor system interface are defined, the router ID from the base router context is inherited.
This is a required command when configuring multiple instances and the instance being configured is not the base instance.
When configuring a new router ID, the instance is not automatically restarted with the new router ID. The next time the instance is initialized, the new router ID is used.
To force the new router ID to be used, issue the shutdown and no shutdown commands for the instance, or reboot the entire router.
It is possible to configure an SR OS to operate with an IPv6 only BOF and no IPv4 system interface address. When configured in this manner, the operator must explicitly define IPv4 router IDs for protocols such as OSPF and BGP as there is no mechanism to derive the router ID from an IPv6 system interface address.
The no form of the command removes the router ID definition from the given VPRN context.
no router-id
This command configures an optional service name, up to 64 characters in length, which adds a name identifier to a given service to then use that service name in configuration references as well as display and use service names in show commands throughout the system. This helps the service provider/administrator to identify and manage services within the 7450 ESS and 7750 SR platforms.
All services are required to assign a service ID to initially create a service. However, either the service ID or the service name can be used to identify and reference a given service once it is initially created.
This command enables the context to configure DSCP/Dot1p re-marking for self-generated traffic.
This command configures DSCP/Dot1p re-marking for self-generated traffic. When an application is configured using this command, then the specified DSCP name/value is used for all packets generated by this application within the router instance it is configured.
Using the value configured in this command:
Only one DSCP name/value can be configured per application, if multiple entries are configured then the subsequent entry overrides the previous configured entry.
The no form of this command reverts back to the default value.
This command creates a mapping between the DiffServ Code Point (DSCP) of the self generated traffic and the forwarding class.
Self generated traffic that matches the specified DSCP will be assigned to the corresponding forwarding class. Multiple commands can be entered to define the association of some or all sixty-four DiffServ code points to the forwarding class. For undefined code points, packets are assigned to the forwarding class specified under the default-action command.
All DSCP names that defines a DSCP value must be explicitly defined.
The no form of this command removes the DiffServ code point to forwarding class association. The default-action then applies to that code point value.
n/a
This command configures OSPF, OSPFv3 and IS-IS to set overload when the router has fewer than the full set of SFMs functioning, which reduces forwarding capacity. Setting overload enables a router to still participate in exchanging routing information, but routes all traffic away from it.
The conditions to set overload are as follows:
The no form of this command configures the router to not set overload if an SFM fails.
no single-sfm-overload
This command enables the context to configure SNMP parameters for this VPRN.
This command enables/disables SNMP access on the VPRN interface. This command allows SNMP queries destined to the VPRN interface IP addresses for this VPRN (including VPRN interfaces that are bound to R-VPLS services) to be processed by the SNMP agent on the router. SNMP queries that arrive on VPRN interfaces but are destined to IP addresses in the Base routing context that can be accessed in the VPRN (for example, the router system address via grt leaking) do not require snmp-access to be enabled but do require allow-local-management to be enabled.
Refer to the 7450 ESS, 7750 SR, and 7950 XRS System Management Guide for detailed information about SNMP.
This command sets the SNMP community name(s) to be used with the associated VPRN instance. These VPRN community names are used to associate SNMP v1/v2c requests with a particular vprn context and to return a reply that contains VPRN-specific data or limit SNMP access to data in a specific VPRN instance.
VPRN snmp communities configured with an access permission of 'r' are automatically associated with the default access group "snmp-vprn-ro” and the “vprn-view” view (read only). VPRN snmp communities configured with an access permission of 'rw' are automatically associated with the default access group "snmp-vprn” and the “vprn-view” view (read/write).
The community in an SNMP v1/v2 request determines the SNMP context (i.e., the vprn# for accessing SNMP tables) and not the VPRN of the incoming interface on which the request was received. When an SNMP request arrives on VPRN 5 interface “ringo” with a destination IP address equal to the “ringo” interface, but the community in the SNMP request is the community configured against VPRN 101, then the SNMP request will be processed using the VPRN 101 context. (the response will contain information about VPRN 101). It is recommended to avoid using a simple series of vprn snmp-community values that are similar to each other (for example, avoid my-vprncomm-1, my-vprn-comm-2, etc).
The no form of the command removes the SNMP community name from the given VPRN context.
n/a — The SNMP community must be explicitly specified.
This command enables the context to specify the source address and application that should be used in all unsolicited packets.
This command specifies the source address and application.
This command specifies the IPv6 source address and application.
This command creates a static route entry for both the network and access routes. A prefix and netmask must be specified.
Once the static route context for the specified prefix and netmask has been created, additional parameters associated with the static route(s) may be specified through the inclusion of additional static-route parameter commands
The no form of the command deletes the static route entry. If a static route needs to be removed when multiple static routes exist to the same destination, then as many parameters to uniquely identify the static route must be entered
IPv6 static routes are not supported on the 7450 ESS except in mixed mode.
No static routes are defined.
ipv4-prefix | a.b.c.d (host bits must be 0) |
ipv4-prefix-length | 0 to 32 |
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
ipv6-prefix-length | 0 to 128 |
ipv4-prefix | a.b.c.d (host bits must be 0) |
ipv4-prefix-length | 0 to 32 |
This command specifies the directly connected next hop IP address or interface used to reach the destination. If the next hop is over an unnumbered interface or a point-to-point interface, the ip-int-name of the unnumbered or point-to-point interface (on this node) can be configured.
If the next hop is over an unnumbered interface in the 7450 ESS router, the ip-int-name of the unnumbered interface (on this node) can be configured.
The configured ip-address can be either on the network side or the access side on this node. The address must be associated with a network directly connected to a network configured on this node.
no next-hop
ip-int-name | 32 characters max |
ipv4-address | a.b.c.d |
ipv6-address | x:x:x:x:x:x:x:x-[interface] |
x:x:x:x:x:x:d.d.d.d[-interface] | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
| interface: 32 characters maximum, mandatory for link local addresses |
This command specifies that the route is indirect and specifies the next hop IP address used to reach the destination.
The configured ip-address is not directly connected to a network configured on this node. The destination can be reached via multiple paths. The indirect address can only resolved from dynamic routing protocol. Another static route cannot be used to resolve the indirect address.
The ip-address configured here can be either on the network side or the access side and is typically at least one hop away from this node.
no indirect
ipv4-address | a.b.c.d |
ipv6-address | x:x:x:x:x:x:x:x-[interface] |
This command specifies that the route is a black hole route. If the destination address on a packet matches this static route, it will be silently discarded.
no black-hole
This command creates a static route in a VPRN service context that points to the global routing context (base router). This is primarily used to allow traffic that ingress through a VPRN service to be routed out of the global routing context.
This next-hop type cannot be used in conjunction with any other next-hop types.
no grt
This command creates a static route in a VPRN service context that points to the global routing context (base router). This is primarily used to allow traffic that ingress through a VPRN service to be routed out of the global routing context.
This next-hop type cannot be used in conjunction with any other next-hop types.
no ipsec-tunnel
This command associates the static route state to a BFD session between the local system and the configured nexthop.
The remote end of the BFD session must also be configured to originate or accept the BFD session controlling the static route state.
The no form of this command removes the association of the static route state to that of the BFD session.
no bfd-enable
This configuration option associates a BGP community with the static route. The community can be matched in route policies and is automatically added to BGP routes exported from the static route.
The no form of this command removes the community association.
no community
comm-id | asn:comm-val, well-known-comm |
asn | 0 to 65535 |
comm-val | 0 to 65535 |
well-known-comm | no-advertise, no-export, no-export-subconfed |
This command enables CPE-check and specifies the IP address of the target CPE device.
This option initiates a background ICMP ping test to the configured target IP address. The IP address can either be an IPv4 address for IPv4 static routes or an IPv6 address for IPv6 static routes. The target-ip-address cannot be in the same subnet as the static route subnet itself to avoid possible circular references. This option is mutually exclusive with BFD support on a given static route.
The no form of this command disables the cpe-check option.
no cpe-check
This optional parameter specifies the number of consecutive ping-replies that must be missed to declare the CPE down and to deactivate the associated static route.
3
This optional parameter specifies the interval between ICMP pings to the target IP address.
1
This optional parameter specifies the amount of padding to add to the ICMP packet in bytes. The parameter is only applicable when the cpe-check option is used with the associated static route.
0
This optional parameter enables the ability to log transitions between active and in-active based on the CPE connectivity check. Events will be sent to the system log, syslog and SNMP traps.
no log
This command creates a text description stored in the configuration file for a configuration context.
The no form of the command removes the description string from the context
no description
This command configures the policy accounting destination-class index to be used when incrementing accounting statistic for traffic matching the associated static route.
The no form of the command removes the associated destination-class from the associated static route nexthop.
no destination-class
This optional command causes the ICMP unreachable messages to be sent when received packets match the associated static route. By default, the ICMP unreachable messages for those types of static routes are not generated.
This command can only be associated with a static route that has a black-hole next-hop
The no form of this command removes the black-hole next-hop from static route configuration.
no generate-icmp
This command specifies the enqueuing forwarding class that should be associated with traffic matching the associate static route. If this parameter is not specified, the packet will use the forwarding-class association based on default classification or other QoS Policy associations.
no forwarding-class
This command extends the LDP synchronization feature to a static route. When an interface comes back up, it is possible that a preferred static route using the interface as next-hop for a given prefix is enabled before the LDP adjacency to the peer LSR comes up on this interface. In this case, traffic on an SDP that uses the static route for the far-end address would be black-holed until the LDP session comes up and the FECs exchanged.
This option when enabled delays the activation of the static route until the LDP session comes up over the interface and the ldp-sync-timer configured on that interface has expired
no ldp-sync
This command specifies the cost metric for the static route, expressed as a decimal integer. This value is used when importing the static route into other protocols such as OSPF. When the metric is configured as 0 then the metric configured in OSPF, default-import-metric, applies. When modifying the metric of an existing static route, the preference will not change unless specified. This value is also used to determine which static route to install in the forwarding table.
If there are multiple static routes with the same preference but different metrics then the lower cost (metric) route will be installed.
The no form of this command returns the metric to the default value
no ldp-sync
This command specifies the route preference to be assigned to the associated static route. The lower the preference value the more preferred the route is considered.
Table 37 shows the default route preference based on the route source.
Label | Preference | Configurable |
Direct attached | 0 | No |
Static route | 5 | Yes |
OSPF Internal routes | 10 | Yes |
IS-IS level 1 internal | 15 | Yes |
IS-IS level 2 internal | 18 | Yes |
OSPF external | 150 | Yes |
IS-IS level 1 external | 160 | Yes |
IS-IS level 2 external | 165 | Yes |
BGP | 170 | Yes |
The no form of this command returns the returns the associated static route preference to its default value.
5
This command associates a new constraint to the associated static route such that the static route is only active if any, none, or all of the routes in the prefix list are present and active in the route-table.
no prefix-list
This optional command associates an enqueuing priority with the static route. The options are either high or low, with low being the default. This parameter has the ability to affect the likelihood that a packet will be enqueued at SAP ingress in the face of ingress congestion.
Once a packet is enqueued into an ingress buffer, the significance of this parameter is lost.
priority low
This command causes the static route to be placed in an administratively down state and removed from the active route-table
no shutdown
This command configures the policy accounting source-class index to be used when incrementing accounting statistic for traffic matching the associated static route.
If source route policy accounting is enabled and a source-class index is configured, traffic with a source IP address matches the associated static route, the source accounting statistics for the specified class will be incremented.
The no form of the command removes the associated destination-class from the associated static route nexthop.
no source-class
This command adds a 32-bit integer tag to the associated static route.
The tag value can be used in route policies to control distribution of the route into other protocols.
1
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 will be considered valid and is subject to being placed into the active route-table.
no validate-next-hop
This command enables the context to configure TTL propagation for transit and locally generated packets in a given VPRN routing context.
n/a
This command overrides the global configuration of the TTL propagation for locally generated packets which are forwarded over a MPLS LSPs in a given VPRN service context.
The global configuration is performed under config>router>ttl-propagate>vprn-local.
The default behavior for a given VPRN instance is to inherit the global configuration for the same command. The user can explicitly set the default behavior by configuring the inherit value
inherit
This command overrides the global configuration of the TTL propagation for in transit packets which are forwarded over a MPLS LSPs in a given VPRN service context.
The global configuration is performed under config>router>ttl-propagate>vprn-transit.
The default behavior for a given VPRN instance is to inherit the global configuration for the same command. The user can explicitly set the default behavior by configuring the inherit value.
inherit
This command designates the type of VPRN instance being configured for hub and spoke topologies. Use the no form to reset to the default of a fully meshed VPRN.
no type
This command is used to specify route policies that control how routes are exported from the local VRF to other VRFs on the same or remote PE routers (via MP-BGP). Route policies are configured in the config>router>policy-options context.
The vrf-export command can reference up to 15 objects, where each object is either a policy logical expression or the name of a single policy. The objects are evaluated in the specified order to determine final action to accept or reject the route.
Only one of the 15 objects referenced by the vrf-export command can be a policy logical expression consisting of policy names (enclosed in square brackets) and logical operators (AND, OR, NOT). The first of the 15 objects has a maximum length of 255 characters while the remaining 14 objects have a maximum length of 64 characters each.
When multiple vrf-export commands are issued, the last command entered overrides the previous command.
Aggregate routes are not advertised via MP-BGP protocols to the other MP-BGP peers.
The no form of the command removes all route policy names from the vrf-export list.
no vrf-export
This command is used to specify route policies that control how VPN-IP routes exported by other VRFs, on the same or remote PEs, are imported into the local VRF. Route policies are configured in the config>router>policy-options context.
The vrf-import command can reference up to 15 objects, where each object is either a policy logical expression or the name of a single policy. The objects are evaluated in the specified order to determine final action to accept or reject the route
Only one of the 15 objects referenced by the vrf-import command is allowed to be a policy logical expression consisting of policy names (enclosed in square brackets) and logical operators (AND, OR, NOT). The first of the 15 objects has a maximum length of 255 characters while the remaining 14 objects have a maximum length of 64 characters each.
When multiple vrf-import commands are issued, the last command entered overrides the previous command.
The no form of the command removes all route policy names from the import list
Note that unless the preference value is changed by the policy, BGP-VPN routes imported with a vrf-import policy have the preference value of 170 when imported from remote PE routers, or retain the protocol preference value of the exported route when imported from other VRFs on the same router.
no vrf-import
This command facilitates a simplified method to configure the route target to be added to advertised routes or compared against received routes from other VRFs on the same or remote PE routers (via MP-BGP).
BGP-VPN routes imported with a vrf-target statement will use the BGP preference value of 170 when imported from remote PE routers, or retain the protocol preference value of the exported route when imported from other VRFs in the same router.
Specified vrf-import or vrf-export policies override the vrf-target policy.
The no form of the command removes the vrf-target
no vrf-target
<ext-community> | : target:{<ip-addr:comm-val> | <2byte-asnumber:ext-comm-val> | <4byte-asnumber:comm-val>} | |
ip-addr: | a.b.c.d | |
comm-val: | [0 to 65535] | |
2byte-asnumber: | [0 to 65535] | |
ext-comm-val: | [0 to 4294967295] | |
4byte-asnumber: | [0 to 4294967295] |
This command enables weighted load-balancing for IS-IS ECMP routes in the VPRN instance. Weighted ECMP can be performed only when all the next-hops are associated with the same neighbor and all of them are configured with (non-zero) load-balancing weights. The weighted ECMP support for IS-IS ECMP routes applies to both IPv4 and IPv6.
The no form of the command restores regular ECMP spraying of packets to IS-IS route destinations.
no weighted-ecmp
This command enables the context to configure IPSec policies.
n/a
This command configures a security policy to use for an IPSec tunnel.
n/a
This command configures an IPSec security policy entry.
This command configures the local (from the VPN ) IP prefix/mask for the policy parameter entry.
Only one entry is necessary to describe a potential flow. The local-ip and remote-ip commands can be defined only once. The system will evaluate the local IP as the source IP when traffic is examined in the direction of VPN to the tunnel and as the destination IP when traffic flows from the tunnel to the VPN. The remote IP will be evaluated as the source IP when traffic flows from the tunnel to the VPN when traffic flows from the VPN to the tunnel.
This command configures the remote (from the tunnel) IP prefix/mask for the policy parameter entry.
Only one entry is necessary to describe a potential flow. The local-ip and remote-ip commands can be defined only once. The system will evaluate the local IP as the source IP when traffic is examined in the direction of VPN to the tunnel and as the destination IP when traffic flows from the tunnel to the VPN. The remote IP will be evaluated as the source IP when traffic flows from the tunnel to the VPN when traffic flows from the VPN to the tunnel.
This command creates a logical IP routing interface for a Virtual Private Routed Network (VPRN). Once created, attributes like an IP address and service access point (SAP) can be associated with the IP interface.
The interface command, under the context of services, is used to create and maintain IP routing interfaces within VPRN service IDs. The interface command can be executed in the context of an VPRN service ID. The IP interface created is associated with the service core network routing instance and default routing table. The typical use for IP interfaces created in this manner is for subscriber internet access.
Interface names are case sensitive and must be unique within the group of defined IP interfaces defined for config router interface and config service vprn interface. Interface names must not be in the dotted decimal notation of an IP address. For example, the name “1.1.1.1” is not allowed, but “int-1.1.1.1” is allowed. Show commands for router interfaces use either interface names or the IP addresses. Use unique IP address values and IP address names to maintain clarity. It could be unclear to the user if the same IP address and IP address name values are used. Although not recommended, duplicate interface names can exist in different router instances.
The available IP address space for local subnets and routes is controlled with the config router service-prefix command. The service-prefix command administers the allowed subnets that can be defined on service IP interfaces. It also controls the prefixes that may be learned or statically defined with the service IP interface as the egress interface. This allows segmenting the IP address space into config router and config service domains.
When a new name is entered, a new logical router interface is created. When an existing interface name is entered, the user enters the router interface context for editing and configuration.
By default, there are no default IP interface names defined within the system. All VPRN IP interfaces must be explicitly defined. Interfaces are created in an enabled state.
The no form of this command removes IP the interface and all the associated configuration. The interface must be administratively shutdown before issuing the no interface command.
For VPRN services, the IP interface must be shutdown before the SAP on that interface may be removed. VPRN services do not have the shutdown command in the SAP CLI context. VPRN service SAPs rely on the interface status to enable and disable them.
This command assigns an IP address/IP subnet to the interface
This command configures the IP maximum transmit unit (packet) for this interface.
The no form of the command returns the default value.
no ip-mtu
This command specifies an IPSec tunnel name. An IPSec client sets up the encrypted tunnel across public network. The 7750 SR IPSec MDA acts as a concentrator gathering, and terminating these IPSec tunnels into an IES or VPRN service. This mechanism allows as service provider to offer a global VPRN service even if node of the VPRN are on an uncontrolled or insecure portion of the network.
n/a
This command specifies whether this IPSec tunnel is the BFD designated tunnel.
n/a
This command assign a BFD session provide heart-beat mechanism for given IPsec tunnel. There can be only one BFD session assigned to any given IPsec tunnel, but there can be multiple IPsec tunnels using same BFD session. BFD control the state of the associated tunnel, if BFD session goes down, system will also bring down the associated non-designated IPsec tunnel.
n/a
This command specifies whether to clear the Do not Fragment (DF) bit in the outgoing packets in this tunnel.
This command enables dynamic keying for the IPsec tunnel.
n/a
This command specifies whether to attempt to establish a phase 1 exchange automatically.
The no form of the command disables the automatic attempts to establish a phase 1 exchange.
no auto-establish
This command specifies the local id of the 7750 SR used for IDi or IDr for IKEv2 tunnels.
The local-id command can only be changed or removed when tunnel or gw is shutdown. The default value depends on the local-auth-method such as:
no local-id
This command associates the IPSec transform sets allowed for this tunnel. A maximum of four transforms can be specified. The transforms are listed in decreasing order of preference (the first one specified is the most preferred).
n/a
This command specifies the local gateway address used for the tunnel and the address of the remote security gateway at the other end of the tunnel remote peer IP address to use.
The base routing context is used if the delivery-router option is not specified.
This command configures Security Association (SA) for manual keying. When enabled, the command specifies whether this SA entry is created manually by the user or dynamically by the IPsec sub-system.
n/a
This command configures the information required for manual keying SA creation.
n/a
This command specifies the size of the anti-replay window. The anti-replay window protocol secures IP against an entity that can inject messages in a message stream from a source to a destination computer on the Internet.
n/a
This command configures an IPSec security policy. The policy may then be associated with tunnels defined in the same context.
n/a
This command enables the context to configure event stream logging.
This command creates a context for an event filter. An event filter specifies whether to forward or drop an event or trap based on the match criteria.
Filters are configured in the filter filter-id context and then applied to a log in the log-id log-id context. Only events for the configured log source streams destined to the log ID where the filter is applied are filtered.
Any changes made to an existing filter, using any of the sub-commands, are immediately applied to the destinations where the filter is applied.
The no form of the command removes the filter association from log IDs which causes those logs to forward all events.
No event filters are defined.
The default action specifies the action that is applied to events when no action is specified in the event filter entries or when an event does not match the specified criteria.
When multiple default-action commands are entered, the last command overwrites the previous command.
The no form of the command reverts the default action to the default value (forward).
default-action forward — the events which are not explicitly dropped by an event filter match are forwarded
This command is used to create or edit an event filter entry. Multiple entries may be created using unique entry-id numbers. The -TiMOS implementation exits the filter on the first match found and executes the action in accordance with the action command.
Comparisons are performed in an ascending entry ID order. When entries are created, they should be arranged sequentially from the most explicit entry to the least explicit. Matching ceases when a packet matches an entry. The entry action is performed on the packet, either drop or forward. To be considered a match, the packet must meet all the conditions defined in the entry.
An entry may not have any match criteria defined (in which case, everything matches) but must have at least the keyword action for it to be considered complete. Entries without the action keyword will be considered incomplete and are rendered inactive.
The no form of the command removes the specified entry from the event filter. Entries removed from the event filter are immediately removed from all log-id’s where the filter is applied.
No event filter entries are defined. An entry must be explicitly configured.
This command specifies a drop or forward action associated with the filter entry. If neither drop nor forward is specified, the default-action will be used for traffic that conforms to the match criteria. This could be considered a No-Op filter entry used to explicitly exit a set of filter entries without modifying previous actions.
Multiple action statements entered will overwrite previous actions.
The no form of the command removes the specified action statement.
Action specified by the default-action command will apply.
This command creates context to enter/edit match criteria for a filter entry. When the match criteria is satisfied, the action associated with the entry is executed.
If more than one match parameter (within one match statement) is specified, then all the criteria must be satisfied (AND functional) before the action associated with the match is executed.
Use the match command to display a list of the valid applications.
Match context can consist of multiple match parameters (application, event-number, severity, subject), but multiple match statements cannot be entered per entry.
The no form of the command removes the match criteria for the entry-id.
no match
This command adds an OS application as an event filter match criterion.
An OS application is the software entity that reports the event. Applications include IP, MPLS, OSPF, CLI, SERVICES etc. Only one application can be specified. The latest application command overwrites the previous command.
The no form of the command removes the application as a match criterion.
no application — no application match criterion is specified
eq | equal to |
neq | not equal to |
This command adds system messages as a match criterion.
The no form of the command removes messages as a match criterion.
This command adds an SR OS application event number as a match criterion.
SR OS event numbers uniquely identify a specific logging event within an application.
Only one number command can be entered per event filter entry. The latest number command overwrites the previous command.
The no form of the command removes the event number as a match criterion.
no event-number — no event ID match criterion is specified
Operator | Note |
eq | equal to |
neq | not equal to |
lt | less than |
lte | less than or equal to |
gt | greater than |
gte | greater than or equal to |
This command adds an event severity level as a match criterion. Only one severity command can be entered per event filter entry. The latest severity command overwrites the previous command.
The no form of the command removes the severity match criterion.
no severity — no severity level match criterion is specified
Operator | Notes |
eq | equal to |
neq | not equal to |
lt | less than |
lte | less than or equal to |
gt | greater than |
gte | greater than or equal to |
Severity Number | Severity Name |
1 | cleared |
2 | indeterminate (info) |
3 | critical |
4 | major |
5 | minor |
6 | warning |
This command adds an event subject as a match criterion.
The subject is the entity for which the event is reported, such as a port. In this case the port-id string would be the subject. Only one subject command can be entered per event filter entry. The latest subject command overwrites the previous command.
The no form of the command removes the subject match criterion.
no subject — no subject match criterion specified
Operator | Notes |
eq | equal to |
neq | not equal to |
When regexp keyword is not specified, the subject command string is matched exactly by the event filter.
This command creates a context to configure destinations for event streams.
The log-id context is used to direct events, alarms/traps, and debug information to respective destinations.
A maximum of 10 logs can be configured.
Before an event can be associated with this log-id, the from command identifying the source of the event must be configured.
Only one destination can be specified for a log-id. The destination of an event stream can be an in-memory buffer, console, session, snmp-trap-group, syslog, or file.
Use the event-control command to suppress the generation of events, alarms, and traps for all log destinations.
An event filter policy can be applied in the log-id context to limit which events, alarms, and traps are sent to the specified log-id.
Log-IDs 99 and 100 are created by the agent. Log-ID 99 captures all log messages. Log-ID 100 captures log messages with a severity level of major and above.
Log-ID 99 provides valuable information for the admin-tech file. Removing or changing the log configuration may hinder debugging capabilities. It is strongly recommended not to alter the configuration for Log-ID 99.
The no form of the command deletes the log destination ID from the configuration.
No log destinations are defined.
This is one of the commands used to specify the log ID destination. This parameter is mandatory when configuring a log destination. This command instructs the alarms and traps to be directed to the snmp-trap-group associated with log-id.
A local circular memory log is always maintained for SNMP notifications sent to the specified snmp-trap-group for the log-id.
The source of the data stream must be specified in the from command prior to configuring the destination with the to command.
The to command cannot be modified or re-entered. If the destination or maximum size of an SNMP or memory log needs to be modified, the log ID must be removed and then re-created.
n/a
This is one of the commands used to specify the log ID destination. This parameter is mandatory when configuring a log destination.
This command instructs the alarms and traps to be directed to a specified syslog. To remain consistent with the standards governing syslog, messages to syslog are truncated to 1k bytes.
The source of the data stream must be specified in the from command prior to configuring the destination with the to command.
The to command cannot be modified or re-entered. If the destination or maximum size of an SNMP or memory log needs to be modified, the log ID must be removed and then re-created.
n/a
This command selects the source stream to be sent to a log destination.
One or more source streams must be specified. The source of the data stream must be identified using the from command before you can configure the destination using the to command. The from command can identify multiple source streams in a single statement (for example: from main change debug-trace).
Only one from command may be entered for a single log-id. If multiple from commands are configured, then the last command entered overwrites the previous from command.
The no form of the command removes all previously configured source streams.
No source stream is configured.
This command specifies whether the time should be displayed in local or Coordinated Universal Time (UTC) format.
time-format utc
This command creates the context to configure a syslog target host that is capable of receiving selected syslog messages from this network element.
A valid syslog-id must have the target syslog host address configured.
A maximum of 10 syslog-ids can be configured.
No log events are sent to a syslog target address until the syslog-id has been configured as the log destination (to) in the log-id node.
The syslog ID configured in the configure/service/vprn context has a local VPRN scope and only needs to be unique within the specific VPRN instance. The same ID can be reused under a different VPRN service or in the global log context under config>log.
No syslog IDs are defined.
This command adds the syslog target host IP address to/from a syslog ID.
This parameter is mandatory. If no address is configured, syslog data cannot be forwarded to the syslog target host.
Only one address can be associated with a syslog-id. If multiple addresses are entered, the last address entered overwrites the previous address.
The same syslog target host can be used by multiple log IDs.
The no form of the command removes the syslog target host IP address.
no address — There is no syslog target host IP address defined for the syslog ID.
ipv4-address | a.b.c.d |
ipv6-address | x:x:x:x:x:x:x:x[-interface] |
x:x:x:x:x:x:d.d.d.d[-interface] | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
interface: 32 characters maximum, mandatory for link local addresses |
This command configures the facility code for messages sent to the syslog target host.
Multiple syslog IDs can be created with the same target host but each syslog ID can only have one facility code. If multiple facility codes are entered, the last facility-code entered overwrites the previous facility-code.
If multiple facilities need to be generated for a single syslog target host, then multiple log-id entries must be created, each with its own filter criteria to select the events to be sent to the syslog target host with a given facility code.
The no form of the command reverts to the default value.
local7 — syslog entries are sent with the local7 facility code
Numerical Code | Facility Code |
0 | kernel |
1 | user |
2 | |
3 | systemd |
4 | auth |
5 | syslogd |
6 | printer |
7 | net-news |
8 | uucp |
9 | cron |
10 | auth-priv |
11 | ftp |
12 | ntp |
13 | log-audit |
14 | log-alert |
15 | cron2 |
16 | local0 |
17 | local1 |
18 | local2 |
19 | local3 |
20 | local4 |
21 | local5 |
22 | local6 |
23 | local7 |
This command adds the string prepended to every syslog message sent to the syslog host.
RFC3164, The BSD syslog Protocol, allows a alphanumeric string (tag) to be prepended to the content of every log message sent to the syslog host. This alphanumeric string can, for example, be used to identify the node that generates the log entry. The software appends a colon (:) and a space to the string and it is inserted in the syslog message after the date stamp and before the syslog message content.
Only one string can be entered. If multiple strings are entered, the last string overwrites the previous string. The alphanumeric string can contain lowercase (a-z), uppercase (A-Z) and numeric (0-9) characters.
The no form of the command removes the log prefix string.
no log-prefix — no prepend log prefix string defined
This command configures the syslog message severity level threshold. All messages with severity level equal to or higher than the threshold are sent to the syslog target host.
Only a single threshold level can be specified. If multiple levels are entered, the last level entered will overwrite the previously entered commands.
The no form of the command reverts to the default value.
Router severity level | Numerical Severity (highest to lowest) | Configured Severity | Definition |
0 | emergency | system is unusable | |
3 | 1 | alert | action must be taken immediately |
4 | 2 | critical | critical condition |
5 | 3 | error | error condition |
6 | 4 | warning | warning condition |
5 | notice | normal but significant condition | |
1 cleared 2 indeterminate | 6 | info | informational messages |
7 | debug | debug-level messages |
This command configures the UDP port that will be used to send syslog messages to the syslog target host.
The port configuration is needed if the syslog target host uses a port other than the standard UDP syslog port 514.
Only one port can be configured. If multiple port commands are entered, the last entered port overwrites the previously entered ports.
The no form of the command reverts to default value.
no port
This command creates the context to configure a group of SNMP trap receivers and their operational parameters for a given log-id.
A group specifies the types of SNMP traps and specifies the log ID which will receive the group of SNMP traps. A trap group must be configured in order for SNMP traps to be sent.
To suppress the generation of all alarms and traps see the event-control command. To suppress alarms and traps that are sent to this log-id, see the filter command. Once alarms and traps are generated they can be directed to one or more SNMP trap groups. Logger events that can be forwarded as SNMP traps are always defined on the main event source.
The no form of the command deletes the SNMP trap group.
There are no default SNMP trap groups.
This command adds/modifies a trap receiver and configures the operational parameters for the trap receiver. A trap reports significant events that occur on a network device such as errors or failures.
Before an SNMP trap can be issued to a trap receiver, the log-id, snmp-trap-group and at least one snmp-trap-group must be configured.
The snmp-trap-group command is used to add/remove a trap receiver from an snmp-trap-group. The operational parameters specified in the command include:
A single snmp-trap-group log-id can have multiple trap-receivers. Each trap receiver can have different operational parameters.
An address can be configured as a trap receiver more than once as long as a different port is used for each instance.
To prevent resource limitations, only configure a maximum of 10 trap receivers.
If the same trap-target name port port parameter value is specified in more than one SNMP trap group, each trap destination should be configured with a different notify-community value. This allows a trap receiving an application, such as NMS, to reconcile a separate event sequence number stream for each router event log when multiple event logs are directed to the same IP address and port destination.
The no form of the command removes the SNMP trap receiver from the SNMP trap group.
No SNMP trap targets are defined.
ipv4-address | a.b.c.d (host bits must be 0) |
ipv6-address | x:x:x:x:x:x:x:x[-interface] |
x:x:x:x:x:x:d.d.d.d[-interface] | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
interface: 32 characters maximum, mandatory for link local addresses |
The keyword snmpv1 selects the SNMP version 1 format. When specifying snmpv1, the notify-community must be configured for the proper SNMP community string that the trap receiver expects to be present in alarms and traps messages. If the SNMP version is changed from snmpv3 to snmpv1, then the notify-community parameter must be changed to reflect the community string rather than the security-name that is used by snmpv3.
The keyword snmpv2c selects the SNMP version 2c format. When specifying snmpv2c, the notify-community must be configured for the proper SNMP community string that the trap receiver expects to be present in alarms and traps messages. If the SNMP version is changed from snmpv3 to snmpv2c, then the notify-community parameter must be changed to reflect the community string rather than the security-name that is used by snmpv3.
The keyword snmpv3 selects the SNMP version 3 format. When specifying snmpv3, the notify-community must be configured for the SNMP security-name. If the SNMP version is changed from snmpv1 or snmpv2c to snmpv3, then the notify-community parameter must be changed to reflect the security-name rather than the community string used by snmpv1 or snmpv2c.
Pre-existing conditions are checked before the snmpv3SecurityName is accepted. These are:
The keyword no-auth-no-privacy specifies no authentication and no privacy (encryption) are required.
The keyword auth-no-privacy specifies authentication is required but no privacy (encryption) is required. When this option is configured the security-name must be configured for authentication.
The keyword privacy specifies both authentication and privacy (encryption) is required. When this option is configured the security-name must be configured for authentication and privacy.
This command enables the context to configure MVPN-related parameters for the IP VPN.
This command enables MVPN membership auto-discovery through BGP. When auto-discovery is enabled, PIM peering on the inclusive provider tunnel is disabled. Changing auto-discovery configuration requires shutdown of this VPRN instance.
The no form of the command disables MVPN membership auto-discovery through BGP.
default
This command allows optionally to specify a source-address - an IP address to be used by Rosen M-VPN for core diversity non-default IGP instances (not using system IP). Two unique IP addresses for all MVPNs are supported. For instances using default System IP, source address configuration should not be specified to avoid consuming one of the addresses.
Explicitly defined source-address allows GRE-encapsulated Rosen MVPN multicast traffic (Default and Data MDT) to originate from a configured IP address, so the source IP address of the GRE packets won't be the default system IP address.
Value:
This command specifies BGP or PIM, for PE-to-PE signaling of CE multicast states. When this command is set to PIM and neighbor discovery by BGP is disabled, PIM peering will be enabled on the inclusive tree.
Changes may only be made to this command when the mvpn node is shutdown.
The no form of the command reverts it back to the default.
mcast-signaling bgp
This command specifies whether to use inter-site shared C-trees or not. Optional parameters allow enabling additional inter-site shared functionality. Not specifying an optional parameter when executing the command disables that parameter.
intersite-shared
This command allows restricting MVPN instance per PE node to a specific role. By default, MVPN instance on a given PE node assumes the role of being a sender as well as receiver. This creates a mesh of MDT/PMSI across all PE nodes from this PE.
This command provides an option to configure either a sender-only or receiver-only mode per PE node. Restricting the role of a PE node prevents creating full mesh of MDT/PMSI across all PE nodes that are participating in MVPN instance.
auto-rp-discovery cannot be enabled together with mdt-type sender-only or mdt-type receiver-only, or wildcard-spmsi configurations.
The no version of this command restores the default (sender-receiver).
mdt-type sender-receiver
This command enables context to configure list of redundant source prefixes for preferred source selection.
This command configures up to 8 multicast source IPv4 prefixes for preferred source selection. Single or multi-line inputs are allowed.
The no form of the command deletes specified prefix from the list.
No prefixes are specified.
This command enables context to configure list of redundant IPv6 source prefixes for preferred source selection.
This command configures up to 8 multicast source IPv6 prefixes for preferred source selection. Single or multi-line inputs are allowed.
The no form of the command deletes specified prefix from the list
No prefixes are specified.
This command enables context for VRF extranet mapping for C-instance receivers in this receiver MVPN instance to multicast streams in P-instance core MVPN instances.
This command enables context for VRF extranet mapping for C-instance receivers in this receiver MVPN instance to multicast streams in the specified P-instance core MVPN instance.
This command configures multicast group IPv4 prefixes for the MVPN with per-group mapping extranet functionality. Multiple lines are allowed. Duplicate prefixes are ignored.
When the starg option is specified, extranet functionality is enabled for PIM ASM as for the specified group. When the option is not specified (not recommended with PIM ASM), the PIM ASM join will be mapped and data plane will be established, but the control plane will not be updated on SPT switchover, unless the switchover is driven by a CPE router on a receiver side.
The no form of the command deletes specified prefix from the list, or removes mapping of all prefixes if group-prefix any was specified.
n/a
This command enables context to configure tunnel parameters for the MVPN.
This command enables the context for specifying inclusive provider tunnels
This command configures the type of BSR signaling used.
The no form of the command restores the default.
no bsr
This command enables use of mLDP LSP for the provider tunnel.
no mldp
This command administratively disables and enables use of mLDP LSP for the provider tunnel.
no shutdown
This command specifies the PIM mode to use, ASM or SSM, for PIM-based inclusive provider tunnels and the multicast group address to use. Also enables the context for specifying parameters for PIM peering on the inclusive provider tunnel.
Auto-discovery must be enabled in order for SSM to operate.
The no form of the command removes the pim context including the statements under the context.
no pim
This command specifies the interval at which PIM Hello messages are transmitted on the PIM inclusive provider tunnel.
The no form of this command reverts to the default value.
30 seconds
This command specifies the hello multiplier. The hello-multiplier in conjunction with the hello-interval determines the hold time for a PIM neighbor.
Hold time = (hello-interval * hello-multiplier) / 10.
The no form of the command reverts the value to the default.
35
This command enables improved assert procedure on the PIM inclusive provider tunnel.
The no form of the command disables improved assert procedure.
enabled
This command enables PIM three-way hello on the inclusive provider tunnel.
The no form of the command disables the PIM three-way hello.
disabled
This command enables the setting of the T bit in the LAN Prune Delay option of the Hello message. This indicates the router's capability to disable Join message suppression.
The no form of the command disables the setting.
disabled
This command enables the context for specifying RSVP P2MP LSP for the provider tunnel. The no form of the command removes the rsvp context including all the statements in the context.
no rsvp
This command enables unidirectional multi-point BFD session on a sender (Root) PE node for upstream fast failure detection over RSVP-TE P2MP LSP.
This command enables unidirectional multi-point BFD session on a receiver (leaf) PE node for upstream fast failure detection over RSVP-TE P2MP LSP.
This command specifies the use of automatically created P2MP LSP as the provider tunnel. The P2MP LSP will be signaled using the parameters specified in the template, such as bandwidth constraints, etc.
no lsp-template
This command administratively disables and enables use of RSVP P2MP LSP for the provider tunnel.
no shutdown
This command enables RFC 6625 (C-*, C-*) S-PMSI functionality for NG-MVPN. When enabled, (C-*, C-*) S-PMSI is used instead of I-PMSI for this MVPN. Wildcard S-PMSI uses the I-PMSI LSP template.
auto-rp-discovery cannot be enabled together with mdt-type sender-only or mdt-type receiver-only, or wildcard-spmsi configurations.
The no form disables the (C-*, C-*) S-PMSI functionality.
no wildcard-spmsi
This command enables the context to specify selective provider tunnel parameters.
n/a
This command disables C-trees to P-tunnel binding auto-discovery through BGP so it is signaled using PIM join TLVs.
This command requires the c-mcast-signaling parameter to be set to PIM.
For mutli-stream S-PMSI, this command must be enabled for BGP auto-discovery to function.
The no form of the command enables multicast VPN membership auto-discovery through BGP.
no auto-discovery-disable
This command specifies the interval, in seconds, before a PE router connected to the source switches traffic from the inclusive provider tunnel to the selective provider tunnel.
This command is not applicable to multi-stream S-PMSI,
The no form of the command reverts the value to the default.
3 seconds
This command specifies the data rate threshold that triggers the switch from the inclusive provider tunnel to the selective provider tunnel for (C-S, C-G) within the group range. Optionally, PE thresholds for creating/deleting ng-MVPN S-PMSI may also be specified. Omitting the PE thresholds, preserves currently set value (or defaults if never set). Multiple statements (one per a unique group) are allowed in the configuration.
This command is not applicable to multi-stream S-PMSI,
The no form of the command removes the values from the configuration.
no data-threshold
c-grp-ip-addr | : multicast group address a.b.c.d | |
mask | [4 to 32] | |
netmask | : a.b.c.d (network bits all 1 and host bits all 0) | |
s-pmsi-threshold | : [1 to 4294967294](threshold in kbps) | |
c-grp-ipv6-addr | : multicast ipv6-address x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x [0 to FFFF]H | ||
d [0 to 255]D | ||
prefix-length [1 to 128] | ||
pe-threshold-add: | [1 to 65535], if never specified, 65535 is used (add threshold always met) | |
pe-threshold-delete: | [2 to 65535], if never specified, 65535 is used (delete threshold never met) |
This command enables packing of MDT join TLVs into a single PDU to improve efficiency, if multiple join TLVs are available at the time of transmission.
The no form of the command disables packing of MDT join TLVs into a single PDU.
no join-tlv-packing-disable
This command creates a multi-stream S-PMSI policy. Having multiple multi-stream S-PMSIs per MVPN creates a link list, in which the first match (lowest index) will be chosen for a multicast stream. The number of configured multi-stream S-PMSIs cannot exceed the configured maximum S-PMSI for a given MVPN.
This command creates group prefixes that map to the multicast stream. At least one source must be specified for the policy to be active.
ipv4-prefix | a.b.c.d | |
ipv4-prefix-le | [0..32] | |
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x | [0..FFFF]H | |
d | [0..255]D | |
ipv6-prefix-le | [0..128] |
This command creates source prefixes for specific groups that map to the multicast stream.
ipv4-prefix | a.b.c.d | |
ipv4-prefix-le | [0..32] | |
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x | [0..FFFF]H | |
d | [0..255]D | |
| ipv6-prefix-le | [0..128] |
This command creates a RSVP-TE LSP template for S-PSMI. Multi-stream S-PMSIs can share a single template or can each use their own template.
This commands enables multi-stream S-PSMI. At least one group must be active in a policy.
This command specifies the range of PIM-ASM groups to use on the sender PE to setup ASM multicast tree for draft Rosen based Data MDT.
This command enables use of P2MP RSVP as the inclusive or selective provider tunnel.
no rsvp
This command specifies the use of automatically created P2MP LSP as the inclusive or selective provider tunnel. The P2MP LSP will be signaled using the parameters specified in the template, such as bandwidth constraints, etc.
no lsp-template
This command enables use of P2MP mLDP LSP as inclusive or selective PMSI tunnels.
For multi-stream S-PMSI, either LDP or RSVP-TE must first be configured before multi-stream policy can be configured.
no mldp
This command specifies the maximum number of RSVP P2MP or LDP P2MP S-PMSI tunnels for the mVPN. When the limit is reached, no more RSVP P2MP S-PMSI or LDP P2MP S-PMSI is created and traffic over the data-threshold will stay on I-PMSI.
10
This command administratively disables/enables use of P2MP RSVP LSP template or mLDP LSP for inclusive or selective PMSI tunnels.
no shutdown
This command enables Data MDT with PIM-ASM mode on the receiver PE node. PIM-ASM or PIM-SSM operation mode is derived based on the locally configured SSM range on the node.
If asm-mode is disabled using this command, then PIM-SSM mode is enabled for all groups, independent of the configured SSM range on the node.
This command specifies the PIM SSM groups to use for the selective provider tunnel.
This command enables context to configure primary and standby upstream PE association for the MVPN.
This command assigns a standby PE to each primary PE that must be selected as an alternative PE in case the UFD session on tunnel from primary PE is detected down. Standby for a PE cannot be modified without shutting down the MVPN instance.
If a primary PE is not assigned a standby PE then the UMH selection would fall back to the default method.
This command specifies which UMH selection mechanism to use, highest IP address, hash based or provider tunnel status.
The no form of the command resets it back to default.
umh-selection highest-ip
This command specifies the export policy (up to 16) to control MVPN routes exported from the local VRF to other VRFs on the same or remote PE routers.
vrf-export unicast
This command specifies the import policy (up to 16) to control MVPN routes imported to the local VRF from other VRFs on the same or remote PE routers.
vrf-import unicast
This command specifies the route target to be added to the advertised routes or compared against the received routes from other VRFs on the same or remote PE routers. vrf-import or vrf-export policies override the vrf-target policy.
The no form of the command removes the vrf-target.
no vrf-target
target:{ip-address:comm-val | 2byte-asnumber:ext-comm-val | 4byte-asnumber:comm-val} | ||
ip-address: | a.b.c.d | |
comm-val: | 0 to 65535 | |
2byte-asnumber: | 1 to 65535 | |
4byte-asnumber | 0 to 4294967295 |
This command specifies communities to be sent to peers.
target:{ip-address:comm-val | 2byte-asnumber:ext-comm-val | 4byte-asnumber:comm-val} | ||
ip-address: | a.b.c.d | |
comm-val: | 0 to 65535 | |
2byte-asnumber: | 1 to 65535 | |
4byte-asnumber | 0 to 4294967295 |
This command specifies communities to be accepted from peers.
target:{ip-address:comm-val | 2byte-asnumber:ext-comm-val | 4byte-asnumber:comm-val} | ||
ip-address: | a.b.c.d | |
comm-val: | 0 to 65535 | |
2byte-asnumber: | 1 to 65535 | |
4byte-asnumber | 0 to 4294967295 |
This command configures a redundant interface.
This command assigns an IP address mask or netmask and a remote IP address to the interface.
assigns an IP address netmask to the interface
This command configures router advertisement properties. By default, it is disabled for all IPv6 enabled interfaces.
The no form of the command disables all IPv6 interface. However, the no interface interface-name command disables a specific interface.
disabled
This command enables the context for configuration of DNS information for Stateless Address Auto-Configuration (SLAAC) hosts.
When specified at the router-advertisement level in the routing context, this command allows configuration of service-wide parameters. These can then be inherited at the interface level by specifying the config>service>vprn>router-advert>interface>dns-options>include-dns command.
The no form of the command disables configuration of DNS information for Stateless Address Auto-Configuration (SLAAC) hosts.
disabled
This command specifies the IPv6 DNS servers to include in the RDNSS option in Router Advertisements. When specified at the router advertisement level this applies to all interfaces that have include-dns enabled, unless the interfaces have more specific dns-options configured.
n/a
This command enables the Recursive DNS Server (RDNSS) Option in router advertisements. This must be enabled for each interface on which the RDNSS option is required in router advertisement messages.
The no form of the command disables the RDNSS option in router advertisements.
disabled
This command specifies the maximum time that the RDNSS address may be used for name resolution by the client. The RDNSS Lifetime must be no more than twice MaxRtrAdvLifetime with a maximum of 3600 seconds.
rdnss-lifetime infinite
This command configures router advertisement properties on a specific interface. The interface must already exist in the config>router>interface context.
No interfaces are configured by default.
This command configures the current-hop-limit in the router advertisement messages. It informs the nodes on the subnet about the hop-limit when originating IPv6 packets.
64
This command sets the managed address configuration flag. This flag indicates that DHCPv6 is available for address configuration in addition to any address autoconfigured using stateless address autoconfiguration. See RFC 3315, Dynamic Host Configuration Protocol (DHCP) for IPv6.
no managed-configuration
This command configures the maximum interval between sending router advertisement messages.
600
This command configures the minimum interval between sending ICMPv6 neighbor discovery router advertisement messages.
200
This command configures the MTU for the nodes to use to send packets on the link.
no mtu — the MTU option is not sent in the router advertisement messages
This command sets the "Other configuration" flag. This flag indicates that DHCPv6lite is available for autoconfiguration of other (non-address) information such as DNS-related information or information on other servers in the network. See RFC 3736, Stateless Dynamic Host Configuration Protocol (DHCP) for IPv6.
no other-stateful-configuration
This command configures an IPv6 prefix in the router advertisement messages. To support multiple IPv6 prefixes, use multiple prefix statements. No prefix is advertised until explicitly configured using prefix statements.
n/a
ipv4-prefix | a.b.c.d (host bits must be 0) |
ipv4-prefix-length | 0 to 32 |
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
ipv6-prefix-length | 0 to 128 |
This command specifies whether the prefix can be used for stateless address autoconfiguration.
enabled
This command specifies whether the prefix can be used for onlink determination.
enabled
This command configures the remaining length of time in seconds that this prefix will continue to be preferred, such as, time until deprecation. The address generated from a deprecated prefix should not be used as a source address in new communications, but packets received on such an interface are processed as expected.
604800
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.
2592000
This command configures how long this router should be considered reachable by other nodes on the link after receiving a reachability confirmation.
no reachable-time
This command configures the retransmission frequency of neighbor solicitation messages.
no retransmit-time
This command sets the router lifetime.
1800
This command enables sending router advertisement messages using the VRRP virtual MAC address, provided that the virtual router is currently the master.
If the virtual router is not the master, no router advertisement messages are sent.
The no form of the command disables sending router advertisement messages.
no use-virtual-mac
This command enables the context to configure Network Time Protocol (NTP) and its operation. This protocol defines a method to accurately distribute and maintain time for network elements. Furthermore this capability allows for the synchronization of clocks between the various network elements. Use the no form of the command to stop the execution of NTP and remove its configuration.
n/a
This command enables authentication for the NTP server.
This command provides the option to skip the rejection of NTP PDUs that do not match the authentication key-id, type or key requirements. The default behavior when authentication is configured is to reject all NTP protocol PDUs that have a mismatch in either the authentication key-id, type or key.
When authentication-check is enabled, NTP PDUs are authenticated on receipt. However, mismatches cause a counter to be increased, one counter for type and one for key-id, one for type, value mismatches. These counters are visible in a show command.
The no form of this command allows authentication mismatches to be accepted; the counters however are maintained.
authentication-check — rejects authentication mismatches
This command sets the authentication key-id, type and key used to authenticate NTP PDUs sent to or received by other network elements participating in the NTP protocol. For authentication to work, the authentication key-id, type and key value must match.
The no form of the command removes the authentication key.
n/a
Entering the authentication-key command with a key-id value that matches an existing configuration key will result in overriding the existing entry.
Recipients of the NTP packets must have the same authentication key-id, type, and key value in order to use the data transmitted by this node. This is an optional parameter.
The key can be any combination of ASCII characters up to 8 characters in length (unencrypted). If spaces are used in the string, enclose the entire string in quotation marks (“.”).
This is a required parameter; either DES or message-digest must be configured.
This command configures the node to transmit NTP packets on a given interface. Broadcast and multicast messages can easily be spoofed, thus, authentication is strongly recommended.
The no form of this command removes the address from the configuration.
This command configures, creates or deletes a NAT instance.
This command enters the “inside” context to configure the inside NAT instance.
This command configures a destination prefix. An (internal) static route will be created for this prefix. All traffic that hits this route will be subject to NAT. The system will not allow a destination-prefix to be configured if the configured nat-policy refers to an IP pool that resides in the same service (as this would result in a routing loop).
This command enables the context to configure Dual-Stack-Lite NAT parameters.
This command configures a dual-stack-lite IPv6 address
The no form of the command removes the value from the configuration.
n/a
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D |
This command configures the DSLite tunnel MTU for this Dual Stack Lite address.
The no form of the command reverts the default.
1500
This command configures the IPv6 prefix length of the dual-stack-lite subscribers.
The no form of the command reverts the default.
128
This command enables the context to configure parameters specific to Layer 2-aware NAT.
This command configures a Layer 2-aware NAT address. This address will act as a local address of the system. Hosts connected to the inside service will be able to ARP for this address. To verify connectivity, a host can also ping the address. This address is typically used as next hop of the default route of a Layer 2-aware host. The given mask defines a Layer 2-aware subnet. The (inside) IP address used by anLayer 2-aware host must match one of the subnets defined here or it will be rejected.
This command configures the NAT policy that will be used for large-scale NAT in this service.
This command enables the context to configure redundancy parameters.
This command configures the IP address of the NAT redundancy peer in the realm of this virtual router instance.
This command configures specifies the IP address and prefix length of the steering route. The steering route is used in the realm of this virtual router instance as an indirect next-hop for all the traffic that must be routed to the large scale NAT function.
This command enters the “outside” context to configure the outside NAT instance.
This command configures a NAT pool.
This command configures a NAT address range.
This command configures the description for the NAT address range.
This command starts or stops draining this NAT address range. When an address-range is being drained, it will not be used to serve new hosts. Existing hosts, however, will still be able to use the address that was assigned to them even if it is being drained.An address-range can only be deleted if the parent pool is shut down or if the range itself is effectively drained (no hosts are using the addresses anymore).
This command configures the mode of operation of this NAT address pool.
The mode value is only relevant while the value of pool type is equal to largeScale; while the value of pool type is equal to l2Aware, the mode of operation is always NAPT.
This command configures the end of the port range available for port forwarding. The start of the range is always equal to one.
The actual maximum value of the range end may be restricted to less than 65535 depending on the value of the objects port reservation type and port reservation value and on system specifications.
1023
This command configures the size of the port-block that will be assigned to a host that is served by this pool. The number of ports configured here will be available to UDP, TCP and ICMP (as identifiers).
his command installs the export route in the routing table for active NAT pools.
Once the export route is in the routing table, it can be advertised in the network via a routing protocol. NAT pools in the standby or disabled state will not advertise the export route.
A NAT pool will become active when it becomes operationally UP, AND there is no monitoring route (which is also the export route from the peer) present in the routing node (as received from the network). The pool will transition into standby state in case that the monitoring route (or export route from the peer) is already present in the routing table. In other words, the monitoring route is already advertised as an export route from the peering node with active NAT pool.
The export route can be advertised only from:
no export
Syntax:
ip-prefix/length : | ip-prefix | a.b.c.d |
ip-prefix-length | 0 to 32 |
This command implicitly enables Pool Fate-Sharing Group (PFSG) which is required in case of multiple NAT policies per inside routing context. A NAT pool configured with this command will not advertise or monitor any route in order to change its (activity) state but instead it will directly follow the state of the lead pool in the PFSG. Once the lead pool changes its (activity) state, all the remaining pools following the lead pool will change their state accordingly.
no follow
This command configures the monitoring route based on which the NAT multi-chassis switchover is triggered. Monitoring route of a NAT pool on the local node must match the export route of a corresponding NAT pool on the peering node. Presence of the monitoring route in the routing table is an indication that the peering NAT pool is active (since it is advertising its export route). The disappearance of the monitoring route from the routing table is an indication that the peering pool has failed and consequently the nodal switchover is triggered, the local pool becomes active and its export route is consequently advertised. The export route can be advertised only from:
Syntax:
ip-prefix/length : | ip-prefix | a.b.c.d |
ip-prefix-length | 0 to 32 |
This command configures the maximum number of subscribers per outside IP address.
If multiple port blocks per subscriber are used, the block size is typically small; all blocks assigned to a given subscriber belong to the same IP address; the subscriber limit guarantees that any subscriber can get a minimum number of ports.
This command configures the watermarks for this NAT pool.
This command allows the operator to create special subscriber-based interfaces. It is used to contain multiple group interfaces. Multiple subnets associated with the subscriber interface can be applied to any of the contained group interfaces in any combination. The subscriber interface allows subnet sharing between group interfaces.
Use the no form of the command to remove the subscriber interface.
This command configures the local subscriber subnets available on a subscriber IP interface. The configured ip-address and mask define the address space associated with the subscriber subnet. Up to 16 IP subnets can be created on a single subscriber IP interface. Each subnet supports a locally owned IP host address within the subnet that is not expected to appear on other routers that may be servicing the same subscriber subnet. For redundancy purposes, the keyword gw-address defines a separate IP address within the subnet for Subscriber Routed Redundancy Protocol (SRRP) routing. This IP address must be the same on the local and remote routers participating in a common SRRP instance.
In SRRP, a single SRRP instance is tied to a group IP interface. The group IP interface is contained directly within a subscriber IP interface context and thus directly associated with the subscriber subnets on the subscriber IP interface. The SRRP instance is also indirectly associated with any subscriber subnets tied to the subscriber interface through wholesale/retail VPRN configurations. With the directly-associated and the indirectly-associated subscriber interface subnets, a single SRRP instance can manage hundreds of SRRP gateway IP addresses. This automatic subnet association to the SRRP instance is different from VRRP where the redundant IP address is defined within the VRRP context.
Defining an SRRP gateway IP address on a subscriber subnet is not optional when the subnet is associated with a group IP interface with SRRP enabled. Enabling SRRP (no shutdown) will fail if one or more subscriber subnets do not have an SRRP gateway IP address defined. Creating a new subscriber subnet without an SRRP gateway IP address defined will fail when the subscriber subnet is associated with a group IP interface with an active SRRP instance. Once SRRP is enabled on a group interface, the SRRP instance will manage the ARP response and routing behavior for all subscriber hosts reachable through the group IP interface.
The no form of the command removes the address from a subscriber subnet. The address command for the specific subscriber subnet must be executed without the gw-address parameter. To succeed, all SRRP instances associated with the subscriber subnet must removed or shutdown.
The gw-address parameter may be specified at anytime. If the subscriber subnet was created previously, executing the address command with a gw-address parameter will simply add the SRRP gateway IP address to the existing subnet.
If the address command is executed without the gw-address parameter when the subscriber subnet is associated with an active SRRP instance, the address will fail. If the SRRP instance is inactive or removed, executing the address command without the gw-address parameter will remove the SRRP gateway IP address from the specified subscriber subnet.
If the address command is executed with a new gw-address, all SRRP instances currently associated with the specified subscriber subnet will be updated with the new SRRP gateway IP address.
This command specifies whether subscriber hosts with a subnet that does not match any of the subnets configured on this interface, are allowed.
This command enables the context to configure a group interface. A group interface is an interface that may contain one or more SAPs. This interface is used in triple-play services where multiple SAPs are part of the same subnet.
n/a
This command enables the context to configure ARP host parameters.
This command configures the maximum number of ARP hosts.
This command configures the minimum authentication interval.
This command configures the maximum number of ARP hosts per SAP.
This command creates a logical IP routing interface for a Virtual Private Routed Network (VPRN). Once created, attributes like an IP address and service access point (SAP) can be associated with the IP interface.
The interface command, under the context of services, is used to create and maintain IP routing interfaces within VPRN service IDs. The interface command can be executed in the context of an VPRN service ID. The IP interface created is associated with the service core network routing instance and default routing table. The typical use for IP interfaces created in this manner is for subscriber Internet access.
Interface names are case sensitive and must be unique within the group of defined IP interfaces defined for config router interface and config service vprn interface. Interface names must not be in the dotted decimal notation of an IP address. For example, the name “1.1.1.1” is not allowed, but “int-1.1.1.1” is allowed. Show commands for router interfaces use either interface names or the IP addresses. Use unique IP address values and IP address names to maintain clarity. It could be unclear to the user if the same IP address and IP address name values are used. Although not recommended, duplicate interface names can exist in different router instances.
The available IP address space for local subnets and routes is controlled with the config router service-prefix command. The service-prefix command administers the allowed subnets that can be defined on service IP interfaces. It also controls the prefixes that may be learned or statically defined with the service IP interface as the egress interface. This allows segmenting the IP address space into config router and config service domains.
When a new name is entered, a new logical router interface is created. When an existing interface name is entered, the user enters the router interface context for editing and configuration.
By default, there are no default IP interface names defined within the system. All VPRN IP interfaces must be explicitly defined. Interfaces are created in an enabled state.
The no form of this command removes IP the interface and all the associated configuration. The interface must be administratively shutdown before issuing the no interface command.
For VPRN services, the IP interface must be shutdown before the SAP on that interface may be removed. VPRN services do not have the shutdown command in the SAP CLI context. VPRN service SAPs rely on the interface status to enable and disable them.
If ip-int-name already exists within the service ID, the context will be changed to maintain that IP interface. If ip-int-name already exists within another service ID or is an IP interface defined within the config router commands, an error will occur and context will not be changed to that IP interface. If ip-int-name does not exist, the interface is created and context is changed to that interface for further command processing.
This command enables CPM protocols on this interface.
Assigns an IP address, IP subnet, and broadcast address format to a VPRN IP router interface. Only one IP address can be associated with an IP interface.
An IP address must be assigned to each VPRN IP interface. An IP address and a mask are used together to create a local IP prefix. The defined IP prefix must be unique within the context of the routing instance. It cannot overlap with other existing IP prefixes defined as local subnets on other IP interfaces in the same routing context within the 7750 SR.
The local subnet that the address command defines must be part of the services address space within the routing context using the config router service-prefix command. The default is to disallow the complete address space to services. Once a portion of the address space is allocated as a service prefix, that portion can be made unavailable for IP interfaces defined within the config router interface CLI context for network core connectivity with the exclude option in the config router service-prefix command.
The IP address for the interface can be entered in either CIDR (Classless Inter-Domain Routing) or traditional dotted decimal notation. The show commands display CIDR notation and is stored in configuration files.
By default, no IP address or subnet association exists on an IP interface until it is explicitly created.
Use the no form of this command to remove the IP address assignment from the IP interface. When the no address command is entered, the interface becomes operationally down.
Address | Admin state | Oper state |
No address | up | down |
No address | down | down |
1.1.1.1 | up | up |
1.1.1.1 | down | down |
The operational state is a read-only variable and the only controlling variables are the address and admin states. The address and admin states are independent and can be set independently. If an interface is in an adminstratively up state and an address is assigned, it becomes operationally up and the protocol interfaces and the MPLS LSPs associated with that IP interface will be reinitialized.
The broadcast format on an IP interface can be specified when the IP address is assigned or changed.
This parameter does not affect the type of broadcasts that can be received by the IP interface. A host sending either the local broadcast (all-ones) or the valid subnet broadcast address (host-ones) will be received by the IP interface.
The broadcast parameter within the address command does not have a negate feature, which is usually used to revert a parameter to the default value. To change the broadcast type to host-ones after being changed to all-ones, the address command must be executed with the broadcast parameter defined.
This command controls the forwarding of directed broadcasts out of the IP interface.
A directed broadcast is a packet received on a local router interface destined for the subnet broadcast address on another IP interface. The allow-directed-broadcasts command on an IP interface enables or disables the transmission of packets destined to the subnet broadcast address of the egress IP interface.
When enabled, a frame destined to the local subnet on this IP interface will be sent as a subnet broadcast out this interface. Care should be exercised when allowing directed broadcasts as it is a well-known mechanism used for denial-of-service attacks.
When disabled, directed broadcast packets discarded at this egress IP interface will be counted in the normal discard counters for the egress SAP.
By default, directed broadcasts are not allowed and will be discarded at this egress IP interface.
The no form of this command disables the forwarding of directed broadcasts out of the IP interface.
no allow-directed-broadcasts — Directed broadcasts are dropped.
This command specifies the BFD parameters for the associated IP interface. If no parameters are defined the default value are used.
The multiplier specifies the number of consecutive BFD messages that must be missed from the peer before the BFD session state is changed to down and the upper level protocols (OSPF, IS-IS, BGP or PIM) is notified of the fault.
The no form of the command removes BFD from the associated IGP protocol adjacency.
Note: On the 7750 SR and 7950 XRS, the transmit-interval, receive receive-interval, and echo-receive echo-interval values can only be modified to a value less than 100 when:
To remove the type cpm-np option, re-issue the bfd command without specifying the type parameter. |
no bfd
This command creates the configuration context to configure cflowd parameters for the associated IP interfaces.
cflowd is used for network planning and traffic engineering, capacity planning, security, application and user profiling, performance monitoring, usage-based billing, and SLA measurement.
At a minimum, the sampling command must be configured within this context in order to enable cflowd sampling, otherwise traffic sampling will not occur.
no cflowd-parameters
This command enables and configures the cflowd sampling behavior to collect traffic flow samples through a router for analysis.
This command can be used to configure the sampling parameters for unicast and multicast traffic separately. If sampling is not configured for either unicast or multicast traffic, then that type of traffic will not be sampled.
If cflowd is enabled without either egress-only or both specified or with the ingress-only keyword specified, then only ingress sampling will be enabled on the associated IP interface.
The no form of the command disables the associated type of traffic sampling on the associated interface.
no sampling
This command assigns an existing CPU protection policy to the associated service interface. For these interface types, the per-source rate limit is not applicable.The CPU protection policies are configured in the config>sys>security>cpu-protection>policy cpu-protection-policy-id context.
If no CPU protection policy is assigned to a service interface, then a the default policy is used to limit the overall-rate.
The no form of the command removes CPU protection policy association from the interface, resulting in no default rate limiting of control packets.
cpu-protection 254 (for access interfaces)
cpu-protection 255 (for network interfaces)
none (for video-interfaces (where applicable), shown as no cpu-protection in CLI)
The configuration of no cpu-protection returns the interface/SAP to the default policies as shown above.
This command assigns an existing CPU protection policy to the associated service group interface SAP, interface or MSAP policy. The CPU protection policies are configured in the config>sys>security>cpu-protection>policy cpu-protection-policy-id context.
If no CPU protection policy is assigned to a service group interface SAP, then a the default policy is used to limit the overall-rate.
cpu-protection 254 (for access interfaces)
cpu-protection 255 (for network interfaces)
none (for video-interfaces (where applicable), shown as no cpu-protection in CLI)
The configuration of no cpu-protection returns the interface/SAP to the default policies as shown above.
This command disables duplicate address detection (DAD) on a per-interface basis. This prevents the router from performing a DAD check on the interface. All IPv6 addresses of an interface with DAD disabled, immediately enter a preferred state, without checking for uniqueness on the interface. This is useful for interfaces which enter a looped state during troubleshooting and operationally disable themselves when the loop is detected, requiring manual intervention to clear the DAD violation.
The no form of the command turns off dad-disable on the interface.
not enabled
This command assigns a Distributed CPU Protection (DCP) policy to the network interface. Only a valid created DCP policy can be assigned to a SAP or a network interface (this rule does not apply to templates such as an msap-policy)
no dist-cpu-protection
This command will cause a delay in the activation of an IP interface by the specified number of seconds. The delay is invoked whenever the system attempts to bring the associated IP interface up.
The no form of the command removes the command from the active configuration and removes the delay in activating the associated IP interface. If the configuration is removed during a delay period, the currently running delay will continue until it expires.
This command creates the context to configure or apply IP interface attributes such as administrative group (admin-group) or Shared Risk Loss Group (SRLG).
This command configures the admin group membership of an interface. The user can apply admin groups to an IES, VPRN, network IP, or MPLS interface.
Each single operation of the admin-group command allows a maximum of five (5) groups to be specified at a time. However, a maximum of 32 groups can be added to a given interface through multiple operations. Once an admin group is bound to one or more interface, its value cannot be changed until all bindings are removed.
The configured admin-group membership will be applied in all levels/areas the interface is participating in. The same interface cannot have different memberships in different levels/areas.
Only the admin groups bound to an MPLS interface are advertised area-wide in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF. IES and VPRN interfaces do not have their attributes advertised in TE TLVs.
The no form of this command deletes one or more of the admin-group memberships of an interface. The user can also delete all memberships of an interface by not specifying a group name.
This command configures the SRLG membership of an interface. The user can apply SRLGs to an IES, VPRN, network IP, or MPLS interface.
An interface can belong to up to 64 SRLG groups. However, each single operation of the srlg-group command allows a maximum of five (5) groups to be specified at a time. Once an SRLG group is bound to one or more interface, its value cannot be changed until all bindings are removed.
The configured SRLG membership will be applied in all levels/areas the interface is participating in. The same interface cannot have different memberships in different levels/areas.
Only the SRLGs bound to an MPLS interface are advertised area-wide in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF. IES and VPRN interfaces do not have their attributes advertised in TE TLVs.
The no form of this command deletes one or more of the SRLG memberships of an interface. The user can also delete all memberships of an interface by not specifying a group name.
This command enters context to configure ingress parameters for network interfaces.
This command configures the service vprn interface ingress policy accounting
This command configures the IP maximum transmit unit (packet) for this interface.
The no form of the command returns the default value.
no ip-mtu
This command creates allows access to the IPCP context within the interface configuration. Within this context, IPCP extensions can be configured to define such things as the remote IP address and DNS IP address to be signaled via IPCP on the associated PPP interface.
This command is only applicable if the associated SAP/port is a PPP/MLPPP interface.
n/a
This command defines the dns address(es) to be assigned to the far-end of the associated PPP/MLPPP link via IPCP extensions.
This command is only applicable if the associated SAP/port is a PPP/MLPPP interface with an IPCP encapsulation.
The no form of the command deletes either the specified primary DNS address, secondary DNS address or both addresses from the IPCP extension peer-ip-address configuration.
no dns
This command defines the remote IP address to be assigned to the far-end of the associated PPP/MLPPP link via IPCP extensions.
This command is only applicable if the associated SAP/port is a PPP/MLPPP interface with an IPCP encapsulation.
The interface must be shut down to modify the IPCP configuration.
The no form of the command deletes the IPCP extension peer-ip-address configuration.
no peer-ip-address (0.0.0.0)
This command configures an IPv6 interface.
This command assigns an IPv6 address to the VPRN interface.
ipv6-address/prefix: | ipv6-address | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | ||
x [0 to FFFF]H | ||
d [0 to 255]D | ||
prefix-length | 1 to 128 |
This command configures DHCPv6 relay parameters for the VPRN interface.
This command configures DHCPv6 server parameters for the VPRN interface.
This command configures ICMPv6 for the interface.
This command configures the IPv6 link local address.
The no form of the command removes the configured link local address, and the router automatically generates a default link local address.
Caution: Removing a manually configured link local address may impact routing protocols or static routes that have a dependency on that address. It is not recommended to remove a link local address when there are active IPv6 subscriber hosts on an IES or VPRN interface. |
This command enables or disables neighbor discovery on the interface.
This command configures IPv6-to-MAC address mapping on the interface.
ipv6-address | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x [0 to FFFF]H | |
d [0 to 255]D |
This command configures the maximum amount of dynamic IPv6 neighbor entries that can be learned on an IP interface.
When the number of dynamic neighbor entries reaches the configured percentage of this limit, an SNMP trap is sent. When the limit is exceeded, no new entries are learned until an entry expires and traffic to these destinations will be dropped. Entries that have already been learned will be refreshed.
The no form of the command removes the neighbor-limit.
90 percent
This command configures a proxy neighbor discovery policy for the interface.
This command enables the load-balancing context to configure interface per-flow load balancing options that will apply to traffic entering this interface and egressing over a LAG/ECMP on system-egress. This is a per interface setting. For load-balancing options that can also be enabled on the system level, the options enabled on the interface level overwrite system level configurations.
not applicable
This command specifies whether to include the source address or destination address or both in the LAG/ECMP hash on IP interfaces. Additionally, when l4-load-balancing is enabled, the command also applies to the inclusion of source/destination port in the hash inputs.
The no form of this command includes both source and destination parameters.
no egr-ip-load-balancing
This command specifies whether the IP header is used in the LAG and ECMP LSR hashing algorithm. This is the per interface setting.
no lsr-load-balancing
This command enables use of the SPI in hashing for ESP/AH encrypted IPv4/v6 traffic. This is a per interface setting.
The no form disables the SPI function.
disabled
This command enables inclusion of TEID in hashing for GTP-U/C encapsulates traffic for GTPv1/GTPv2. The no form of this command ignores TEID in hashing.
disabled
This command enables local proxy ARP. When local proxy ARP is enabled on an IP interface, the system responds to all ARP requests for IP addresses belonging to the subnet with its own MAC address, and thus will become the forwarding point for all traffic between hosts in that subnet. When local-proxy-arp is enabled, ICMP redirects on the ports associated with the service are automatically blocked.
no local-proxy-arp
This command specifies that the associated interface is a loopback interface that has no associated physical interface. As a result, the associated interface cannot be bound to a SAP.
When using mtrace/mstat in a Layer 3 VPN context then the configuration for the VPRN should have a loopback address configured which has the same address as the core instance's system address (BGP next-hop).
no loopback
This command assigns a specific MAC address to a VPRN IP interface.
The no form of this command returns the MAC address of the IP interface to the default value.
The physical MAC address associated with the Ethernet interface that the SAP is configured on.
This command enables receiving of NTP/SNTP broadcasts on the interface/
This command specifies the operational group to be monitored by the object under which it is configured. The oper-group name must be already configured under the config>service context before its name is referenced in this command.
The no form of the command removes the association from the configuration.
no monitor-oper-group
This command enables proxy ARP on the interface.
no proxy-arp
This command enables a proxy ARP policy for the interface.
The no form of this command disables the proxy ARP capability.
no proxy-arp
The specified name(s) must already be defined.
This command configures the 1588 port based timestamping assist function for the interface. This capability is supported on a specific set of hardware. The command may be blocked if not all hardware has the required level of support.
If the SAP configuration of the interface is removed, the ptp-hw-assist configuration will be removed.
If the IPv4 address configuration of the interface is removed, the ptp-hw-assist configuration will be removed.
Only one interface per physical port can have ptp-hw-assist enabled.
no ptp-hw-assist
This command enables QoS classification of the ingress IP packets on an interface based on the QoS information associated with routes in the forwarding table.
If the optional destination parameter is specified and the destination address of an incoming IP packet matches a route with QoS information the packet is classified to the fc and priority associated with that route, overriding the fc and priority/profile determined from the sap-ingress or network qos policy associated with the IP interface. If the destination address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the sap-ingress or network QoS policy.
If the optional source parameter is specified and the source address of an incoming IP packet matches a route with QoS information the packet is classified to the fc and priority associated with that route, overriding the fc and priority/profile determined from the sap-ingress or network qos policy associated with the IP interface. If the source address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the sap-ingress or network QoS policy.
If neither the optional source or destination parameter is present, then the default is destination address matching.
The functionality enabled by the qos-route-lookup command can be applied to IPv4 packets or IPv6 packets on an interface, depending on whether it is present at the interface context (applies to IPv4) or the interface>ipv6 context (applies to IPv6). The ability to specify source address based QoS lookup is not supported for IPv6. For the 7740 ESS, subscriber management group interfaces also do not support the source QPPB option.
The no form of the command reverts to the default.
destination
This command configures a redundant interface used for dual homing.
This command enables remote proxy ARP on the interface.
Remote proxy ARP is similar to proxy ARP. It allows the router to answer an ARP request on an interface for a subnet that is not provisioned on that interface. This allows the router to forward to the other subnet on behalf of the requester. To distinguish remote proxy ARP from local proxy ARP, local proxy ARP performs a similar function but only when the requested IP is on the receiving interface.
no remote-proxy-arp
This command assigns an secondary IP address/IP subnet/broadcast address format to the interface.
n/a
The broadcast format on an IP interface can be specified when the IP address is assigned or changed. This parameter does not affect the type of broadcasts that can be received by the IP interface. A host sending either the local broadcast (all-ones) or the valid subnet broadcast address (host-ones) will be received by the IP interface. (Default: host-ones)
The broadcast parameter within the address command does not have a negate feature, which is usually used to revert a parameter to the default value. To change the broadcast type to host-ones after being changed to all-ones, the address command must be executed with the broadcast parameter defined.
This command configures a static address resolution protocol (ARP) entry associating a subscriber IP address with a MAC address for the core router instance. This static ARP will appear in the core routing ARP table. A static ARP can only be configured if it exists on the network attached to the IP interface. If an entry for a particular IP address already exists and a new MAC address is configured for the IP address, the existing MAC address will be replaced with the new MAC address.
The no form of this command removes a static ARP entry.
n/a
This command specifies redundant next-hop address on public or private IPsec interface (with public or private tunnel-sap) for static IPsec tunnel. The specified next-hop address will be used by standby node to shunt traffic to master in case of it receives them.
The next-hop address will be resolved in routing table of corresponding service.
The no form of the command removes the address from the interface configuration.
n/a
This command enables Secure Neighbor Discovery (SeND) on the IPv6 interface.
The no form of the command reverts to the default and disabled SeND.
This command specifies whether unsecured messages are accepted. When Secure Neighbor Discovery (SeND) is enabled, only secure messages are accepted by default.
The no form of the command disables accepting unsecured messages.
This command configures the Cryptographically Generated Address (CGA) modifier for link-local addresses.
This command configures the minimum acceptable key length for public keys used in the generation of a Cryptographically Generated Address (CGA).
This command configures the security parameter used in the generation of a Cryptographically Generated Address (CGA).
This command enables or disables Secure Neighbor Discovery (SeND) on the interface.
This command configures the time a neighbor discovery cache entry can remain stale before being removed.
The no form of the command removes the stale-time value.
no stale-time
This command statically sets the TCP maximum segment size (MSS) for TCP connections originated from the associated IP interface to the specified value.
The no form of the command removes the static value and allows the TCP MSS value to be calculated based on the IP MTU value by subtracting the base IP and TCP header lengths from the IP MTU value (tcp_mss = ip_mtu – 40).
no tcp-mss
Note: 9158 = max-IP_MTU (9198)-40
This command is used to alter the default trusted state to a non-trusted state. When unset or reverted to the trusted default, the ToS field will not be remarked by egress network IP interfaces unless the egress network IP interface has the remark-trusted state set, in which case the egress network interface treats all VPRN and network IP interface as untrusted.
When the ingress interface is set to untrusted, all egress network IP interfaces will remark IP packets received on the network interface according to the egress marking definitions on each network interface. The egress network remarking rules also apply to the ToS field of IP packets routed using IGP shortcuts (tunneled to a remote next-hop). However, the tunnel QoS markings are always derived from the egress network QoS definitions. Egress marking and remarking is based on the internal forwarding class and profile state of the packet once it reaches the egress interface. The forwarding class is derived from ingress classification functions. The profile of a packet is either derived from ingress classification or ingress policing.
The default marking state for network IP interfaces is trusted. This is equivalent to declaring no tos-marking-state on the network IP interface. When undefined or set to tos-marking-state trusted, the trusted state of the interface will not be displayed when using show config or show info unless the detail parameter is given. The save config command will not store the default tos-marking-state trusted state for network IP interfaces unless the detail parameter is also specified.
The no tos-marking-state command is used to restore the trusted state to a network IP interface. This is equivalent to executing the tos-marking-state trusted command.
trusted
This command configures IPv6 parameters.
This command allows address assignment to PPPoX hosts in cases where the assigned address falls outside the range of the configured subnets below the subscriber interface. Alternatively, if the interface is configured as unnumbered, this command cannot be enabled.
no allow-unmatching-prefixes
This command allows address assignment to IPv6 hosts in cases where the assigned address or the prefix falls outside of the range of the configured IPv6 subscriber-prefixes under the configure>service>vprn/ies>sub-if>ipv6 hierarchy.
Unnumbered PPPoEv6 does not mean that the PPPoEv6 hosts do not have an IPv6 address or prefix assigned. It only means that the IPv6 address range (out of which the address or prefix is assigned to the host) does not have to be known in advance via configuration under the subscriber-interface>ipv6>subscriber-prefixes node.
no allow-unmatching-prefixes
This command configures the subscriber-interface level setting for delegated prefix length. The delegated prefix length for a subscriber- interface can be either set to a fixed value that is explicitly configured under the subscriber-interface CLI hierarchy or a variable value that can be obtained from various sources. This command can be changed only when no IPv6 prefixes are configured under the subscriber-interface.
no delegated-prefix-length This means that the delegated prefix length is 64.
This command allows access to the DHCP6 context within the group interface configuration. Within this context, DHCP6 parameters can be configured.
no dhcp6
This command enables the context to configure DHCPv6 relay information options.
The no form of the command disables DHCPv6 relay information options.
This command enables the sending of interface ID options in the DHCPv6 relay packet.
The no form of the command disables the sending of interface ID options in the DHCPv6 relay packet
This command enables the sending of remote ID option in the DHCPv6 relay packet.
The client DHCP Unique Identifier (DUID) is used as the remote ID.
The no form of the command disables the sending of remote ID option in the DHCPv6 relay packet.
This command allows access to the DHCP6 proxy server context. Within this context, DHCP6 proxy server parameters of the group interface can be configured.
no proxy-server
This command configures the renew-timer (T1), the time at which the client contacts the server from which the addresses in the IA_NA or IA_PD were obtained to extend the lifetimes of the addresses or prefixes assigned to the client.
1800
This command configures the rebind-timer (T2), the time at which the client contacts any available server to extend the lifetimes of the addresses or prefixes assigned to the client.
2880
The preferred lifetime for the IPv6 prefix or address in the option, expressed in units of seconds. When the preferred lifetime expires, any derived addresses are deprecated.
3600
The valid lifetime for the IPv6 prefix or address in the option, expressed in units of seconds.
86,400
This command configures the client host types to which the DHCP6 proxy server is allowed to assign addresses.
This command enables Router Advertisement transmission on this group interface.
router-advertisements
This command specifies the hop-limit advertised to hosts in router advertisements.
64
This command sets the managed address configuration flag. This flag indicates that DHCPv6 is available for address configuration in addition to any address auto-configured using stateless address auto-configuration. See RFC 3315, Dynamic Host Configuration Protocol (DHCP) for IPv6.
no managed-configuration
This command configures the maximum interval between sending router advertisement messages.
1800
This command configures the minimum interval between sending router advertisement messages.
900
This command configures the MTU for the nodes to use to send packets on the link.
no mtu
This command sets the “Other configuration” flag. This flag indicates that DHCPv6 is available for auto-configuration of other (non-address) information such as DNS-related information or information on other servers in the network. See RFC 3736, Stateless Dynamic Host Configuration Protocol (DHCP) for IPv6.
no other-stateful-configuration
This command configures router advertisement parameters for IPv6 prefixes returned via RADIUS Framed-IPv6-Prefix. All prefixes will inherit these configuration parameters.
no prefix-options
This command specifies whether the prefix can be used for stateless address auto-configuration.
no autonomous
This command configures the remaining length of time in seconds that this prefix will continue to be preferred, such as, time until deprecation. The address generated from a deprecated prefix should not be used as a source address in new communications, but packets received on such an interface are processed as expected.
3600
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.
86400
This command configures how long this router should be considered reachable by other nodes on the link after receiving a reachability confirmation.
no reachable-time
This command configures the retransmission frequency of neighbor solicitation messages.
no retransmit-time
This command sets the router lifetime. A value of zero indicates this router should not be used by hosts as a default router.
4500
This command configures the renew-timer (T1). The time at which the client contacts the server from the addresses in the IA_NA or IA_PD were obtained to extend the lifetimes of the addresses or prefixes assigned to the client.
1800
This command configures the rebind-timer (T2), the time at which the client contacts any available server to extend the lifetimes of the addresses or prefixes assigned to the client.
2880
This command defines the prefix-length used for all DHCPv6 prefix delegations on this subscriber interface.
This command specifies aggregate off-link subscriber prefixes associated with this subscriber interface. Individual prefixes are specified under the prefix context list aggregate routes in which the next-hop is indirect via the subscriber interface.
This command allows a list of prefixes (using the prefix command multiple times) to be routed to hosts associated with this subscriber interface. Each prefix will be represented in the associated FIB with a reference to the subscriber interface. Prefixes are defined as being for prefix delegation (pd) or use on a WAN interface or host (wan-host).
This command controls the export of subnets to the forwarding service. When this attribute is configured, subnets defined on this retail subscriber interface will no longer be exported to the associated wholesale VPRN and will remain private to the retail VPRN. This is useful in a PPPoE business service context as it allows retail services to use overlapping IP address spaces even if these services are associated with the same wholesale service.
PPPoE sessions are actually terminated in the retail service although their traffic transits on a SAP belonging to the wholesale service. This configuration is incompatible, however, with IPoE host management (DHCP, static-host and ARP-host) as these host types require that the retail subnets are exported to the wholesale VPRN. Thus, if PPPoE sessions need to coexist with IPoE hosts, this attribute should not be configured on this retail interface.
This command will fail if the subscriber interface is not associated with a wholesale service.
If the retail VPRN is of the type hub, this attribute is mandatory. Then, it will be enabled by default and it will not be possible to deconfigure it.
This command configures the interface as an unnumbered interface. An unnumbered IP interface is supported on a SONET/SDH access port with the PPP, ATM, Frame Relay, cisco-HDLC encapsulation. It is not supported on access ports that do not carry IP traffic, but are used for native TDM circuit emulation.
This command associates a network Quality of Service (QoS) policy with a network IP interface. Only one network QoS policy can be associated with an IP interface at one time. Attempts to associate a second QoS policy return an error.
Associating a network QoS policy with a network interface is useful for the following purposes:
The no form of the command removes the network QoS policy association from the network IP interface, and the QoS policy reverts to the default.
no qos
This command enables unicast RPF (uRPF) check on this interface.
The no form of the command disables unicast RPF (uRPF) Check on this interface.
disabled
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 the command removes the VAS interface type configuration.
no vas-if-type
This command specifies the mode of unicast RPF check.
The no form of the command reverts to the default (strict) mode.
strict
This command configures a network interface in a VPRN that acts as a CSC interface to a CSC-CE in a Carrier Supporting Carrier IP VPN deployment model.
This command enables the context to configure DHCP parameters.
This command enables the clients that will try to contact the DHCP server(s).
The no form of the command removes the server client type from the configuration.
This command configures the processing required when the router receives a DHCP request that already has a Relay Agent Information Option (Option 82) field in the packet.
The no form of this command returns the system to the default value.
Per RFC 3046, DHCP Relay Agent Information Option , section 2.1.1, Reforwarded DHCP requests, the default is to keep the existing information intact. The exception to this is if the giaddr of the received packet is the same as the ingress address on the router. In that case the packet is dropped and an error is logged.
The behavior is slightly different in case of Vendor Specific Options (VSOs). When the keep parameter is specified, the router will insert his own VSO into the Option 82 field. This will only be done when the incoming message has already an Option 82 field.
If no Option 82 field is present, the router will not create the Option 82 field. In this in that case, no VSO will be added to the message.
When enabled, the router sends the interface index (If Index) in the circuit-id suboption of the DHCP packet. The If Index of a router interface can be displayed using the command show>router>interface>detail. This option specifies data that must be unique to the router that is relaying the circuit.
If disabled, the circuit-id suboption of the DHCP packet will be left empty.
The no form of this command returns the system to the default.
circuit-id
This command configures the DHCP filter for this interface.
This command configures the gateway interface address for the DHCP relay. A subscriber interface can include multiple group interfaces with multiple SAPs. The GI address is needed, when the router functions as a DHCP relay, to distinguish between the different subscriber interfaces and potentially between the group interfaces defined.
no gi-address
This command specifies the maximum number of DHCPv6 lease states allocated by the DHCPv6 relay function, allowed on this interface.
Optionally, by specifying “route-populate” parameter, system could:
These routes could be redistributed into IGP/BGP by using route-policy, following protocol types that could be used in “from protocol”:
This command enables neighbor resolution with DHCPv6 relay.
The no form of the command disables neighbor resolution.
This command enables Option 82 circuit ID on relayed DHCP packet matching. For routed CO, the group interface DHCP relay process is stateful. When packets are relayed to the server the virtual router ID, transaction ID, SAP ID, and client hardware MAC address of the relayed packet are tracked.
When a response is received from the server the virtual router ID, transaction ID, and client hardware MAC address must be matched to determine the SAP on which to send the packet out. In some cases, the virtual router ID, transaction ID, and client hardware MAC address are not guaranteed to be unique.
When the match-circuit-id command is enabled we use this as part of the key to guarantee correctness in our lookup. This is really only needed when we are dealing with an IP aware DSLAM that proxies the client hardware MAC address.
no match-circuit-id
This command enables DHCP Option 82 (Relay Agent Information Option) parameters processing and enters the context for configuring Option 82 sub-options.
The no form of this command returns the system to the default.
no option
This command enables the copy-82 option.
The no form of the command disables the option.
When enabled, the router sends the MAC address of the remote end (typically the DHCP client) in the remote-id suboption of the DHCP packet. This command identifies the host at the other end of the circuit. If disabled, the remote-id suboption of the DHCP packet will be left empty.
The no form of this command returns the system to the default.
remote-id
This command configures the Nokia vendor specific suboption of the DHCP relay packet.
This command enables the sending of the MAC address in the Nokia vendor specific suboption of the DHCP relay packet.
The no form of the command disables the sending of the MAC address in the Nokia vendor specific suboption of the DHCP relay packet.
This command enables the sending of the pool name in the Nokia vendor-specific suboption of the DHCP relay packet.
The no form of the command disables the feature.
This command enables the sending of the interface name in the Nokia vendor-specific suboption of the DHCP relay packet
The no form of the command disables the sending.
This command enables sending of the port-id in the Nokia vendor-specific suboption of the DHCP relay packet
The no form of the command disables the sending.
This command enables the sending of the SAP ID in the Nokia vendor-specific suboption of the DHCP relay packet.
The no form of the command disables the sending of the SAP ID in the Nokia vendor specific suboption of the DHCP relay packet.
This command enables the sending of the service ID in the Nokia vendor specific suboption of the DHCP relay packet.
The no form of the command disables the sending of the service ID in the Nokia vendor specific suboption of the DHCP relay packet.
This command specifies the vendor specific suboption string of the DHCP relay packet.
The no form of the command returns the default value.
This command specifies whether the system-id is encoded in the Nokia vendor specific sub-option of Option 82.
n/a
This command configures the DHCP proxy server.
This command configures the IP address to be used as the DHCP server address in the context of this service. Typically, the configured address should be in the context of the subnet.
The no form of this command reverts to the default setting. The local proxy server will not become operational without a specified emulated server address.
This command defines the length of lease-time that will be provided to DHCP clients. By default the local-proxy-server will always make use of the lease-time information provide by either a RADIUS or DHCP server.
The no form of this command disables the use of the lease-time command. The local-proxy-server will use the lease-time offered by either a RADIUS or DHCP server.
7 days 0 hours 0 seconds
This command specifies a list of servers where requests will be forwarded. The list of servers can entered as either IP addresses or fully qualified domain names. There must be at least one server specified for DHCP relay to work. If there are multiple servers then the request is forwarded to all of the servers in the list. There can be a maximum of 8 DHCP servers configured.
The flood command is applicable only in the VPLS case. There is a scenario with VPLS where the VPLS node only wants to add Option 82 information to the DHCP request to provider per-subscriber information, but it does not do full DHCP relay. In this case, the server is set to “flood”. This means the DHCP request is still a broadcast and is sent through the VPLS domain. A node running at L3 further upstream then can perform the full L3 DHCP relay function.
no server
This command specifies a python policy to be used for DHCPv4. Python policies are configured in the config>python> python-policy name context.
This command specifies a python policy to be used for DHCPv6 relay. Python policies are configured in the config>python> python-policy name context.
This command enables the relaying of plain BOOTP packets.
The no form of the command disables the relaying of plain BOOTP packets.
Relay unicast client DHCPv4 request (renew) messages. In the upstream direction: update the source-ip address and add the gateway IP address (gi-address) field before sending the message to the intended DHCP server (the message is not broadcasted to all configured DHCP servers). In the downstream direction: remove the gi-address and update the destination IP address to the value of the yiaddr (your IP addess) field.
By default, unicast DHCPv4 release messages are forwarded transparently.
Additionally when the optional flag “relay-unicast-msg” is enabled, then the gi address and source IP address of relayed DHCPv4 messages can be configured to any local configured IP address in the same routing instance.
no relay-unicast-msg
This command enables snooping of DHCP packets on this interface.
The no form of the command disables snooping.
According to RFC 3046, DHCP Relay Agent Information Option, a DHCP request where the giaddr is 0.0.0.0 and which contains a Option 82 field in the packet, should be discarded, unless it arrives on a “trusted” circuit.
If trusted mode is enabled on an IP interface, the relay agent router will modify the request's giaddr to be equal to the ingress interface and forward the request.
This behavior only applies when the action in the Relay Agent Information Option is “keep”. In the case where the Option 82 field is being replaced by the relay agent (action = replace), the original Option 82 information is lost anyway, and there is thus no reason for enabling the trusted option.
The no form of this command returns the system to the default.
not enabled
This command enables the context to configure egress network filter policies for the interface.
This command enables the use of ARP to determine the destination heardware address.
The no form of the command disables the use of ARP to determine the destination heardware address
This command configures the local user database to use for authentication.
The no form of the command removes the value from the configuration.
no user-db
This command specifies redundant next-hop address on public or private IPsec interface (with public or private tunnel-sap) for dynamic IPsec tunnel. The specified next-hop address will be used by standby node to shunt traffic to master in case of it receives them.
The next-hop address will be resolved in routing table of corresponding service.
n/a
This command specifies whether to include source address or destination address or both in LAG/ECMP hash on IP interfaces. Additionally, when l4-load-balancing is enabled the command applies also to inclusion of source/destination port in the hash inputs.
The no form of this command includes both source and destination parameters.
no egr-ip-load-balancing
This command enables the collection of ingress interface IP stats. This command is only applicable to IP statistics, and not to uRPF statistics.
If enabled, then the following statistics are collected:
no enable-ingress-stats
This command enables MAC accounting functionality on this interface.
The no form of the command disables MAC accounting functionality on this interface.
This command enables enables subscriber host connectivity verification on a given SAP within a service.
This tool will periodically scan all known hosts (from dhcp-state) and perform a UC ARP request. The subscriber host connectivity verification will maintain state (connected vs. not-connected) for all hosts.
no host-connectivity-verify
This command creates the CLI context to configure interface level hold-up and hold-down timers for the associated IP interface.
The up timer controls a delay for the associated IPv4 or IPv6 interface so that the system will delay the deactivation of the associated interface for the specified amount of time.
The down timer controls a delay for the associated IPv4 or IPv6 interface so that the system will delay the activation of the associated interface for the specified amount of time
This command will cause a delay in the deactivation of the associated IP interface by the specified number of seconds. The delay is invoked whenever the system attempts to bring the associated IP interface down.
The no form of the command removes the command from the active configuration and removes the delay in deactivating the associated IP interface. If the configuration is removed during a delay period, the currently running delay will continue until it expires.
This command will cause a delay in the activation of the associated IP interface by the specified number of seconds. The delay is invoked whenever the system attempts to bring the associated IP interface up, unless the init-only option is configured. If the init-only option is configured, the delay is only applied when the IP interface is first configured or after a system reboot.
The no form of the command removes the command from the active configuration and removes the delay in activating the associated IP interface. If the configuration is removed during a delay period, the currently running delay will continue until it completes.
This command configures Internet Control Message Protocol (ICMP) parameters on a VPRN service.
This command enables responses to Internet Control Message Protocol (ICMP) mask requests on the router interface.
If a local node sends an ICMP mask request to the router interface, the mask-reply command configures the router interface to reply to the request.
By default, the router instance will reply to mask requests.
The no form of this command disables replies to ICMP mask requests on the router interface.
mask-reply — specifies to reply to ICMP mask requests
This commad configures the rate for Internet Control Message Protocol (ICMP) redirect messages issued on the router interface.
When routes are not optimal on this router and another router on the same subnetwork has a better route, the router can issue an ICMP redirect to alert the sending node that a better route is available.
The redirects command enables the generation of ICMP redirects on the router interface. The rate at which ICMP redirects is issued can be controlled with the optional number and seconds parameters by indicating the maximum number of redirect messages that can be issued on the interface for a given time interval.
By default, generation of ICMP redirect messages is enabled at a maximum rate of 100 per 10 second time interval.
The no form of this command disables the generation of icmp redirects on the router interface.
redirects 100 10 — maximum of 100 redirect messages in 10 seconds
Configures the rate Internet Control Message Protocol (ICMP) TTL expired messages are issued by the IP interface.
By default, generation of ICMP TTL expired messages is enabled at a maximum rate of 100 per 10 second time interval.
The no form of this command disables the limiting the rate of TTL expired messages on the router interface.
ttl-expired 100 10
This command enables and configures the rate for ICMP host and network destination unreachable messages issued on the router interface.
The unreachables command enables the generation of ICMP destination unreachables on the router interface. The rate at which ICMP unreachables is issued can be controlled with the optional number and seconds parameters by indicating the maximum number of destination unreachable messages which can be issued on the interface for a given time interval.
By default, generation of ICMP destination unreachable messages is enabled at a maximum rate of 10 per 10 second time interval.
The no form of this command disables the generation of icmp destination unreachable messages on the router interface.
unreachables 100 10
This command configures the IP maximum transmit unit (packet) for the associated router IP interface.
The configured IP-MTU cannot be larger then the calculated IP MTU based on the port MTU configuration.
The MTU that is advertised from the IES size is:
MINIMUM((SdpOperPathMtu - EtherHeaderSize), (Configured ip-mtu))
The no form of the command returns the associated IP interfaces MTU to its default value, which is calculated based on the port MTU setting. For Ethernet ports this will typically be 1554.
no ip-mtu
This command binds the interface to a Link Aggregation Group (LAG)
The no form of the command removes the LAG id from the configuration.
lag-id | 1 to 800 |
encap-val | 0 (for null) |
0 to 4094 (for dot1q) |
This command configures weight and class to this SAP to be used on LAG egress when the LAG uses weighted per-link-hash.
The no form of this command restores the default configuration.
no lag-per-link-hash (equivalent to weight 1 class 1)
This command enables the context to configure ATM-related attributes. This command can only be used when a given context (for example, a channel or SAP) supporting ATM functionality such as:
If ATM functionality is not supported for a given context, the command returns an error.
This command configures egress ATM attributes for the SAP.
This command configures RFC 2684, Multiprotocol Encapsulation over ATM AAL5, encapsulation for an ATM PVCC delimited SAP. This command specifies the data encapsulation for an ATM PVCC delimited SAP. The definition also references the ATM Forum LAN Emulation specification.
Ingress traffic that does not match the configured encapsulation will be dropped.
The encapsulation is driven by the services for which the SAP is configured.
For VPRN service SAPs, the default is aal5snap-routed.
This command configures ingress ATM attributes for the SAP.
This command assigns an ATM traffic descriptor profile to a given context (for example, a SAP). When configured under the ingress context, the specified traffic descriptor profile defines the traffic contract in the forward direction. When configured under the egress context, the specified traffic descriptor profile defines the traffic contract in the backward direction.
The no form of the command reverts the traffic descriptor to the default traffic descriptor profile.
The default traffic descriptor (trafficDescProfileId. = 1) is associated with newly created PVCC-delimited SAPs.
This command enables the context to configure OAM functionality for a PVCC delimiting a SAP.
The ATM-capable MDAs support F5 end-to-end OAM functionality (AIS, RDI, Loopback):
This command configures AIS/RDI fault management on a PVCC. Fault management allows PVCC termination to monitor and report the status of their connection by propagating fault information through the network and by driving PVCC’s operational status.
When alarm-cells functionality is enabled, a PVCC’s operational status is affected when a PVCC goes into an AIS or RDI state because of an AIS/RDI processing (assuming nothing else affects PVCC’s operational status, for example, if the PVCC goes DOWN, or enters a fault state and comes back UP, or exits that fault state). RDI cells are generated when PVCC is operationally DOWN. No OAM-specific SNMP trap is raised whenever an endpoint enters/exits an AIS or RDI state, however, if as result of an OAM state change, the PVCC changes operational status, then a trap is expected from an entity the PVCC is associated with (for example a SAP).
The no command disables alarm-cells functionality for a PVCC. When alarm-cells functionality is disabled, a PVCC’s operational status is no longer affected by a PVCC’s OAM state changes due to AIS/RDI processing (when alarm-cells is disabled, a PVCC will change operational status to UP due to alarm-cell processing) and RDI cells are not generated as result of the PVCC going into AIS or RDI state. The PVCC’s OAM status, however, will record OAM faults as described above.
enabled for PVCCs delimiting VPRN SAPs
This command enables periodic OAM loopbacks on this SAP. This command is only configurable on VPRN SAPs. When enabled, an ATM OAM loopback cell is transmitted every period as configured in the config>system>atm>oam>loopback-period period context.
If a response is not received and consecutive retry-down retries also result in failure, the endpoint will transition to an alarm indication signal/loss of clock state. Then, an ATM OAM loopback cell will be transmitted every period as configured in the loopback-period period. If a response is received for the periodic loopback and consecutive retry-up retries also each receive a response, the endpoint will transition back to the up state.
The no form of the command sets the value back to the default.
no periodic-loopback
This command enables anti-spoof filtering and optionally changes the anti-spoof matching type for the interface.
The type of anti-spoof filtering defines what information in the incoming packet is used to generate the criteria to lookup an entry in the anti-spoof filter table. The type parameter (ip, mac, ip-mac, nh-mac) defines the anti-spoof filter type enforced by the SAP when anti-spoof filtering is enabled.
The no form of the command disables anti-spoof filtering on the SAP.
Filter type default types:
This command configures the application profile name.
This command configures the maximum amount of dynamic IPv4 ARP entries that can be learned on an IP interface.
When the number of dynamic ARP entries reaches the configured percentage of this limit, an SNMP trap is sent. When the limit is exceeded, no new entries are learned until an entry expires and traffic to these destinations will be dropped. Entries that have already been learned will be refreshed.
The no form of the command removes the arp-limit.
90 percent
This command enables populating static and dynamic hosts into the system ARP cache. When enabled, the host’s IP address and MAC address are placed in the system ARP cache as a managed entry. Static hosts must be defined on the interface using the host command. Dynamic hosts are enabled on the system through enabling lease-populate in the IP interface DHCP context. In the event that both a static host and a dynamic host share the same IP and MAC address, the system’s ARP cache retains the host information until both the static and dynamic information are removed. Both static and dynamic hosts override static ARP entries. Static ARP entries are marked as inactive when they conflict with static or dynamic hosts and will be repopulated once all static and dynamic host information for the IP address are removed. Since static ARP entries are not possible when static subscriber hosts are defined or when DHCP lease state table population is enabled, conflict between static ARP entries and the arp-populate function is not an issue.
The arp-populate command will fail if an existing static subscriber host on the SAP does not have both MAC and IP addresses specified.
Once arp-populate is enabled, creating a static subscriber host on the SAP without both an IP address and MAC address will fail.
arp-populate can only be enabled on VPRN interfaces supporting Ethernet encapsulation.
Use the no form of the command to disable ARP cache population functions for static and dynamic hosts on the interface. All static and dynamic host information in the systems ARP cache will be removed. Any existing static ARP entries previously inactive due to static or dynamic hosts will be populated in the system ARP cache.
When arp-populate is enabled, the system will not send out ARP Requests for hosts that are not in the ARP cache. Only statically configured and DHCP learned hosts are reachable through an IP interface with arp-populate enabled.
not enabled
This command allows the arp retry timer to be configured to a specific value.
The timer value is entered as a multiple of 100 ms. So a timer value of 1, means the ARP timer will be set to 100 ms.
The no form of this command removes the command from the active configuration and returns the ARP retry timer to its default value of 5 s.
5 seconds
This command configures the minimum time in seconds an ARP entry learned on the IP interface will be stored in the ARP table. ARP entries are automatically refreshed when an ARP request or gratuitous ARP is seen from an IP host, otherwise, the ARP entry is aged from the ARP table. If arp-timeout is set to a value of zero seconds, ARP aging is disabled.
The no form of this command restores arp-timeout to the default value.
14400 seconds
This command assigns an authentication policy to the interface.
The no form of this command removes the policy name from the group interface configuration.
no authentication-policy
This command enables the inclusion of the calling-station-id attribute in RADIUS authentication requests and RADIUS accounting messages. The value inserted is set at the SAP level. If no value is set at the SAP level, an empty string is included.
This attribute is not sent by default.
This command creates a static host for the SAP. Applications within the system that make use of static host entries include anti-spoof, and source MAC population into the VPLS forwarding database.
Multiple static hosts can be defined on the SAP. Each host is identified by a source IP address, a source MAC address, or both a source IP and source MAC address. When anti-spoof in enabled on the SAP, the host information will be populated into the SAP’s anti-spoof table, allowing ingress packets matching the entry access to the SAP. When the MAC address exists in the host definition, the MAC address is populated into the VPLS forwarding database and associates it with the SAP. The static host definition overrides any static MAC entries using the same MAC and prevents dynamic learning of the MAC on another interface.
Defining a static host identical to an existing static host has no effect and will not generate a log or error message.
Every static host definition must have at least one address defined, IP or MAC.
Static hosts may exist on the SAP even with anti-spoof and arp-populate (VPRN) features disabled. When enabled, each feature has different requirements for static hosts.
There are no default static entries.
The no form of the command removes a static entry from the system. The specified ip address and mac address must match the host’s exact IP and MAC addresses as defined when it was created. When a static host is removed from the SAP, the affect of its removal on the anti-spoof filter, ARP cache or the VPLS forwarding database is also evaluated.
The following rules apply to configure static hosts using an IP address:
If the static subscriber host’s sub-ident string is not defined, the host is not considered to belong to the same subscriber as another host on the SAP.
If source or destination host is unknown, the hosts are not considered to belong to the same subscriber. ARP messages from unknown hosts are subject to anti-spoof filtering rules applied at the SAP.
If sub-ident is not enabled on the SAP arp-reply-agent, subscriber identification matching is not performed on ARP requests received on the SAP.
ARP requests are never forwarded back to the same SAP or within the receiving SAP’s split horizon group.
This command enables the context to configure Frame Relay parameters on the SAP.
This command enables the use of FRF12 headers.
The no form of the command disables the use of FRF12 headers.
This command specifies the maximum length of a fragment to be transmitted.
The no form of the command reverts to the default.
This command enables interleaving of high priority frames and low-priority frame fragments within a FR SAP using FRF.12 end-to-end fragmentation.
When this option is enabled, only frames of the FR SAP non expedited forwarding class queues are subject to fragmentation. The frames of the FR SAP expedited queues are interleaved, with no fragmentation header, among the fragmented frames. In effect, this provides a behavior like in MLPPP Link Fragment Interleaving (LFI).
When this option is disabled, frames of all the FR SAP forwarding class queues are subject to fragmentation. The fragmentation header is however not included when the frame size is smaller than the user configured fragmentation size. In this mode, the SAP transmits all fragments of a frame before sending the next full or fragmented frame.
The receive direction of the FR SAP supports both modes of operation concurrently, with and without fragment interleaving.
The no form of this command restores the default mode of operation.
no interleave
This command specifies the scheduling class to use for this SAP.
This command configures a host lockout policy.
The no form of the command removes the policy name from the configuration.
This command administratively enables host creation on this SAP.
This command is used to configure an IP-GRE or IP-IP tunnel and associate it with a private tunnel SAP within an IES or VPRN service.
The no form of the command deletes the specified IP/GRE or IP-IP tunnel from the configuration. The tunnel must be administratively shutdown before issuing the no ip-tunnel command.
No IP tunnels are defined.
This command sets the backup destination IPv4 address of GRE encapsulated packets associated with a particular GRE tunnel. If the primary destination address is not reachable in the delivery service (there is no route) or not defined then this is the destination IPv4 address of GRE encapsulated packets sent by the delivery service.
The no form of the command deletes the backup-destination address from the GRE tunnel configuration.
This command sets the delivery service for GRE encapsulated packets associated with a particular GRE tunnel. This is the IES or VPRN service where the GRE encapsulated packets are injected and terminated. The delivery service may be the same service that owns the private tunnel SAP associated with the GRE tunnel. The GRE tunnel does not come up until a valid delivery service is configured.
The no form of the command deletes the delivery-service from the GRE tunnel configuration.
This command sets the DSCP code-point in the outer IP header of GRE encapsulated packets associated with a particular GRE tunnel. The default, set using the no form of the command, is to copy the DSCP value from the inner IP header (after remarking by the private tunnel SAP egress qos policy) to the outer IP header.
no dscp
This command sets the source IPv4 address of GRE encapsulated packets associated with a particular GRE tunnel. It must be an address in the subnet of the associated public tunnel SAP interface. The GRE tunnel does not come up until a valid source address is configured.
The no form of the command deletes the source address from the GRE tunnel configuration. The tunnel must be administratively shutdown before issuing the no source command.
This command sets the primary destination IPv4 address of GRE encapsulated packets associated with a particular GRE tunnel. If this address is reachable in the delivery service (there is a route) then this is the destination IPv4 address of GRE encapsulated packets sent by the delivery service.
The no form of the command deletes the destination address from the GRE tunnel configuration.
This command enables the context to configure egress SAP Quality of Service (QoS) policies and filter policies.
If no sap-egress QoS policy is defined, the system default sap-egress QoS policy is used for egress processing. If no egress filter is defined, no filtering is performed.
This command enables the context to configure ingress SAP Quality of Service (QoS) policies and filter policies.
If no sap-ingress QoS policy is defined, the system default sap-ingress QoS policy is used for ingress processing. If no ingress filter is defined, no filtering is performed.
This command is used to control an HQoS aggregate rate limit. It is used in conjunction with the following parameter commands: rate, limit-unused-bandwidth, and queue-frame-based-accounting.
This command is used to enable (or disable) aggregate rate overrun protection on the agg-rate context.
This command is used to enabled (or disable) frame based accounting on all policers and queues associated with the agg-rate context. Only supported on Ethernet ports. Not supported on HSMDA Ethernet ports. Packet byte offset settings are not included in the applied rate when queue frame-based accounting is configured; the offsets are applied to the statistics.
This command defines the enforced aggregate rate for all queues associated with the agg-rate context. A rate must be specified for the agg-rate context to be considered to be active on the context’s object (SAP, subscriber, VPORT etc.).
This command defines a maximum total rate for all egress queues on a service SAP or multi-service site. The agg-rate-limit command is mutually exclusive with the egress scheduler policy. When an egress scheduler policy is defined, the agg-rate-limit command will fail. If the agg-rate-limit command is specified, an attempt to bind a scheduler-policy to the SAP or multi-service site will fail.
A multi-service site must have a port scope defined that ensures all queues associated with the site are on the same port or channel. If the scope is not set to a port, the agg-rate-limit command will fail. Once an agg-rate-limit has been assigned to a multi-service site, the scope cannot be changed to card level.
A port scheduler policy must be applied on the egress port or channel the SAP or multi-service site is bound to in order for the defined agg-rate-limit to take effect. The egress port scheduler enforces the aggregate queue rate as it distributes its bandwidth at the various port priority levels. The port scheduler stops offering bandwidth to member queues once it has detected that the aggregate rate limit has been reached.
If a port scheduler is not defined on the egress port, the queues are allowed to operate based on their own bandwidth parameters.
The no form of the command removes the aggregate rate limit from the SAP or multi-service site.
This command associates an IP filter policy with an ingress or egress Service Access Point (SAP) or IP interface. Filter policies control the forwarding and dropping of packets based on IP matching criteria.
The filter command is used to associate a filter policy with a specified ip-filter-id with an ingress or egress SAP. The ip-filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation will fail and an error message returned.
In general, filters applied to SAPs (ingress or egress) apply to all packets on the SAP. One exception is non-IP packets are not applied to IP match criteria, so the default action in the filter policy applies to these packets.
The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.
This command is used to specify a policer control policy to apply to SAP egress.
N/A
This command enables the context to configure HSMDA queue overrides.
This command configures overrides for a HSMDA queue. The actual valid values are those defined in the given SAP QoS policy.
This command adds or subtracts the specified number of bytes to the accounting function for each packet handled by the HSMDA queue. Normally, the accounting and leaky bucket functions are based on the Ethernet DLC header, payload and the 4 byte CRC (everything except the preamble and inter-frame gap). As an example, the packet-byte-offset command can be used to add the frame encapsulation overhead (20 bytes) to the queues accounting functions.
The accounting functions affected include:
The secondary shaper leaky bucket, scheduler priority level leaky bucket and the port maximum rate updates are not affected by the configured packet-byte-offset. Each of these accounting functions are frame based and always include the preamble, DLC header, payload and the CRC regardless of the configured byte offset.
The packet-byte-offset command accepts either add or subtract as valid keywords which define whether bytes are being added or removed from each packet traversing the queue. Up to 31 bytes may be added to the packet and up to 32 bytes may be removed from the packet. An example use case for subtracting bytes from each packet is an IP based accounting function. Given a Dot1Q encapsulation, the command packet-byte-offset subtract 14 would remove the DLC header and the Dot1Q header from the size of each packet for accounting functions only. The 14 bytes are not actually removed from the packet, only the accounting size of the packet is affected.
As inferred above, the variable accounting size offered by the packet-byte-offset command is targeted at the queue and queue group level. The packet-byte-offset, when set, applies to all queues in the quee group. The accounting size of the packet is ignored by the secondary shapers, the scheduling priority level shapers and the scheduler maximum rate. The actual on-the-wire frame size is used for these functions to allow an accurate representation of the behavior of the subscriberís packets on an Ethernet aggregation network.
The packet-byte-offset value may be overridden at the queue-group level.
This command specifies an existing slope policy name.
This command assigns the weight value to the HSMDA queue.
The no form of the command returns the weight value for the queue to the default value.
This command associates an existing HSMDA weighted-round-robin (WRR) scheduling loop policy to the HSMDA queue.
This command configures an HSMDA secondary shaper. A shaper override can only be configured on an HSMDA SAP.
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to one or more policers created on the SAP through the sap-ingress or sap-egress QoS policies.
The no form of the command is used to remove any existing policer overrides.
no policer-override
This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to a specific policer created on the SAP through a sap-ingress or sap-egress QoS policy.
The no form of the command is used to remove any existing overrides for the specified policer-id.
This command specifies which Dot1Q tag position Dot1P bits in a QinQ encapsulated packet should be used to evaluate Dot1P QoS classification.
The match-qinq-dot1p command allows the top or bottom PBits to be used when evaluating the applied sap-ingress QoS policy’s Dot1P entries. The top and bottom keywords specify which position should be evaluated for QinQ encapsulated packets.
The no form of the command restores the default dot1p evaluation behavior for the SAP.
By default, the bottom most service delineating Dot1Q tags Dot1P bits are used. Table 40 defines the default behavior for Dot1P evaluation when the match-qinq-dot1p command is not executed.
Port / SAP Type | Existing Packet Tags | PBits Used for Match |
null | none | none |
null | Dot1P (VLAN-ID 0) | Dot1P PBits |
null | — | Dot1Q PBits |
null | TopQ BottomQ | TopQ PBits |
null | TopQ (No BottomQ) | TopQ PBits |
Dot1Q | none (Default SAP) | none |
Dot1Q | Dot1P (Default SAP VLAN-ID 0) | Dot1P PBits |
Dot1Q | Dot1Q | Dot1Q PBits |
QinQ / TopQ | TopQ | TopQ PBits |
QinQ / TopQ | TopQ BottomQ | TopQ PBits |
QinQ / QinQ | TopQ BottomQ | BottomQ PBits |
no match-qinq-dot1p - No filtering based on p-bits.
top or bottom must be specified to override the default QinQ dot1p behavior.
Port / SAP Type | Existing Packet Tags | PBits Used for Match |
null | none | none |
null | Dot1P (VLAN-ID 0) | Dot1P PBits |
null | Dot1Q | Dot1Q PBits |
null | TopQ BottomQ | TopQ PBits |
null | TopQ (No BottomQ) | TopQ PBits |
Dot1Q | none (Default SAP) | none |
Dot1Q | Dot1P (Default SAP VLAN-ID 0) | Dot1P PBits |
Dot1Q | Dot1Q | Dot1Q PBits |
QinQ / TopQ | TopQ | TopQ PBits |
QinQ / TopQ | TopQ BottomQ | TopQ PBits |
QinQ / TopQ | TopQ BottomQ | TopQ PBits |
Port / SAP Type | Existing Packet Tags | PBits Used for Match |
null | none | none |
null | Dot1P (VLAN-ID 0) | Dot1P PBits |
null | Dot1Q | Dot1Q PBits |
null | TopQ BottomQ | BottomQ PBits |
null | TopQ (No BottomQ) | TopQ PBits |
Dot1Q | none (default SAP) | none |
Dot1Q | Dot1P (default SAP VLAN-ID 0) | Dot1P PBits |
Dot1Q | Dot1Q | Dot1Q PBits |
QinQ / TopQ | TopQ | TopQ PBits |
QinQ / TopQ | TopQ BottomQ | BottomQ PBits |
QinQ / QinQ | TopQ BottomQ | BottomQ PBits |
Egress SAP Type | Ingress Packet Preserved Dot1P State | Marked (or Remarked) PBits |
null | no preserved Dot1P bits | none |
null | preserved Dot1P bits | preserved tag PBits remarked using dot1p-value |
Dot1Q | no preserved Dot1P bits | new PBits marked using dot1p-value |
Dot1Q | preserved Dot1P bits | preserved tag PBits remarked using dot1p-value |
TopQ | no preserved Dot1P bits | TopQ PBits marked using dot1p-value |
TopQ | preserved Dot1P bits (used as TopQ and BottomQ PBits) | TopQ PBits marked using dot1p-value, BottomQ PBits preserved |
QinQ | no preserved Dot1P bits | TopQ PBits and BottomQ PBits marked using dot1p-value |
QinQ | preserved Dot1P bits (used as TopQ and BottomQ PBits) | TopQ PBits and BottomQ PBits marked using dot1p-value |
The dot1p dot1p-value command must be configured without the qinq-mark-top-only parameter to remove the TopQ PBits only marking restriction.
When enabled (the encapsulation type of the access port where this SAP is defined as qinq), the qinq-mark-top-only command specifies which P-bits/DEI bit to mark during packet egress. When disabled, both set of P-bits/DEI bit are marked. When the enabled, only the P-bits/DEI bit in the top Q-tag are marked.
no qinq-mark-top-only
This command associates a Quality of Service (QoS) policy with an ingress or egress Service Access Point (SAP).
QoS ingress and egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP or IP interface. If the policy- id does not exist, an error will be returned.
The qos command is used to associate both ingress and egress QoS policies. The qos command only allows ingress policies to be associated on SAP ingress and egress policies on SAP egress. Attempts to associate a QoS policy of the wrong type returns an error.
Only one ingress and one egress QoS policy can be associated with a SAP or IP interface at one time. Attempts to associate a second QoS policy of a given type will return an error.
By default, no specific QoS policy is associated with the SAP for ingress or egress, so the default QoS policy is used.
The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.
n/a
This command associates a Quality of Service (QoS) policy with an ingress Service Access Point (SAP).
QoS ingress and egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP. If the policy- id does not exist, an error will be returned.
The qos command is used to associate both ingress and egress QoS policies. The qos command only allows ingress policies to be associated on SAP ingress and egress policies on SAP egress. Attempts to associate a QoS policy of the wrong type returns an error.
Only one ingress and one egress QoS policy can be associated with a SAP or IP interface at one time. Attempts to associate a second QoS policy of a given type will return an error.
By default, no specific QoS policy is associated with the SAP for ingress or egress, so the default QoS policy is used.
The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.
n/a
A queue must be created as multipoint. The multipoint designator cannot be defined after the queue is created. If an attempt is made to modify the command to include the multipoint keyword, an error is generated and the command will not execute.
The multipoint keyword can be entered in the command line on a pre-existing multipoint queue to edit queue-id parameters.
This command applies an existing scheduler policy to an ingress or egress scheduler used by SAP policers and queues associated with this multi-service customer site. The schedulers defined in the scheduler policy can only be created once the customer site has been appropriately assigned to a chassis port, channel or slot. Scheduler policies are defined in the config>qos>scheduler-policy scheduler-policy-name context.
The no form of this command removes the configured ingress or egress scheduler policy from the multi-service customer site. When the policy is removed, the schedulers created due to the policy are removed also making them unavailable for the SAP policers and queues associated with the customer site. Policers and queues that lose their parent scheduler association are deemed to be orphaned and are no longer subject to a virtual scheduler. The SAPs that have policers and queues that rely on the removed schedulers enter into an operational state depicting the orphaned status of one or more policers and queues. When the no scheduler-policy command is executed, the customer site ingress or egress node will not contain an applied scheduler policy.
This command configures the IPSec gateway.
This command enables the context to configure certificate parameters.
This command configures the cert with local file URL.
n/a
This command specifies the cert-profile for the ipsec-tunnel or ipsec-gw. This command will override “cert” and “key” configuration under the ipsec-tunnel or ipsec-gw.
n/a
This command configures the key-pair file to be used for X.509 certificate authentication with this SAP IPSec tunnel.
n/a
This command configures the Certificate-Authority Profile name associated with this SAP IPSec tunnel certificate.
n/a
This command specifies a service ID or service name of the default security service used by this SAP IPSec gateway.
This command configures the default tunnel policy template for the gateway.
This command configures the IKE policy for the gateway.
This command configures the ipsec-gateway local address.
This command specifies the local ID of the router used for IDi or IDr for IKEv2 tunnels. The local-id can only be changed or removed when tunnel or gateway is shutdown.
Default: Depends on local-auth-method such as:
This command specifies the shared secret between the two peers forming the tunnel.
This command configures the radius-accounting-policy.
This command configures the radius-authentication-policy.
This command assigns a pre-configured lag link map profile to a SAP/network interface configured on a LAG or a PW port that exists on a LAG. Once assigned/de-assigned, the SAP/network interface egress traffic will be re-hashed over LAG as required by the new configuration.
The no form of this command reverts the SAP/network interface to use per-flow, service or link hash as configured for the service/LAG.
no lag-link-map-profile
This command creates a new customer site or edits an existing customer site with the customer-site-name parameter. A customer site is an anchor point to create an ingress and egress virtual scheduler hierarchy. When a site is created, it must be assigned to a chassis slot or port on the 7750 SR. When scheduler policies are defined for ingress and egress, the scheduler names contained in each policy are created according to the parameters defined in the policy. Multi-service customer sites exist for the sole purpose of creating a virtual scheduler hierarchy and making it available to queues on multiple Service Access Points (SAPs).
The scheduler policy association with the customer site normally prevents the scheduler policy from being deleted until after the scheduler policy is removed from the customer site. The multi-service-site object will generate a log message indicating that the association was deleted due to scheduler policy removal.
When the multi-service customer site is created, an ingress and egress scheduler policy association does not exist. This does not prevent the site from being assigned to a chassis slot or prevent service SAP assignment. After the site has been created, the ingress and egress scheduler policy associations can be assigned or removed at any time.
n/a — Each customer site must be explicitly created.
If the customer-site-name does not exist, it is assumed that an attempt is being made to create a site of that name in the customer ID context. The success of the command execution depends on the following:
When the maximum number of customer sites has been exceeded a configuration error occurs; the command will not execute and the CLI context will not change.
If the customer-site-name is invalid, a syntax error occurs; the command will not execute and the CLI context will not change.
This command configures a static host on this SAP.
sla-profile sla-profile-name
This optional parameter is used to specify an existing SLA profile name to be associated with the static subscriber host. The SLA profile is configured in the config>subscr-mgmt>sla-profile context.
This command specifies the ANCP string associated to this SAP host.
This command specifies an application profile name.
This command specifies to which intermediate destination (for example a DSLAM) this host belongs.
This command configures managed routes.
This command assigns managed-route to a given subscriber-host. As a consequence, a static route pointing subscriber-host ip address as a next hop will be installed in FIB. Up to 16 managed routes per subscriber-host can be configured.
The no form of the command removes the respective route. Per default, there are no managed-routes configured.
This command specifies an existing SLA profile name to be associated with the static subscriber host. The SLA profile is configured in the config>subscr-mgmt>sla-profile context.
This command specifies an existing subscriber profile name to be associated with the static subscriber host.
This command specifies an existing subscriber identification profile to be associated with the static subscriber host.
This command enables using the SAP ID as subscriber id.
This command enables the context to configure override values for the specified SAP egress or ingress QoS queue. These values override the corresponding ones specified in the associated SAP egress or ingress QoS policy.
This command specifies the ID of the queue whose parameters are to be overridden.
This command can be used to override specific attributes of the specified queue’s adaptation rule parameters. The adaptation rule controls the method used by the system to derive the operational CIR and PIR settings when the queue is provisioned in hardware. For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.
The no form of the command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.
no adaptation-rule
This command configures the average frame overhead to define the average percentage that the offered load to a queue will expand during the frame encapsulation process before sending traffic on-the-wire. While the avg-frame-overhead value may be defined on any queue, it is only used by the system for queues that egress a Sonet or SDH port or channel. Queues operating on egress Ethernet ports automatically calculate the frame encapsulation overhead based on a 20 byte per packet rule (8 bytes for preamble and 12 bytes for Inter-Frame Gap).
When calculating the frame encapsulation overhead for port scheduling purposes, the system determines the following values:
For egress Ethernet queues, the frame encapsulation overhead is calculated by multiplying the number of offered-packets for the queue by 20 bytes. If a queue was offered 50 packets then the frame encapsulation overhead would be 50 x 20 or 1000 octets.
As a special case, when a queue or associated intermediate scheduler is configured with a CIR-weight equal to 0, the system automatically sets the queue’s frame based within-cir offered-load to 0, preventing it from receiving bandwidth during the port scheduler’s within-cir pass.
Port scheduler operation using frame transformed rates — The port scheduler uses the frame based rates to determine the maximum rates that each queue may receive during the within-cir and above-cir bandwidth allocation passes. During the within-cir pass, a queue may receive up to its frame based within-cir offered-load. The maximum it may receive during the above-cir pass is the difference between the frame based within-pir offered load and the amount of actual bandwidth allocated during the within-cir pass.
SAP and subscriber SLA-profile average frame overhead override — The average frame overhead parameter on a sap-egress may be overridden at an individual egress queue basis. On each SAP and within the sla-profile policy used by subscribers an avg-frame-overhead command may be defined under the queue-override context for each queue. When overridden, the queue instance will use its local value for the average frame overhead instead of the sap-egress defined overhead.
The no form of this command restores the average frame overhead parameter for the queue to the default value of 0 percent. When set to 0, the system uses the packet based queue statistics for calculating port scheduler priority bandwidth allocation. If the no avg-frame-overhead command is executed in a queue-override queue id context, the avg-frame-overhead setting for the queue within the sap-egress QoS policy takes effect.
0
This command can be used to override specific attributes of the specified queue’s CBS parameters.
It is permissible, and possibly desirable, to oversubscribe the total CBS reserved buffers for a given access port egress buffer pool. Oversubscription may be desirable due to the potential large number of service queues and the economy of statistical multiplexing the individual queue’s CBS setting into the defined reserved total.
When oversubscribing the reserved total, it is possible for a queue depth to be lower than its CBS setting and still not receive a buffer from the buffer pool for an ingress frame. As more queues are using their CBS buffers and the total in use exceeds the defined reserved total, essentially the buffers are being removed from the shared portion of the pool without the shared in use average and total counts being decremented. This can affect the operation of the high and low priority RED slopes on the pool, causing them to miscalculate when to start randomly drop packets.
If the CBS value is larger than the MBS value, an error will occur, preventing the CBS change.
The no form of this command returns the CBS size to the default value.
no cbs
This command can be used to override specific attributes of the specified queue’s high-prio-only parameters. The high-prio-only command configures the percentage of buffer space for the queue, used exclusively by high priority packets.
The priority of a packet can only be set in the SAP ingress QoS policy and is only applicable on the ingress queues for a SAP. The high-prio-only parameter is used to override the default value derived from the network-queue command.
The defined high-prio-only value cannot be greater than the MBS size of the queue. Attempting to change the MBS to a value smaller than the high priority reserve will generate an error and fail execution. Attempting to set the high-prio-only value larger than the current MBS size will also result in an error and fail execution.
The no form of this command restores the default high priority reserved size.
This command can be used to override specific attributes of the specified queue’s MBS parameters. The MBS is a mechanism to override the default maximum size for the queue.
The sum of the MBS for all queues on an egress access port can oversubscribe the total amount of buffering available. When congestion occurs and buffers become scarce, access to buffers is controlled by the RED slope a packet is associated with. A queue that has not exceeded its MBS size is not guaranteed that a buffer will be available when needed or that the packet’s RED slope will not force the discard of the packet. Setting proper CBS parameters and controlling CBS oversubscription is one major safeguard to queue starvation (when a queue does not receive its fair share of buffers). Another is properly setting the RED slope parameters for the needs of services on this port or channel.
If the CBS value is larger than the MBS value, an error will occur, preventing the MBS change.
The no form of this command returns the MBS size assigned to the queue.
default
For sap>egress>queue-override>queue:
For sap>egress>hsmda-queue-override>queue:
This command can be used to override specific attributes of the specified queue’s MBS parameters. The MBS value is used by a queue to determine whether it has exhausted all of its buffers while enqueuing packets. Once the queue has exceeded the amount of buffers allowed by MBS, all packets are discarded until packets have been drained from the queue.
The sum of the MBS for all queues on an ingress access port can oversubscribe the total amount of buffering available. When congestion occurs and buffers become scarce, access to buffers is controlled by the RED slope a packet is associated with. A queue that has not exceeded its MBS size is not guaranteed that a buffer will be available when needed or that the packet’s RED slope will not force the discard of the packet. Setting proper CBS parameters and controlling CBS oversubscription is one major safeguard to queue starvation (when a queue does not receive its fair share of buffers). Another is properly setting the RED slope parameters for the needs of services on this port or channel.
If the CBS value is larger than the MBS value, an error will occur, preventing the MBS change.
The defined high-prio-only value cannot be greater than the MBS size of the queue. Attempting to change the MBS to a value smaller than the high priority reserve will generate an error and fail execution. Attempting to set the high-prio-only value larger than the current MBS size will also result in an error and fail execution.
The no form of this command returns the MBS size assigned to the queue to the value.
mbs default
This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.
The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy – this allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the SAP/MSS overrides. If the parent scheduler does not exist causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non default weightings for fostered schedulers.
The no form of the command returns the scheduler’s parent weight and cir-weight to the value configured in the applied scheduler policy.
no parent
A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
The percent-rate command supports a queue’s shaping rate and CIR rate as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gigabit and a 10-Gigabit Ethernet port, the queue’s rates will be 10 times greater on the 10 Gigabit port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at anytime.
An egress port queue group queue rate override may be expressed as either a percentage or an explicit rate independent on how the queue's template rate is expressed.
The no form of this command returns the queue to its default shaping rate and cir rate. When no percent-rate is defined within a port egress queue group queue override, the queue reverts to the defined shaping and CIR rates within the egress queue group template associated with the queue.
This command can be used to override specific attributes of the specified queue’s Peak Information Rate (PIR) and the Committed Information Rate (CIR) parameters. The PIR defines the maximum rate that the queue can transmit packets out an egress interface (for SAP egress queues). Defining a PIR does not necessarily guarantee that the queue can transmit at the intended rate. The actual rate sustained by the queue can be limited by oversubscription factors or available egress bandwidth.
The CIR defines the rate at which the system prioritizes the queue over other queues competing for the same bandwidth. In-profile packets are preferentially queued by the system at egress and at subsequent next hop nodes where the packet can traverse. To be properly handled throughout the network, the packets must be marked accordingly for profiling at each hop.
The CIR can be used by the queue’s parent commands cir-level and cir-weight parameters to define the amount of bandwidth considered to be committed for the child queue during bandwidth allocation by the parent scheduler.
The rate command can be executed at any time, altering the PIR and CIR rates for all queues created through the association of the SAP egress QoS policy with the queue-id.
The no form of the command returns all queues created with the queue-id by association with the QoS policy to the default PIR and CIR parameters (max, 0).
rate max cir 0 - The max default specifies the amount of bandwidth in kilobits per second (thousand bits per second). The max value is mutually exclusive to the pir-rate value.
Fractional values are not allowed and must be given as a positive integer.
The actual PIR rate is dependent on the queue’s adaptation-rule parameters and the actual hardware where the queue is provisioned.
Fractional values are not allowed and must be given as a positive integer. The sum keyword specifies that the CIR be used as the summed CIR values of the children schedulers or queues.
This command can be used to override specific attributes of the specified queue’s Peak Information Rate (PIR). The PIR defines the maximum rate that the queue can transmit packets out an egress interface (for SAP egress queues). Defining a PIR does not necessarily guarantee that the queue can transmit at the intended rate. The actual rate sustained by the queue can be limited by oversubscription factors or available egress bandwidth.
The rate command can be executed at any time, altering the PIR rates for all queues created through the association of the SAP egress QoS policy with the queue-id.
The no form of the command returns all queues created with the queue-id by association with the QoS policy to the default PIR parameters (max, 0).
Fractional values are not allowed and must be given as a positive integer.
The actual PIR rate is dependent on the queue’s adaptation-rule parameters and the actual hardware where the queue is provisioned.
This command specifies the set of attributes whose values have been overridden via management on this virtual scheduler. Clearing a given flag will return the corresponding overridden attribute to the value defined on the SAP's ingress scheduler policy.
This command can be used to override specific attributes of the specified scheduler name.
A scheduler defines a bandwidth controls that limit each child (other schedulers, policers, and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have policers, queues, or other schedulers defined as child associations. The scheduler can be a child (take bandwidth from a scheduler in a higher tier, except for schedulers created in tier 1). A total of 32 schedulers can be created within a single scheduler policy with no restriction on the distribution between the tiers.
Each scheduler must have a unique name within the context of the scheduler policy; however the same name can be reused in multiple scheduler policies. If scheduler-name already exists within the policy tier level (regardless of the inclusion of the keyword create), the context changes to that scheduler name for the purpose of editing the scheduler parameters. Modifications made to an existing scheduler are executed on all instantiated schedulers created through association with the policy of the edited scheduler. This can cause queues or schedulers to become orphaned (invalid parent association) and adversely affect the ability of the system to enforce service level agreements (SLAs).
If the scheduler-name exists within the policy on a different tier (regardless of the inclusion of the keyword create), an error occurs and the current CLI context will not change.
If the scheduler-name does not exist in this or another tier within the scheduler policy, it is assumed that an attempt is being made to create a scheduler of that name. The success of the command execution is dependent on the following:
When the maximum number of schedulers has been exceeded on the policy, a configuration error occurs and the command will not execute, nor will the CLI context change.
If the provided scheduler-name is invalid according to the criteria below, a name syntax error will occur, the command will not execute, and the CLI context will not change.
This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.
The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy – this allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the SAP/MSS overrides. If the parent scheduler does not exist causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non default weightings for fostered schedulers.
The no form of the command returns the scheduler’s parent weight and cir-weight to the value configured in the applied scheduler policy.
no parent
A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
This command can be used to override specific attributes of the specified scheduler rate. The rate command defines the maximum bandwidth that the scheduler can offer its child queues or schedulers. The maximum rate is limited to the amount of bandwidth the scheduler can receive from its parent scheduler. If the scheduler has no parent, the maximum rate is assumed to be the amount available to the scheduler. When a parent is associated with the scheduler, the CIR parameter provides the amount of bandwidth to be considered during the parent scheduler’s ‘within CIR’ distribution phase.
The actual operating rate of the scheduler is limited by bandwidth constraints other then its maximum rate. The scheduler’s parent scheduler may not have the available bandwidth to meet the scheduler’s needs or the bandwidth available to the parent scheduler could be allocated to other child schedulers or child policers and queues on the parent based on higher priority. The children of the scheduler may not need the maximum rate available to the scheduler due to insufficient offered load or limits to their own maximum rates.
When a scheduler is defined without specifying a rate, the default rate is max. If the scheduler is a root scheduler (no parent defined), the default maximum rate must be changed to an explicit value. Without this explicit value, the scheduler will assume that an infinite amount of bandwidth is available and allow all child queues and schedulers to operate at their maximum rates.
The no form of this command returns all queues created with this queue-id by association with the QoS policy to the default PIR and CIR parameters.
If the cir is set to max, then the CIR rate is set to infinity, but is limited by the pir-rate.
If the cir is set to sum, then the CIR rate is set to the summed CIR values of the children schedulers, policers, or queues.
This command creates or edits a Virtual Router ID (VRID) on the service IP interface. A VRID is internally represented in conjunction with the IP interface name. This allows the VRID to be used on multiple IP interfaces while representing different virtual router instances.
Two VRRP nodes can be defined on an IP interface. One, both, or none may be defined as owner. The nodal context of vrrp virtual-router-id is used to define the configuration parameters for the VRID.
The no form of this command removes the specified VRID from the IP interface. This terminates VRRP participation for the virtual router and deletes all references to the VRID. The VRID does not need to be shutdown in order to remove the virtual router instance.
n/a
The authentication-key command, within the vrrp virtual-router-id context, is used to assign a simple text password authentication key to generate master VRRP advertisement messages and validate received VRRP advertisement messages.
The authentication-key command is one of the few commands not affected by the presence of the owner keyword. If simple text password authentication is not required, this command is not required. If the command is re-executed with a different password key defined, the new key will be used immediately. If a no authentication-key command is executed, the password authentication key is restored to the default value. The authentication-key command may be executed at any time.
To change the current in-use password key on multiple virtual router instances:
The no form of this command restores the default null string to the value of key.
n/a. The authentication data field contains the value 0 in all 16 octets.
The key parameter is expressed as a string consisting of up to eight alpha-numeric characters. Spaces must be contained in quotation marks ( “ ” ). The quotation marks are not considered part of the string.
The string is case sensitive and is left-justified in the VRRP advertisement message authentication data fields. The first field contains the first four characters with the first octet (starting with IETF RFC bit position 0) containing the first character. The second field holds the fifth through eighth characters. Any unspecified portion of the authentication data field is padded with the value 0 in the corresponding octet.
Exceptions: | Double quote (") | ASCII 34 |
Carriage Return | ASCII 13 | |
Line Feed | ASCII 10 | |
Tab | ASCII 9 | |
Backspace | ASCII 8 |
This is useful when a user must configure the parameter, but, for security purposes, the actual unencrypted key value is not provided.
This command configures virtual router IP addresses for the interface.
This commands assigns a bi-directional forwarding (BFD) session providing heart-beat mechanism for the given VRRP/SRRP instance. There can be only one BFD session assigned to any given VRRP/SRRP instance, but there can be multiple SRRP/VRRP sessions using the same BFD session. If the interface used is configured with centralized BFD, the BFD transmit and receive intervals need to be set to at least 300 ms.
BFD control the state of the associated interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set via the BFD command under the IP interface. The specified interface may not be configured with BFD; when it is, the virtual router will then initiate the BFD session.
The no form of this command removes BFD from the configuration.
n/a
service-id: | 1 to 2147483648 |
svc-name: | Specifies an existing service name up to 64 characters in length |
No service ID indicates a network interface |
This command configures a VRRP initialization delay timer.
no init-delay
This command assigns a specific MAC address to an IP interface.
The no form of this command returns the MAC address of the IP interface to the default value.
The physical MAC address associated with the Ethernet interface that the SAP is configured on.
This command allows the master instance to dictate the master down timer (non-owner context only).
no master-int-inherit
This command sets the advertisement timer and indirectly sets the master down timer on the virtual router instance. The message-interval setting must be the same for all virtual routers participating as a virtual router. Any VRRP advertisement message received with an Advertisement Interval field different than the virtual router instance configured message-interval value will be silently discarded.
The message-interval command is available in both non-owner and owner vrrp virtual-router-id nodal contexts. If the message-interval command is not executed, the default message interval of 1 second will be used.
The no form of this command restores the default message interval value of 1 second to the virtual router instance.
This command enables the non-owner master to reply to ICMP Echo Requests directed at the virtual router instances IP addresses. The ping request can be received on any routed interface.
Ping must not have been disabled at the management security level (either on the parental IP interface or based on the Ping source host address). When ping-reply is not enabled, ICMP Echo Requests to non-owner master virtual IP addresses are silently discarded.
Non-owner backup virtual routers never respond to ICMP Echo Requests regardless of the setting of ping-reply configuration.
The ping-reply command is only available in non-owner vrrp virtual-router-id nodal context. If the ping-reply command is not executed, ICMP Echo Requests to the virtual router instance IP addresses will be silently discarded.
The no form of this command restores the default operation of discarding all ICMP Echo Request messages destined to the non-owner virtual router instance IP addresses.
no ping-reply
This command associates a VRRP priority control policy with the virtual router instance (non-owner context only).
The preempt mode value controls whether a specific backup virtual router preempts a lower priority master.
When preempt is enabled, the virtual router instance overrides any non-owner master with an “in use” message priority value less than the virtual router instance in-use priority value. If preempt is disabled, the virtual router only becomes master if the master down timer expires before a VRRP advertisement message is received from another virtual router.
The IP address owner will always become master when available. Preempt mode cannot be disabled on the owner virtual router.
The default value for preempt mode is enabled.
preempt
The priority command provides the ability to configure a specific priority value to the virtual router instance. In conjunction with an optional policy command, the base-priority is used to derive the in-use priority of the virtual router instance.
The priority command is only available in the non-owner vrrp virtual-router-id nodal context. The priority of owner virtual router instances is permanently set to 255 and cannot be changed. For non-owner virtual router instances, if the priority command is not executed, the base-priority will be set to 100.
The no form of this command restores the default value of 100 to base-priority.
This command enables the non-owner master to reply to SSH Requests directed at the virtual router instance’s IP addresses. The SSH request can be received on any routed interface. SSH must not have been disabled at the management security level (either on the parental IP interface or based on the SSH source host address). Proper login and CLI command authentication is still enforced.
When ssh-reply is not enabled, SSH packets to non-owner master virtual IP addresses are silently discarded. Non-owner backup virtual routers never respond to SSH regardless of the ssh-reply configuration.
The ssh-reply command is only available in non-owner vrrp virtual-router-id nodal context. If the ssh-reply command is not executed, SSH packets to the virtual router instance IP addresses will be silently discarded.
The no form of this command restores the default operation of discarding all SSH packets destined to the non-owner virtual router instance IP addresses.
no ssh-reply
This command allows the forwarding of packets by a standby router.
The no form of the command specifies that a standby router should not forward traffic sent to virtual router's MAC address. However, the standby router should forward traffic sent to the standby router’s real MAC address.
no standby-forwarding
This command enables the non-owner master to reply to TCP port 23 Telnet Requests directed at the virtual router instance’s IP addresses. The Telnet request can be received on any routed interface. Telnet must not have been disabled at the management security level (either on the parental IP interface or based on the Telnet source host address). Proper login and CLI command authentication is still enforced.
When telnet-reply is not enabled, TCP port 23 Telnet packets to non-owner master virtual IP addresses are silently discarded.
Non-owner backup virtual routers never respond to Telnet Requests regardless of the telnet-reply configuration.
The telnet-reply command is only available in non-owner VRRP nodal context. If the telnet-reply command is not executed, Telnet packets to the virtual router instance IP addresses will be silently discarded.
The no form of this command restores the default operation of discarding all Telnet packets destined to the non-owner virtual router instance IP addresses.
no telnet-reply
This command is valid only if the VRRP virtual router instance associated with this entry is a non-owner.
When this command is enabled, a non-owner master can reply to traceroute requests directed to the virtual router instance IP addresses.
A non-owner backup virtual router never responds to such traceroute requests regardless of the trace-route-reply status.
no traceroute-reply
This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters which identifies the service access point on the interface and within the router. Each SAP must be unique.
All SAPs must be explicitly created. If no SAPs are created within a service or on an IP interface, a SAP will not exist on that object. Enter an existing SAP without the create keyword to edit SAP parameters. The SAP is owned by the service in which it was created.
A SAP can only be associated with a single service. A SAP can only be defined on a port that has been configured as an access port using the config interface port-type port-id mode access command. Channelized TDM ports are always access ports.
If a port is shutdown, all SAPs on that port become operationally down. When a service is shutdown, SAPs for the service are not displayed as operationally down although all traffic traversing the service will be discarded. The operational state of a SAP is relative to the operational state of the port on which the SAP is defined.
The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP will also be deleted. The no form of the command cuases the ptp-h-assist to be disabled.
No SAPs are defined.
sap ipsec-id.private | public:tag — This parameter associates an IPSec group SAP with this interface. This is the public side for an IPSec tunnel. Tunnels referencing this IPSec group in the private side may be created if their local IP is in the subnet of the interface subnet and the routing context specified matches with the one of the interface.
This context will provide a SAP to the tunnel. The operator may associate an ingress and egress QoS policies as well as filters and virtual scheduling contexts. Internally this creates an Ethernet SAP that will be used to send and receive encrypted traffic to and from the MDA. Multiple tunnels can be associated with this SAP. The “tag” will be a dot1q value. The operator may see it as an identifier. The range is limited to 1 to 4094.
If the card in the slot has Media Dependent Adapters (MDAs) installed, the port-id must be in the slot_number/MDA_number/port_number format. For example 6/2/3 specifies port 3 on MDA 2 in slot 6.
The port-id must reference a valid port type. When the port-id parameter represents SONET/SDH and TDM channels the port ID must include the channel ID. A period “.” separates the physical port from the channel-id. The port must be configured as an access port.
If the SONET/SDH port is configured as clear-channel then only the port is specified.
port-id | slot/mda/port [.channel] | ||
eth-sat-id | esat-id/slot/port | ||
esat | keyword | ||
id | 1 to 20 | ||
pxc-id | pxc-id.sub-port | ||
pxc | keyword | ||
id | 1 to 64 | ||
sub-port | a, b |
This command associates an AARP instance with a multi-homed SAP or spoke SDP. This instance uses the same AARP ID in the same node or in a peer node (pre-configured) to provide traffic flow and packet asymmetry removal for a multi-homed SAP or spoke SDP.
The type specifies the role of this service point in the AARP: either, primary (dual-homed) or secondary (dual-homed-secondary). The AA service attributes (app-profile and transit-policy) of the primary are inherited by the secondary endpoints. All endpoints within an AARP must be of the same type (SAP or spoke), and all endpoints with an AARP must be within the same service.
The no form of the command removes the association between an AARP instance and a multi-homed SAP or spoke SDP.
no aarp
This command associates an AA transit policy to the service. The transit IP policy must be defined prior to associating the policy with a SAP in the config>application assurance>group>policy>transit-ip-policy context.
Transit AA subscribers are managed by the system through this service policy, which determines how transit subs are created and removed for that service.
The no form of the command removes the association of the policy to the service.
no transit-policy
This command creates the accounting policy context that can be applied to an interface SAP or interface SAP spoke SDP.
An accounting policy must be defined before it can be associated with a SAP. If the policy-id does not exist, an error message is generated.
A maximum of one accounting policy can be associated with a SAP at one time. Accounting policies are configured in the config>log context.
The no form of this command removes the accounting policy association from the SAP, and the accounting policy reverts to the default.
default accounting policy
This command configures the application profile name.
This command enables VCCV BFD on the PW associated with the VLL, BGP VPWS, or VPLS service. The parameters for the BFD session are derived from the named BFD template, which must have been first configured using the bfd-template command.
This command configures a named BFD template to be used by VCCV BFD on PWs belonging to the VLL, BGP VPWS, or VPLS service. The template specifies parameters, such as the minimum transmit and receive control packet timer intervals, to be used by the BFD session. Template parameters are configured under the config>router>bfd context.
no bfd-template
This command enables accounting and statistical data collection for either an interface SAP or interface SAP spoke SDP, or network port. When applying accounting policies the data, by default, is collected in the appropriate records and written to the designated billing file.
When the no collect-stats command is issued the statistics are still accumulated by the IOM cards. However, the CPU will not obtain the results and write them to the billing file. If a subsequent collect-stats command is issued then the counters written to the billing file include all the traffic while the no collect-stats command was in effect.
no collect-stats
This command assigns an existing CPU protection policy to the associated group interface. The CPU protection policies are configured in the config>sys>security>cpu-protection>policy cpu-protection-policy-id context.
If no CPU-Protection policy is assigned to a group interface SAP, then the default policy is used to limit the overall-rate. The default policy is policy number 254 for access interfaces and 255 for network interfaces.
The no form of the command removes the association of the CPU protection policy from the associated interface and reverts to the default policy values.
cpu-protection 254 (for access interfaces); cpu-protection 255 (for network interfaces)
The configuration of no cpu-protection returns the interface/SAP to the default policies as shown above.
This command assigns a Distributed CPU Protection (DCP) policy to the SAP. Only a valid created DCP policy can be assigned to a SAP or a network interface (This rule does not apply to templates such as an msap-policy).
no dist-cpu-protection
This command configures the default-host to be used. More than one default-host can be configured per SAP.
The no form of the command removes the values from the configuration.
This command configures the source IPv4 or IPv6 address to use for an IP tunnel. This configuration applies to the outer IP header of the encapsulated packets. The IPv4 or IPv6 address must belong to the one of the IP subnets associated with the public SAP interface of the tunnel-group. The source address, remote-ip address and backup-remote-ip address of a tunnel must all belong to the same address family (IPv4 or IPv6). When the source address contains an IPv6 address it must be a global unicast address.
no source
This command configures the primary destination IPv4 or IPv6 address to use for an IP tunnel. This configuration applies to the outer IP header of the encapsulated packets. The source address, remote-ip address and backup-remote-ip address of a tunnel must all belong to the same address family (IPv4 or IPv6). When the remote-ip address contains an IPv6 address it must be a global unicast address.
no remote-ip
This command configures the alternate destination IPv4 or IPv6 address to use for an IP tunnel. This destination address is used only if the primary destination configured with the remote-ip command is unreachable in the delivery service. The source address, remote-ip address and backup-remote-ip address of a tunnel must all belong to the same address family (IPv4 or IPv6). When the backup-remote-ip address contains an IPv6 address it must be a global unicast address.
no remote-ip
The vpls command, within the IP interface context, is used to bind the IP interface to the specified service name.
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 will be 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 will be 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 will be 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 will be 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.
IES Chassis Mode Dependency
An IES IP interface cannot be bound to a service name unless the system is configured in chassis mode D Once an IES interface is bound to a service name, the chassis mode of the system cannot be changed to B or C.
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 FlexPath forwarding plane. Currently, these include the IOM3-XP, the various IMM modules and the SR7710c12. If any SAPs are associated with the wrong hardware type, the service name binding to the VPRN IP interface will fail. Once an IP interface within the VPRN service is bound to a service name, attempting to create a SAP on excluded hardware will fail.
Route Export and Import between Routing Contexts
The IES chassis mode dependency and the VPRN hardware dependency each are designed to prevent a condition where an ingress routing decision on hardware that does not support the mixed Layer 2 and Layer 3 behavior of routed VPLS is asked to route to a VPLS based next-hop.
Even with these restrictions, it is still possible using route leaking or import/export routing policies to create a condition where a FlexPath forwarding plane resolves a route to a VPLS next-hop. In this case, the forwarding plane handles the resolved next-hop as if it points to a null IP interface. Packets associated with a null next-hop egress IP interface will be discarded and an ICPM unreachable message will be generated when enabled.
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 the 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.
n/a
The ingress node in this context under the vpls binding is used to define the routed IPv4 and IPv6 optional filter overrides.
The v4-routed-override-filter command is used to specify an IPv4 filter ID that will be 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 packets will use the any existing ingress IPv4 filter on the VPLS virtual port.
The no form of the command is used to remove 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.
n/a
The v6-routed-override-filter command is used to specify an IPv6 filter ID that will be 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 will use the 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 packets virtual port when defined.
n/a
The egress node under the vpls binding is used to define the optional sap-egress QoS policy that will be used for reclassifying the egress forwarding class or profile for routed packets associated with the IP interface on the attached VPLS service context.
The reclassify-using-qos command is used to specify a sap-egress QoS policy that will be used to reclassify the forwarding class and profile of egress routed packets on the VPLS service. When routed packets associated with the IP interface egress a VPLS SAP, the reclassification rules within the sap-egress QoS policy applied to the SAP are always ignored (even when reclassify-using-qos is not defined).
Any queues or policers defined within the specified QoS policy are ignored and are not created on the VPLS egress SAPs. Instead, the routed packets continue to use the forwarding class mappings, queues and policers from the sap-egress QoS policy applied to the egress VPLS SAP.
While the specified sap-egress policy ID is applied to an IP interface it cannot be deleted from the system.
The no form of the command removes the sap-egress QoS policy used for reclassification from the egress IP interface. When removed, IP routed packets will not be reclassified on the egress SAPs of the VPLS service attached to the IP interface.
This command sets a flag on the VPLS service that enables the ability to attach an IES or VPRN IP interface to the VPLS service in order to make the VPLS service routable. When the allow-ip-int-bind command is not enabled, the VPLS service cannot be attached to an IP interface.
VPLS Configuration Constraints for Enabling allow-ip-int-bind
When attempting to set the allow-ip-int-bind VPLS flag, the system first checks to see if the correct configuration constraints exist for the VPLS service and the network ports. The following VPLS features must be disabled or not configured for the allow-ip-int-bind flag to set:
Once the VPLS allow-ip-int-bind flag is set on a VPLS service, the above features cannot be enabled on the VPLS service.
Network Port Hardware Constraints
The system also checks to ensure that all ports configured in network mode are associated with FlexPath forwarding planes. If a port is currently in network mode and the port is associated with a FlexPath forwarding plane, the allow-ip-int-bind command will fail. Once the allow-ip-int-bind flag is set on any VPLS service, attempting to enable network mode on a port associated with a FlexPath forwarding plane will fail.
VPLS SAP Hardware Constraints
Besides VPLS configuration and network port hardware association, the system also checks to that all SAPs within the VPLS are created on Ethernet ports and the ports are associated with FlexPath forwarding planes. Certain Ethernet ports and virtual Ethernet ports are not supported which include HSMDA ports and CCAG virtual ports (VSM based). If a SAP in the VPLS exists on an unsupported port type or is associated with a FlexPath forwarding plane, the allow-ip-int-bind command will fail. Once the allow-ip-int-bind flag is set on the VPLS service, attempting to create a VPLS SAP on the wrong port type or associated with a FlexPath forwarding plane will fail.
VPLS Service Name Bound to IP Interface without allow-ip-int-bind flag Set
In the event that a service name is applied to a VPLS service and that service name is also bound to an IP interface but the allow-ip-int-bind flag has not been set on the VPLS service context, the system attempt to resolve the service name between the VPLS service and the IP interface will fail. After the allow-ip-int-bind flag is successfully set on the VPLS service, either the service name on the VPLS service must be removed and reapplied or the IP interface must be re-initialized using the shutdown / no shutdown commands. This will cause the system to reattempt the name resolution process between the IP interface and the VPLS service.
The no form of the command resets the allow-ip-int-bind flag on the VPLS service. If the VPLS service currently has an IP interface from an IES or VPRN service attached, the no allow-ip-int-bind command will fail. Once the allow-ip-int-bind flag is reset on the VPLS service, the configuration and hardware restrictions associated with setting the flag are removed. The port network mode hardware restrictions are also removed.
This command enables the context to configure network parameters for the VPRN service.
This command enables the context to configure network ingress parameters for the VPRN service.
This command is used to redirect unicast packets arriving on an automatically (using the auto-bind command) or manually configured (using a spoke-sdp command, but not the spoke-sdp command under the VPRN IP interface) binding in a VPRN to a policer in an ingress forwarding plane queue-group for the purpose of rate-limiting.
For the policer to be used, the following must be true:
The command will fail if the queue group template name does not exist or if the policer specified in the network QoS policy does not exist in the queue group template. If the queue group template name with the specified instance is not applied to the forwarding plane on which the VPRN binding unicast traffic arrives then this traffic will use the ingress network queues related to the network interface, however, the ingress classification is still based on the applied network QoS policy.
The unicast traffic can be redirected to a policer under the forwarding class fp-redirect-group command in the ingress section of a network QoS policy; any fp-redirect-group multicast-policer, broadcast-policer or unknown-policer commands are ignored for this traffic. Multicast traffic would use the ingress network queues or queue group related to the network interface.
Ingress classification is based on the configuration of the ingress section of the specified network QoS policy, noting that the dot1p and exp classification is based on the outer Ethernet header and MPLS label whereas the DSCP applies to the outer IP header if the tunnel encapsulation is GRE, or the DSCP in the first IP header in the payload if ler-use-dscp is enabled in the ingress section of the referenced network QoS policy.
When this command is applied, it overrides the QoS applied to the related network interfaces for unicast traffic arriving on bindings in that VPRN.
The no version of this command removes the redirection of VPRN binding traffic to the queue-group policers.
This command enables the context to configure subscriber management parameters for this SAP.
no sub-sla-mgmt
This command specifies a default SLA profile for this SAP. The SLA profile must be defined prior to associating the profile with a SAP in the config>subscriber-mgmt>sla-profile context.
An SLA profile is a named group of QoS parameters used to define per service QoS for all subscriber hosts common to the same subscriber within a provider service offering. A single SLA profile may define the QoS parameters for multiple subscriber hosts. SLA profiles are maintained in two locations, the subscriber identification policy and the subscriber profile templates. After a subscriber host is associated with an SLA profile name, either the subscriber identification policy used to identify the subscriber or the subscriber profile associated with the subscriber host must contain an SLA profile with that name. If both the subscriber identification policy and the subscriber profile contain the SLA profile name, the SLA profile in the subscriber profile is used.
The no form of the command removes the default SLA profile from the SAP configuration.
no def-sla-profile
This command specifies a default subscriber profile for this SAP. The subscriber profile must be defined prior to associating the profile with a SAP in the config>subscriber-mgmt>sub-profile context.
A subscriber profile defines the aggregate QoS for all hosts within a subscriber context. This is done through the definition of the egress and ingress scheduler policies that govern the aggregate SLA for subscriber using the subscriber profile. Subscriber profiles also allow for specific SLA profile definitions when the default definitions from the subscriber identification policy must be overridden.
The no form of the command removes the default SLA profile from the SAP configuration.
This command configures the maximum number of subscribers for this SAP. It is used in conjunction with the profiled-traffic-only command on single subscriber SAPs and creates a subscriber host which is used to forward non-IP traffic through the single subscriber SAP without the need for SAP queues.
The no form of this command returns the default value.
1
This command enables the context to configure single subscriber parameters for this SAP.
This command configures non-subscriber traffic profiles. It is used in conjunction with the profiled-traffic-only command on single subscriber SAPs and creates a subscriber host which is used to forward non-IP traffic through the single subscriber SAP without the need for SAP queues.
The no form of the command removes removes the profiles and disables the feature.
If the static subscriber host’s sub-ident string is not defined, the host is not considered to belong to the same subscriber as another host on the SAP.
If source or destination host is unknown, the hosts are not considered to belong to the same subscriber. ARP messages from unknown hosts are subject to anti-spoof filtering rules applied at the SAP.
If sub-ident is not enabled on the SAP arp-reply-agent, subscriber identification matching is not performed on ARP requests received on the SAP.
ARP requests are never forwarded back to the same SAP or within the receiving SAP’s split horizon group.
This command enables profiled traffic only for this SAP. The profiled traffic refers to single subscriber traffic on a dedicated SAP (in the VLAN-per-subscriber model). When enabled, subscriber queues are instantiated through the QOS policy defined in the sla-profile and the associated SAP queues are deleted. This can increase subscriber scaling by reducing the number of queues instantiated per subscriber (in the VLAN-per-subscriber model). In order for this to be achieved, any configured multi-sub-sap limit must be removed (leaving the default of 1).
The no form of the command disables the command.
This command associates a subscriber identification policy to this SAP. The subscriber identification policy must be defined prior to associating the profile with a SAP in the config>subscriber-mgmt>sub-ident-policy context.
Subscribers are managed by the system through the use of subscriber identification strings. A subscriber identification string uniquely identifies a subscriber. For static hosts, the subscriber identification string is explicitly defined with each static subscriber host.
For dynamic hosts, the subscriber identification string must be derived from the DHCP ACK message sent to the subscriber host. The default value for the string is the content of Option 82 CIRCUIT-ID and REMOTE-ID fields interpreted as an octet string. As an option, the DHCP ACK message may be processed by a subscriber identification policy which has the capability to parse the message into an alternative ASCII or octet string value.
When multiple hosts on the same port are associated with the same subscriber identification string they are considered to be host members of the same subscriber.
The no form of the command removes the default subscriber identification policy from the SAP configuration.
no sub-ident-policy
This command creates an SRRP instance on a group IP interface. An SRRP instance manages all subscriber subnets within the group interfaces subscriber IP interface or other subscriber IP interfaces that are associated through a wholesale/retail relationship. Only one unique SRRP instance can be configured per group interface.
The no form of the command removes an SRRP instance from a group IP interface. Once removed, the group interface ignores ARP requests for the SRRP gateway IP addresses that may exist on subscriber subnets associated with the group IP interface. Then the group interface stops routing using the redundant IP interface associated with the group IP interface and will stop routing with the SRRP gateway MAC address. Ingress packets destined to the SRRP gateway MAC will also be silently discarded. This is the same behavior as a group IP interface that is disabled (shutdown).
no srrp
This command overrides the default SRRP gateway MAC address used by the SRRP instance. Unless specified, the system uses the same base MAC address for all SRRP instances with the last octet overridden by the lower 8 bits of the SRRP instance ID. The same SRRP gateway MAC address should be in-use by both the local and remote routers participating in the same SRRP context.
One reason to change the default SRRP gateway MAC address is if two SRRP instances sharing the same broadcast domain are using the same SRRP gateway MAC. The system will use the SRRP instance ID to separate the SRRP messages (by ignoring the messages that does not match the local instance ID), but a unique SRRP gateway MAC is essential to separate the routed packets for each gateway IP address.
The no form of the command removes the explicit SRRP gateway MAC address from the SRRP instance. The SRRP gateway MAC address can only be changed or removed when the SRRP instance is shutdown.
This command defines the interval between SRRP advertisement messages sent when operating in the master state. The interval is also the basis for setting the master-down timer used to determine when the master is no longer sending. The system uses three times the keep-alive interval to set the timer. Every time an SRRP advertisement is seen that is better then the local priority, the timer is reset. If the timer expires, the SRRP instance assumes that a master does not exist and initiates the attempt to become master.
When in backup state, the SRRP instance takes the keep-alive interval of the master as represented in the masters SRRP advertisement message. Once in master state, the SRRP instance uses its own configured keep-alive interval.
The keep-alive-interval may be changed at anytime, but will have no effect until the SRRP instance is in the master state.
The no form of the command restores the default interval.
This command defines a specific SAP for SRRP in-band messaging. A message-path SAP must be defined prior to activating the SRRP instance. The defined SAP must exist on the SRRP instances group IP interface for the command to succeed and cannot currently be associated with any dynamic or static subscriber hosts. Once a group IP interface SAP has been defined as the transmission path for SRRP Advertisement messages, it cannot be administratively shutdown, will not support static or dynamic subscriber hosts and cannot be removed from the group IP interface.
The SRRP instance message-path command may be executed at anytime on the SRRP instance. Changing the message SAP will fail if a dynamic or static subscriber host is associated with the new SAP. Once successfully changed, the SRRP instance will immediately disable anti-spoof on the SAP and start sending SRRP Advertisement messages if the SRRP instance is activated.
Changing the current SRRP message SAP on an active pair of routers should be done in the following manner:
Shutting down the backup SRRP instance prevents the SRRP instances from becoming master due to temporarily using differing message path SAPs.
If an MCS peering is operational between the redundant nodes and the SRRP instance has been associated with the peering, the designated message path SAP will be sent from each member.
The no form of the command can only be executed when the SRRP instance is shutdown. Executing no message-path allows the existing SAP to be used for subscriber management functions. A new message-path SAP must be defined prior to activating the SRRP instance.
This command associates one or more VRRP policies with the SRRP instance. A VRRP policy is a collection of connectivity and verification tests used to manipulate the in-use priorities of VRRP and SRRP instances. A VRRP policy can test the link state of ports, ping IP hosts, discover the existence of routes in the routing table or the ability to reach Layer 2 hosts. When one or more of these tests fail, the VRRP policy has the option of decrementing or setting an explicit value for the in-use priority of an SRRP instance.
More than one VRRP policy may be associated with an SRRP instance. When more than one VRRP policy is associated with an SRRP instance the delta decrement of the in-use priority is cumulative unless one or more test fail that have explicit priority values. When one or more explicit tests fail, the lowest priority value event takes effect for the SRRP instance. When the highest delta-in-use-limit is used to manage the lowest delta derived in-use priority for the SRRP instance.
VRRP policy associations may be added and removed at anytime. A maximum of two VRRP policies can be associated with a single SRRP instance.
The no form of the command removes the association with vrrp-policy-id from the SRRP instance.
This command overrides the default base priority for the SRRP instance. The SRRP instance priority is advertised by the SRRP instance to its neighbor router and is compared to the priority received from the neighbor router. The router with the best (highest) priority enters the master state while the other router enters the backup state. If the priority of each router is the same, the router with the lowest source IP address in the SRRP advertisement message assumes the master state.
The base priority of an SRRP instance can be managed by VRRP policies. A VRRP policy defines a set of connectivity or verification tests which, when they fail, may lower an SRRP instances base priority (creating an in-use priority for the instance). Every time an SRRP instances in-use priority changes when in master state, it sends an SRRP advertisement message with the new priority. If the dynamic priority drops to zero or receives an SRRP Advertisement message with a better priority, the SRRP instance transitions to the becoming backup state.
When the priority command is not specified, or the no priority command is executed, the system uses a default base priority of 100. The priority command may be executed at anytime.
The no form of the command restores the default base priority to the SRRP instance. If a VRRP policy is associated with the SRRP instance, it will use the default base priority as the basis for any modifications to the SRRP instances in-use priority.
This command sends FIB population packets.
The no form of the command disables sending FIB population packets.
all
This command sends GARP packets to outer VLANs only.
The no form of the command disables sending GARP packets to outer VLANs only.
no send-fib-population-packets
This command enables the BGP protocol with the VPRN service.
The no form of the command disables the BGP protocol from the given VPRN service.
no bgp
This command enables all BGP peers within a VPRN instance to share a single CPM queue. This command takes affect on new BGP connections established; already established BGP peers continue to use their own CPM queue. Any changes to PIR/CIR of the shared queue takes effect only after BGP connections are re-established.
This command enables or disables the advertising of inactive BGP routers to other BGP peers.
By default, BGP only advertises BGP routes to other BGP peers if a given BGP route is chosen by the route table manager as the most preferred route within the system and is active in the forwarding plane. This command allows system administrators to advertise a BGP route even though it is not the most preferred route within the system for a given destination.
no advertise-inactive
This command is used to set the router ID in the BGP aggregator path attribute to zero when BGP aggregates routes. This prevents different routers within an AS from creating aggregate routes that contain different AS paths.
When BGP is aggregating routes, it adds the aggregator path attribute to the BGP update messages. By default, BGP adds the AS number and router ID to the aggregator path attribute.
When this command is enabled, BGP adds the router ID to the aggregator path attribute. This command is used at the group level to revert to the value defined under the global level, while this command is used at the neighbor level to revert to the value defined under the group level.
The no form of the command used at the global level reverts to default where BGP adds the AS number and router ID to the aggregator path attribute.
The no form of the command used at the group level reverts to the value defined at the group level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
no aggregator-id-zero — BGP adds the AS number and router ID to the aggregator path attribute.
This command configures the comparison of BGP routes based on the MED attribute. The default behavior of SR-OS (equivalent to the no form of the command) is to only compare two routes on the basis of MED if they have the same neighbor AS (the first non-confed AS in the received AS_PATH attribute). Also by default, a route without a MED attribute is handled the same as though it had a MED attribute with the value 0. The always-compare-med command without the strict-as keyword allows MED to be compared even if the paths have a different neighbor AS; in this case, if neither zero or infinity is specified, the zero option is inferred, meaning a route without a MED is handled the same as though it had a MED attribute with the value 0. When the strict-as keyword is present, MED is only compared between paths from the same neighbor AS, and in this case, zero or infinity is mandatory and tells BGP how to interpret paths without a MED attribute.
no always-compare-med
This command configures whether AS path length is considered in the selection of the best BGP route for a prefix.
If an address family is listed in this command, then the length of AS paths is not a factor in the route selection process for routes of that address family.
The no form of the command removes the parameter from the configuration.
no as-path-ignore
This command controls how the BGP decision process compares routes on the basis of MED. When deterministic-med is configured, BGP groups paths that are equal up to the MED comparison step based on neighbor AS, and then compares the best path from each group to arrive at the overall best path. This change to the BGP decision process makes best path selection completely deterministic in all cases. Without deterministic-med, the overall best path selection is sometimes dependent on the order of the route arrival because of the rule that MED cannot be compared in routes from different neighbor AS.
no deterministic-med
This command instructs the BGP decision process to ignore the difference between EBGP and IBGP routes in selecting the best path and eligible multipaths (if multipath and ECMP are enabled). The result is a form of EIBGP load-balancing in a multipath scenario.
By default (with the no form of the command), the BGP decision process prefers an EBGP learned route over an IBGP learned route.
The behavior can be applied selectively to only certain types of routes by specifying one or more address family names in the command. If no families are specified, the command applies to IPv4 and IPv6 routes, and VPN-IPv4 and VPN-IPv6 routes.
no ebgp-ibg-equal
This command replaces all instances of the peer's AS number with the local AS number in a BGP route's AS_PATH.
This command breaks BGP's loop detection mechanism. It should be used carefully.
as-override is not enabled by default.
This command configures the BGP authentication key.
Authentication is performed between neighboring routers before setting up the BGP session by verifying the password. Authentication is performed using the MD-5 message-based digest. The authentication key can be any combination of letters or numbers from 1 to 16.
The no form of the command removes the authentication password from the configuration and effectively disables authentication.
Authentication is disabled and the authentication password is empty.
This is useful when a user must configure the parameter, but, for security purposes, the actual unencrypted key value is not provided.
This command configures the BGP authentication key for all peers.
The keychain allows the rollover of authentication keys during the lifetime of a session.
no auth-keychain
This command enables path selection configuration.
This command instructs BGP to disregard the resolved distance to the BGP next-hop in its decision process for selecting the best route to a destination. When configured in the config>router>bgp>best-path-selection context, this command applies to the comparison of two BGP routes with the same NLRI learned from base router BGP peers. When configured in the config>service>vprn context, this command applies to the comparison of two BGP-VPN routes for the same IP prefix imported into the VPRN from the base router BGP instance. When configured in the config>service>vprn>bgp>best-path-selection context, this command applies to the comparison of two BGP routes for the same IP prefix learned from VPRN BGP peers.
The no form of the command (no ignore-nh-metric) restores the default behavior whereby BGP factors distance to the next-hop into its decision process.
no ignore-nh-metric
When the ignore-router-id command is present and the current best path to a destination was learned from EBGP peer X with BGP identifier x and a new path is received from EBGP peer Y with BGP identifier y the best path remains unchanged if the new path is equivalent to the current best path up to the BGP identifier comparison – even if y is less than x. The no form of the command restores the default behavior of selecting the route with the lowest BGP identifier (y) as best.
no ignore-router-id
This command enables the use of bi-directional forwarding (BFD) to control the state of the associated protocol interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set via the BFD command under the IP interface.
The no form of this command removes BFD from the associated BGP protocol peering.
no bfd-enable
This command configures the cluster ID for a route reflector server.
Route reflectors are used to reduce the number of IBGP sessions required within an AS. Normally, all BGP speakers within an AS must have a BGP peering with every other BGP speaker in an AS. A route reflector and its clients form a cluster. Peers that are not part of the cluster are considered to be non-clients.
When a route reflector receives a route, first it must select the best path from all the paths received. If the route was received from a non-client peer, then the route reflector sends the route to all clients in the cluster. If the route came from a client peer, the route reflector sends the route to all non-client peers and to all client peers except the originator.
For redundancy, a cluster can have multiple route reflectors.
Confederations can also be used to remove the full IBGP mesh requirement within an AS.
The no form of the command deletes the cluster ID and effectively disables the Route Reflection for the given group.
no cluster — No cluster ID is defined.
This command configures the BGP connect retry timer value in seconds.
When this timer expires, BGP tries to reconnect to the configured peer. This configuration parameter can be set at three levels: global level (applies to all peers), peer-group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific value is used.
The no form of the command used at the global level reverts to the default value.
The no form of the command used at the group level reverts to the value defined at the global level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
120 seconds
This command controls how long a BGP peer session remains in the idle-state after some type of error causes the session to reset. In the idle state, BGP does not initiate or respond to attempts to establish a new session. Repeated errors that occur a short while after each session reset cause longer and longer hold times in the idle state. This command supports the DampPeerOscillations FSM behavior described in section 8.1 of RFC 4271, A Border Gateway Protocol 4 (BGP-4).
The default behavior, which applies when no damp-peer-oscillations is configured, is to immediately transition out of the idle-state after every reset.
no damp-peer-oscillations
This command enables BGP route damping for learned routes which are defined within the route policy. Use damping to reduce the number of update messages sent between BGP peers and reduce the load on peers without affecting the route convergence time for stable routes. Damping parameters are set via route policy definition.
The no form of the command used at the global level disables route damping.
The no form of the command used at the group level reverts to the value defined at the global level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
When damping is enabled and the route policy does not specify a damping profile, the default damping profile is used. This profile is always present and consists of the following parameters:
Half-life: 15 minutes
Max-suppress: 60 minutes
Suppress-threshold: 3000
Reuse-threshold: 750
no damping — Learned route damping is disabled.
This command disables the use of 4-byte ASNs. It can be configured at all 3 level of the hierarchy so it can be specified down to the per peer basis.
If this command is enabled 4-byte ASN support should not be negotiated with the associated remote peer(s).
The no form of the command resets the behavior to the default which is to enable the use of 4-byte ASN.
This command disables the exchange of capabilities. When command is enabled and after the peering is flapped, any new capabilities are not negotiated and will strictly support IPv4 routing exchanges with that peer.
The no form of the command removes this command from the configuration and restores the normal behavior.
no disable-capability-negotiation
This command disables the reflection of routes by the route reflector to the group or neighbor. This only disables the reflection of routes from other client peers. Routes learned from non-client peers are still reflected to all clients.
The no form re-enables client reflection of routes.
no disable-client-reflect — Client routes are reflected to all client peers.
This command configures BGP to disable sending communities.
This command configures BGP fast external failover.
This command configures the maximum number of dynamic BGP sessions that will be accepted from remote peers associated with the entire BGP instance or a specific peer group. If accepting a new dynamic session would cause either the group limit or the instance limit to be exceeded, then the new session attempt is rejected and a Notification message is sent back to the remote peer.
The no form of the command removes the limit on the number of dynamic sessions.
no dynamic-neighbor-limit
This command enables the context to configure dynamic BGP sessions for a peer group.
This command configures a prefix from which to accept dynamic BGP sessions; particularly, sessions from source IP addresses not matching any configured neighbor addresses. A dynamic session is associated with the group having the longest match prefix entry for the source IP address of the peer. The group association determines local parameters that apply to the session, including the local AS, the local IP address, the peer AS, the import and export policies, and so on.
The no form of the command removes a prefix entry.
n/a
This command enables eiBGP load sharing so routes with both MP-BGP and IPv4 next-hops can be used simultaneously.
In order for this command to be effective, the ecmp and multipath commands for the associated VPRN instance must also be configured to allow for multiple routes to the same destination.
The no form of the command used at the global level reverts to default values.
no eibgp-loadbalance — multipath disabled
This command allows BGP-VPN routes imported into the VPRN to be used as backup paths for IPv4 and/or IPv6 BGP-learned prefixes.
When the egp-link-bandwidth command is configured, BGP automatically adds a link-bandwidth extended community to every route (of the selected types) received from directly connected (single-hop) EBGP peers within the scope of the command.
The link-bandwidth extended community added by this command encodes the local-AS number of receiving BGP instance and the bandwidth of the interface to the directly connected EBGP peer.
no egp-link-bandwidth
No link bandwidth extended community is automatically added to received BGP routes.
This command enables BGP peer tracking.
no enable-peer-tracking
This command enables or disables graceful-restart for all VPRN BGP peers.
When this command is present, the graceful restart capability sent by this router indicates support for NOTIFICATION messages. If the peer also supports this capability then the session can be restarted gracefully (while preserving forwarding) if either peer needs to sends a NOTIFICATION message due to some type of event or error.
no enable-notification
This command sets the value of the restart-time that is advertised in the router’s graceful-restart capability. If this command is not configured, the default is 300.
no restart time
This command configures the time period to keep stale routes before the END-OF-RIB message is received from the restarting router.
360 seconds
This command specifies whether the error handling mechanism for optional transitive path attributes is enabled for this peer group.
This command enables treat-as-withdraw and other similarly non-disruptive approaches for handling a wide range of UPDATE message errors, as long as there are no length errors that prevent all of the NLRI fields from being correctly identified and parsed.
no fault-tolerance
This command is used to specify route policies that control how outbound routes transmitted to certain peers are handled. Route policies are configured in the config>router>policy-options context.
This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in a peer-group) or neighbor level (only applies to the specified peer). The most specific level is used.
The export command can reference up to 15 objects, where each object is either a policy logical expression or the name of a single policy. The objects are evaluated in the specified order to determine the modifications of each route and the final action to accept or reject the route.
Only one of the 15 objects referenced by the export command can be a policy logical expression consisting of policy names (enclosed in square brackets) and logical operators (AND, OR, NOT). The first of the 15 objects has a maximum length of 255 characters while the remaining 14 objects have a maximum length of 64 characters each.
When multiple export commands are issued, the last command entered overrides the previous command.
When an export policy is not specified, BGP-learned routes are advertised by default; non-BGP routes are not advertised.
The no form of this command removes the policy association.
no export
This command configures the set of BGP address families (AFI plus SAFI) to be supported by the applicable VPRN BGP sessions.
The no form of the command restores the default, which corresponds to unlabeled IPv4 unicast routes (AFI 1, SAFI 1) only.
family ipv4
This command enables/disables validation of received flowspec routes. A flow route with a destination prefix subcomponent received from a particular peer is considered valid if and only if that peer also advertised the best unicast route to the destination prefix and any of its more-specific components. If validation is enabled and a flowspec route is not valid, it is not eligible for import into the RIB, it is not used for filtering, and it is not propagated to other flowspec peers.
The no form of the command disables the validation procedure.
no flowspec-validate
This command creates a context to configure a BGP peer group.
The no form of the command deletes the specified peer group and all configurations associated with the peer group. The group must be shutdown before it can be deleted.
n/a — No peer groups are defined.
This command creates a BGP peer/neighbor instance within the context of the BGP group.
This command can be issued repeatedly to create multiple peers and their associated configuration.
The no form of the command is used to remove the specified neighbor and the entire configuration associated with the neighbor. The neighbor must be administratively shutdown before attempting to delete it. If the neighbor is not shutdown, the command will not result in any action except a warning message on the console indicating that neighbor is still administratively up.
n/a — No neighbors are defined.
ipv4-address | a.b.c.d (host bits must be 0) |
ipv6-address | x:x:x:x:x:x:x:x[-interface] |
x:x:x:x:x:x:d.d.d.d[-interface] | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
interface: 32 characters maximum, mandatory for link local addresses |
This command specifies the address family or families to be supported over BGP peerings in the base router. This command is additive so issuing the family command adds the specified address family to the list.
The no form of the command removes the specified address family from the associated BGP peerings. If an address family is not specified, then reset the supported address family back to the default.
ipv4
This command configures the BGP hold time, expressed in seconds.
The BGP hold time specifies the maximum time BGP waits between successive messages (either keepalive or update) from its peer, before closing the connection. This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific value is used.
Even though the router OS implementation allows setting the keepalive time separately, the configured keepalive timer is overridden by the hold-time value under the following circumstances:
The no form of the command used at the global level reverts to the default value.
The no form of the command used at the group level reverts to the value defined at the global level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
90 seconds
This command defines the type of IBGP multipath to use when adding BGP routes to the route table if the route resolving the BGP nexthop offers multiple next-hops.
The no form of the command disables the IBGP multipath load balancing feature.
n/a
This command is used to specify route policies that control the handling of inbound routes received from certain peers. Route policies are configured in the config>router>policy-options context.
This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in a peer-group) or neighbor level (only applies to the specified peer). The most specific level is used
The import command can reference up to 15 objects, where each object is either a policy logical expression or the name of a single policy. The objects are evaluated in the specified order to determine the modifications of each route and the final action to accept or reject the route.
Only one of the 15 objects referenced by the import command can be a policy logical expression consisting of policy names (enclosed in square brackets) and logical operators (AND, OR, NOT). The first of the 15 objects has a maximum length of 255 characters while the remaining 14 objects have a maximum length of 64 characters each.
When multiple import commands are issued, the last command entered overrides the previous command.
When an import policy is not specified, BGP routes are accepted by default.
The no form of this command removes the policy association.
no import
This command configures the BGP keepalive timer. A keepalive message is sent every time this timer expires. The seconds parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in peer-group) or neighbor level (only applies to specified peer). The most specific value is used.
The keepalive value is generally one-third of the hold-time interval. Even though the OS implementation allows the keepalive value and the hold-time interval to be independently set, under the following circumstances, the configured keepalive value is overridden by the hold-time value:
If the specified keepalive value is greater than the configured hold-time, then the specified value is ignored, and the keepalive is set to one third of the current hold-time value.
If the specified hold-time interval is less than the configured keepalive value, then the keepalive value is reset to one third of the specified hold-time interval.
If the hold-time interval is set to zero, then the configured value of the keepalive value is ignored. This means that the connection with the peer is up permanently and no keepalive packets are sent to the peer.
The no form of the command used at the global level reverts to the default value.
The no form of the command used at the group level reverts to the value defined at the global level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
30 seconds
This command configures the route preference for routes learned from labeled-unicast peers.
This command can be configured at three levels:
The most specific value is used.
The lower the preference, the higher the chance of the route being the active route.
The no form of the command used at the global level reverts to the default value of 170.
The no form of the command used at the group level reverts to the value defined at the global level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
no label-preference
Configures the local IP address used by the group or neighbor when communicating with BGP peers.
Outgoing connections use the local-address as the source of the TCP connection when initiating connections with a peer.
When a local address is not specified, the OS uses the system IP address when communicating with IBGP peers and uses the interface address for directly connected EBGP peers. This command is used at the neighbor level to revert to the value defined under the group level.
The no form of the command removes the configured local-address for BGP.
The no form of the command used at the group level reverts to the value defined at the global level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
This command configures a BGP virtual autonomous system (AS) number.
In addition to the global AS number configured for BGP in the config>router>autonomous-system context, a virtual (local) AS number can be configured to support various AS number migration scenarios.The local AS number is added to the to the beginning the as-path attribute ahead of the router’s AS number.
This configuration parameter can be set at three levels: global level (applies to all EBGP peers), group level (applies to all EBGP peers in peer-group) or neighbor level (only applies to EBGP specified peer). Thus, by specifying this at each neighbor level, it is possible to have a separate local-as per EBGP session. The local-as command is not supported for IBGP sessions. When the optional private keyword is specified in the command the local-as number is not added to inbound routes from the EBGP peer that has local-as in effect.
When a command is entered multiple times for the same AS, the last command entered is used in the configuration. The private attribute can be added or removed dynamically by reissuing the command.
Changing the local AS at the global level in an active BGP instance causes the BGP instance to restart with the new local AS number. Changing the local AS at the global level in an active BGP instance causes BGP to re-establish the peer relationships with all peers in the group with the new local AS number. Changing the local AS at the neighbor level in an active BGP instance causes BGP to re-establish the peer relationship with the new local AS number.
This is an optional command and can be used in the following circumstance:
Provider router P is moved from AS1 to AS2. The customer router that is connected to P, however, is configured to belong to AS1. To avoid reconfiguring the customer router, the local-as value on router P can be set to AS1. Thus, router P adds AS1 to the as-path message for routes it advertises to the customer router.
The no form of the command used at the global level will remove any virtual AS number configured.
The no form of the command used at the group level reverts to the value defined at the global level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
no local-as
This command enables setting the BGP local-preference attribute in incoming routes if not specified and configures the default value for the attribute. This value is used if the BGP route arrives from a BGP peer without the local-preference integer set.
The specified value can be overridden by any value set via a route policy. This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in peer-group) or neighbor level (only applies to specified peer). The most specific value is used.
The no form of the command at the global level specifies that incoming routes with local-preference set are not overridden and routes arriving without local-preference set are interpreted as if the route had local-preference value of 100.
The no form of the command used at the group level reverts to the value defined at the global level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
no local-preference - Does not override the local-preference value set in arriving routes and analyze routes without local preference with value of 100.
This command configures how the BGP peer session handles loop detection in the AS path.
This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in peer-group) or neighbor level (only applies to specified peer). The most specific value is used.
Dynamic configuration changes of loop-detect are not recognized.
The no form of the command used at the global level reverts to default, which is loop-detect ignore-loop.
The no form of the command used at the group level reverts to the value defined at the global level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
loop-detect ignore-loop
This command enables advertising the Multi-Exit Discriminator (MED) and assigns the value used for the path attribute for the MED advertised to BGP peers if the MED is not already set.
The specified value can be overridden by any value set via a route policy.
This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in peer-group) or neighbor level (only applies to specified peer). The most specific value is used.
The no form of the command used at the global level reverts to default where the MED is not advertised.
The no form of the command used at the group level reverts to the value defined at the global level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
no med-out
This command configures the minimum interval, in seconds, at which a prefix can be advertised to a peer.
This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in peer-group) or neighbor level (only applies to specified peer). The most specific value is used.
The no form of the command reverts to default values.
30 seconds
This command configures the time to live (TTL) value entered in the IP header of packets sent to an EBGP peer multiple hops away.
This parameter is meaningful only when configuring EBGP peers. It is ignored if set for an IBGP peer.
The no form of the command is used to convey to the BGP instance that the EBGP peers are directly connected.
The no form of the command reverts to default values.
1 — EBGP peers are directly connected
64 — IBGP
This command enables BGP multipath for the IPv4 and IPv6 address families.
When multipath is enabled, traffic to the destination is load-shared across a set of paths (BGP routes) that the BGP decision process considers 'equal' to the best path. The actual distribution of traffic over the multiple paths may be equal or unequal (that is, based on weights derived from the Link Bandwidth extended community).
To qualify as a multipath, a non-best route must meet the following criteria (some criteria are controlled by this command):
The no form of the command disables BGP multipath (equivalent to multipath 1).
no multipath
This command enables the context to configure next-hop resolution parameters.
This command configures the group or neighbor to always set the NEXTHOP path attribute to its own physical interface when advertising to a peer.
This is primarily used to avoid third-party route advertisements when connected to a multi-access network.
The no form of the command used at the group level allows third-party route advertisements in a multi-access network.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
This command enables passive mode for the BGP group or neighbor.
When in passive mode, BGP will not attempt to actively connect to the configured BGP peers but responds only when it receives a connect open request from the peer.
The no form of the command used at the group level disables passive mode where BGP actively attempts to connect to its peers.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
This command configures the autonomous system number for the remote peer. The peer AS number must be configured for each configured peer.
For EBGP peers, the peer AS number configured must be different from the autonomous system number configured for this router under the global level since the peer will be in a different autonomous system than this router
For IBGP peers, the peer AS number must be the same as the autonomous system number of this router configured under the global level.
This is a required command for each configured peer. This may be configured under the group level for all neighbors in a particular group.
No AS numbers are defined.
This command specifies the name of a policy statement to use with the BGP next-hop resolution process. The policy controls which IP routes in RTM are eligible to resolve the BGP next-hop addresses of IPv4 and IPv6 routes. The policy has no effect on the resolution of BGP next-hops to MPLS tunnels. If a BGP next-hop of an IPv4 or IPv6 route R is resolved in RTM and the longest matching route for the next-hop address is an IP route N that is rejected by the policy then route R is unresolved; if the route N is accepted by the policy then it becomes the resolving route for R.
The default next-hop resolution policy (when the no policy command is configured) is to use the longest matching active route in RTM that is not a BGP route (unless use-bgp-routes is configured), an aggregate route or a subscriber management route.
no policy
This command specifies the name of a policy statement to use with the BGP peer-tracking function on the BGP sessions where this is enabled. The policy controls which IP routes in RTM are eligible to indicate reachability of IPv4 and IPv6 BGP neighbor addresses. If the longest matching route in RTM for a BGP neighbor address is an IP route that is rejected by the policy, or it is a BGP route accepted by the policy, or if there is no matching route, the neighbor is considered unreachable and BGP tears down the peering session and holds it in the idle state until a valid route is once again available and accepted by the policy.
The default peer-tracking policy (when the no peer-tracking-policy command is configured) is to use the longest matching active route in RTM that is not an LDP shortcut route or an aggregate route.
no peer-tracking-policy
This command configures the route preference for routes learned from the configured peer(s).
This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in peer-group) or neighbor level (only applies to specified peer). The most specific value is used.
The lower the preference the higher the chance of the route being the active route. The OS assigns BGP routes highest default preference compared to routes that are direct, static or learned via MPLS or OSPF.
The no form of the command used at the global level reverts to default value.
The no form of the command used at the group level reverts to the value defined at the global level.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
170
This command configures the maximum number of BGP routes that can be received from a peer before administrative action is taken. The administrative action can be the generation of a log event or taking down the session. If a session is taken down, then it can be brought back up automatically after an idle-timeout period, or else it can be configured to stay down ('forever') until the operator performs a reset.
The prefix-limit command allows each address family to have its own limit; a set of address family limits can be applied to one neighbor or to all neighbors in a group.
The no form of the command removes the prefix-limit.
No prefix limits for any address family.
This command disables the delay (Minimum Route Advertisement) on sending BGP withdrawals. Normal route withdrawals may be delayed up to the minimum route advertisement to allow for efficient packing of BGP updates.
The no form of the command removes this command from the configuration and returns withdrawal processing to the normal behavior.
no rapid-withdrawal
This command allows private AS numbers to be removed from the AS path before advertising them to BGP peers.
When the remove-private parameter is set at the global level, it applies to all peers regardless of group or neighbor configuration. When the parameter is set at the group level, it applies to all peers in the group regardless of the neighbor configuration.
The OS software recognizes the set of AS numbers that are defined by IANA as private. These are AS numbers in the range 64512 through 65535, inclusive.
The no form of the command used at the global level reverts to default value. The no form of the command used at the group level reverts to the value defined at the global level. The no form of the command used at the neighbor level reverts to the value defined at the group level.
no remove-private - Private AS numbers will be included in the AS path attribute.
This command enables the context to configure RIB management parameters.
N/A
This command is used to specify route policies that control the importation of leak-eligible routes from the BGP RIB of another routing instance into the unlabeled-IPv4, unlabeled-IPv6, or labeled-IPv4 RIB of the base router. To leak a route from one routing instance to another, the origin and destination RIB types must be the same; for example, it is not possible to leak a route from an unlabeled-IPv4 RIB of a VPRN into the labeled-IPv4 RIB of the base router.
The leak-import command can reference up to 15 objects, where each object is either a policy logical expression or the name of a single policy. The objects are evaluated in the specified order to determine final action to accept or reject the route.
Only one of the 15 objects referenced by the leak-import command is allowed to be a policy logical expression consisting of policy names (enclosed in square brackets) and logical operators (AND, OR, NOT). The first of the 15 objects has a maximum length of 255 characters while the remaining 14 objects have a maximum length of 64 characters each.
When multiple leak-import commands are issued, the last command entered overrides the previous command.
When a leak-import policy is not specified, no BGP routes from other routing instances are leaked into the VPRN BGP RIB.
The no form of the command removes the policy association.
n/a
This command specifies the name of a route policy to control the importation of active routes from the IP route table into one of the BGP RIBs.
If the route-table-import command is not configured, or if the command refers to an empty policy, all non-BGP routes from the IP route table are imported into the applicable RIB.
If the route-table-import command is configured, then routes dropped or rejected by the configured policy are not installed in the associated RIB. Rejected routes cannot be advertised to BGP peers associated with the RIB, but they can still be used to resolve BGP next-hops of routes in that RIB. If the active route for a prefix is rejected by the route-table-import policy, then the best BGP route for that prefix in the BGP RIB can be advertised to peers as though it is used.
Aggregate routes are always imported into each RIB, independent of the route-table-import policy.
Route modifications specified in the actions of a route-table-import policy are ignored and have no effect on the imported routes.
no route-table-import
This command enables the use of split-horizon. When applied globally, to a group, or a specific peer, split-horizon prevents routes from being reflected back to a peer that sends the best route. It applies to routes of all address families and to any type of sending peer; confed-EBGP, EBGP and IBGP.
The configuration default is no split-horizon, meaning that no effort is taken to prevent a best route from being reflected back to the sending peer.
Caution: Use of the split-horizon command may have a detrimental impact on peer and route scaling and therefore operators are encouraged to use it only when absolutely needed. |
The no form of the command disables split horizon command which allows the lower level to inherit the setting from an upper level.
no split-horizon
Use this command to enable the router to send third-party next-hop to EBGP peers in the same subnet as the source peer, as described in RFC 4271. If enabled when an IPv4 or IPv6 route is received from one EBGP peer and advertised to another EBGP peer in the same IP subnet, the BGP next-hop is left unchanged. Third-party next-hop is not done if the address family of the transport does not match the address family of the route.
The no form of the command prevents BGP from performing any third party next-hop processing toward any single-hop EBGP peers within the scope of the command. No third-party next-hop means the next-hop will always carry the IP address of the interface used to establish the TCP connection to the peer.
no third-party-nexthop
This command designates the BGP peer as type internal or external.
The type of internal indicates the peer is an IBGP peer while the type of external indicates that the peer is an EBGP peer.
By default, the OS derives the type of neighbor based on the local AS specified. If the local AS specified is the same as the AS of the router, the peer is considered internal. If the local AS is different, then the peer is considered external.
The no form of the command used at the group level reverts to the default value.
The no form of the command used at the neighbor level reverts to the value defined at the group level.
no type
This command controls whether SR OS utilizes the new neighbor-complete bit when processing optional transitive path attributes and advertising them to the associated BGP neighbor.
This command also control if SR OS utilizes the error handling mechanism for optional-transitive path attributes.
no updated-error-handling
Configure TTL security parameters for incoming packets.
This command enables the context to configure ETH-CFM parameters.
This command enables the collection of statistics on the SAP or MPLS SDP binding on which the ETH- LMM test is configured. The collection of LMM statistics must be enabled if a MEP is launching or responding to ETH-LMM packets. If LMM statistics collection is not enabled, the counters in the LMM and LMR PDU do not represent accurate measurements and all measurements should be ignored. The show sap-using eth-cfm collect-lmm-stats command and the show sdp-using eth-cfm collect-lmm-stats command can be used to display which entities are collecting stats.
The no form of the command disables and deletes the counters for this SAP or MPLS SDP binding.
no collect-lmm-stats
This command configures the ETH-CFM maintenance endpoint (MEP).
This command configures the reception of Alarm Indication Signal (AIS) message.
This command enables the AIS function to consider the operational state of the entity on which it is configured. With this command, ETH-AIS on DOWN MEPs will be triggered and cleared based on the operational status of the entity on which it is configured. If CCM is also enabled then transmission of the AIS PDU will be based on either the non operational state of the entity or on ANY CCM defect condition. AIS generation will cease if BOTH operational state is UP and CCM has no defect conditions. If the MEP is not CCM enabled then the operational state of the entity is the only consideration assuming this command is present for the MEP.
no interface-support-enabled (AIS will not be generated or stopped based on the state of the entity on) which the DOWN MEP is configured.
This command enables the generation of CCM messages.
The no form of the command disables the generation of CCM messages.
This command specifies the priority value for CCMs and LTMs transmitted by the MEP.
The no form of the command removes the priority value from the configuration.
The highest priority on the bridge-port.
This command sets the byte size of the optional Data TLV to be included in the ETH-CC PDU. This will increase the size of the ETH-CC PDU by the configured value. The base size of the ETH-CC PDU, including the Interface Status TLV and Port Status TLV, is 83 bytes not including the Layer Two encapsulation. CCM padding is not supported when the CCM-Interval is less than one second.
ccm-padding-size
This command enables the reception and local processing of ETH-CSF frames.
This command enables the multiplication factor applied to the receive time used to clear the CSF condition in increments of 5.
3.5
This command enables eth-test functionality on MEP. For this test to work, operators need to configure ETH-test parameters on both sender and receiver nodes. The ETH-test then can be done using the following OAM commands:
oam eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]
A check is done for both the provisioning and test to ensure the MEP is an Y.1731 MEP (MEP provisioned with domain format none, association format icc-based). If not, the operation fails. An error message in the CLI and SNMP will indicate the problem.
This command configures the test pattern for eth-test frames.
The no form of the command removes the values from the configuration.
all-zeros
This command specifies the lowest priority defect that is allowed to generate a fault alarm.
1
This command enables one way delay threshold time limit.
3 seconds
This command defines the levels of the ETH-CFM PDUs that will silently be discarded on ingress into the SAP or SDP Binding from the wire. All ETH-CFM PDUs inbound to the SAP or SDP binding will be dropped that match the configured levels without regard for any other ETH-CFM criteria. No statistical information or drop count will be available for any ETH-PDU that is silently discarded by this option. The operator must configure a complete contiguous list of md-levels up to the highest level that will be dropped. The command must be retyped in complete form to modify a previous configuration, if the operator does not want to delete it first.
The no form of the command removes the silent discarding of previously matching ETH-CFM PDUs.
no squelch-ingress-levels
Allows the individual service SAPs to react to changes in the tunnel MEP state. When tunnel-fault accept is configured at the service level, the SAP will react according to the service type, Epipe will set the operational flag and VPLS, IES and VPRN SAP operational state will become down on failure or up on clear. This command triggers the OAM mapping functions to mate SAPs and bindings in an Epipe service as well as setting the operational flag. If AIS generation is the requirement for the Epipe services this command is not required. See the command ais-enable under epipe>sap>eth-cfm>ais-enable for more details. This works in conjunction with the tunnel-fault accept on the individual SAPs. Both must be set to accept to react to the tunnel MEP state. By default the service level command is “ignore” and the sap level command is “accept”. This means simply changing the service level command to “accept” will enable the feature for all SAPs. This is not required for Epipe services that only wish to generate AIS on failure.
ignore (Service Level)
accept (SAP Level for Epipe and VPLS)
This command configures the fault propagation for the MEP.
This command specifies the lowest priority defect that is allowed to generate a fault alarm.
macRemErrXcon
allDef | DefRDICCM, DefMACstatus, DefRemoteCCM, DefErrorCCM, and DefXconCCM |
macRemErrXcon | Only DefMACstatus, DefRemoteCCM, DefErrorCCM, and DefXconCCM |
remErrXcon | Only DefRemoteCCM, DefErrorCCM, and DefXconCCM |
errXcon | Only DefErrorCCM and DefXconCCM |
xcon | Only DefXconCCM; or |
noXcon | No defects DefXcon or lower are to be reported |
This command enables the ISIS protocol instance with the VPRN service.
The no form of the command disables the ISIS protocol instance from the given VPRN service.
no ISIS
This command enables and disables IS-IS for the VPRN instance to advertise only prefixes that belong to passive interfaces.
This command enables advertisement of a router's capabilities to its neighbors for informational and troubleshooting purposes. A new TLV as defined in RFC 4971 advertises the TE Node Capability Descriptor capability.
The parameters (area & as) control the scope of the capabilities advertisements.
The no form of this command, disables this capability.
no advertise-router-capability
This command specifies the MAC address to use for the VPRN instance of the L1 IS-IS routers. The MAC address should be a multicast address. You should shut/no shut the IS-IS instance to make the change operational.
all-l1isis 01-80-C2-00-01-00
This command specifies the MAC address to use for L2 IS-IS routers for the VPRN instance. The MAC address should be a multicast address. You should shut/no shut the IS-IS instance to make the change operational.
all-l2isis 01-80-C2-00-02-11
This command configures the area ID portion of NSAP addresses for the VPRN instance. This identifies a point of connection to the network, such as a router interface, and is called a Network Service Access Point (NSAP). Addresses in the IS-IS protocol are based on the ISO NSAP addresses and Network Entity Titles (NETs), not IP addresses.
A maximum of 3 area addresses can be configured for the VPRN instance.
NSAP addresses are divided into three parts. Only the area ID portion is configurable.
The NET is constructed like an NSAP but the selector byte contains a 00 value. NET addresses are exchanged in hello and LSP PDUs. All net addresses configured on the node are advertised to its neighbors.
For Level 1 interfaces, neighbors can have different area IDs, but, they must have at least one area ID (AFI + area) in common. Sharing a common area ID, they become neighbors and area merging between the potentially different areas can occur.
For Level 2 (only) interfaces, neighbors can have different area IDs. However, if they have no area IDs in common, they become only Level 2 neighbors and Level 2 LSPs are exchanged.
For Level 1 and Level 2 interfaces, neighbors can have different area IDs. If they have at least one area ID (AFI + area) in common, they become neighbors. In addition to exchanging Level 2 LSPs, area merging between potentially different areas can occur.
If multiple area-id commands are entered, the system ID of all subsequent entries must match the first area address.
The no form of the command removes the area address.
This command configures an authentication keychain to use for the protocol interface for the VPRN instance. The keychain allows the rollover of authentication keys during the lifetime of a session.
no auth-keychain
This command sets an authentication check to reject PDUs that do not match the type or key requirements for the VPRN instance.
The default behavior when authentication is configured is to reject all IS-IS protocol PDUs that have a mismatch in either the authentication type or authentication key.
When no authentication-check is configured, authentication PDUs are generated and IS-IS PDUs are authenticated on receipt. However, mismatches cause an event to be generated and will not be rejected.
The no form of this command allows authentication mismatches to be accepted and generate a log event.
authentication-check — rejects authentication mismatches
This command sets the authentication key used to verify PDUs sent by neighboring routers on the interface for the VPRN instance.
Neighboring routers use passwords to authenticate PDUs sent from an interface. For authentication to work, both the authentication key and the authentication type on a segment must match. The OSPF Commands statement must also be included.
To configure authentication on the global level, configure this command in the config>router>isis context. When this parameter is configured on the global level, all PDUs are authenticated including the hello PDU.
To override the global setting for a specific level, configure the authentication-key command in the config>router>isis>level context. When configured within the specific level, hello PDUs are not authenticated.
The no form of the command removes the authentication key.
no authentication-key — No authentication key is configured.
This is useful when a user must configure the parameter, but, for security purposes, the actual unencrypted key value is not provided.
This command enables either simple password or message digest authentication or must go in either the global IS-IS or IS-IS level context.
Both the authentication key and the authentication type on a segment must match. The authentication-key statement must also be included.
Configure the authentication type on the global level in the config>router>isis context.
Configure or override the global setting by configuring the authentication type in the config>router>isis>level context.
The no form of the command disables authentication.
no authentication-type — No authentication type is configured and authentication is disabled.
This command enables authentication of individual ISIS packets of complete sequence number PDUs (CSNP) type for the VPRN instance.
This command configures the route tag for default route for the router or VPRN service.
This command configures export routing policies that determine the routes exported from the routing table to IS-IS.
If no export policy is defined, non IS-IS routes are not exported from the routing table manager to IS-IS.
If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple export commands are issued, the last command entered overrides the previous command. A maximum of five policy names can be specified.
If an aggregate command is also configured in the config>router context, then the aggregation is applied before the export policy is applied.
Routing policies are created in the config>router>policy-options context.
The no form of the command removes the specified policy-name or all policies from the configuration if no policy-name is specified.
no export — No export policy name is specified.
This command configures the maximum number of routes (prefixes) that can be exported into IS-IS from the route table for the VPRN instance.
The no form of the command removes the parameters from the configuration.
no export-limit - The export limit for routes or prefixes is disabled.
This command enables IS-IS graceful restart (GR) to minimize service interruption. When the control plane of a GR-capable router fails or restarts, the neighboring routers (GR helpers) temporarily preserve IS-IS forwarding information. Traffic continues to be forwarded to the restarting router using the last known forwarding tables. If the control plane of the restarting router becomes operationally and administratively up within the grace period, the restarting router resumes normal IS-IS operation. If the grace period expires, then the restarting router is presumed inactive and the IS-IS topology is recalculated to route traffic around the failure.
The no form of the command disables graceful restart and removes the graceful restart configuration from the IS-IS instance.
no graceful-restart
This command disables helper support for IS-IS graceful restart (GR).
When graceful-restart is enabled, the router can be a helper (meaning that the router is helping a neighbor to restart), a restarting router, or both. The router only supports helper mode. It will not act as a restarting router, because the high availability feature set already preserves IS-IS forwarding information such that this functionality is not needed. This command is a historical command and should not be disabled. Configuring helper-disable has the effect of disabling graceful restart, because the router only supports helper mode.
The no helper-disable command enables helper support and is the default when graceful restart is enabled.
no helper-disable
This command enables authentication of individual IS-IS Hello packets for the VPRN instance.
The no form of the command suppresses authentication of Hello packets.
This command enables the IS-IS Hello (IIH) message padding to ensure that IS-IS LSPs can traverse the link. When this option is enabled, IS-IS Hello messages are padded to the maximum LSP MTU value, which can be set with the lsp-mtu-size command.
The no form of the command disables IS-IS Hello message padding.
no hello-padding — Hello message padding is not configured
This command specifies that for this VPRN instance, ISIS will ignore LSP packets with errors. When enabled, IS-IS LSP errors will be ignored and the associated record will not be purged.
This command enables ISIS to ignore the ATT bit and therefore suppress the installation of default routes.
The no form of the command specifies that ISIS will not ignore LSP errors.
This command enables IS-IS multi-instance (MI) as described in draft-ietf-isis-mi-02. Multiple instances allow instance-specific adjacencies to be formed that support multiple network topologies on the same physical interfaces. Each instance has an LSDB, and each PDU contains a TLV identifying the instance and the topology to which the PDU belongs.
The iid-tlv-enable (based on draft-ietf-isis-mi-02) and standard-multi-instance (based on draft-ginsberg-isis-mi-bis-01) commands cannot be configured in the same instance, because the MAC addresses and PDUs in each standard are incompatible.
no iid-tlv-enable
This command creates the context to configure an IS-IS interface.
When an area is defined, the interfaces belong to that area. Interfaces cannot belong to separate areas.
When the interface is a POS channel, the OSINCP is enabled when the interface is created and removed when the interface is deleted.
The no form of the command removes IS-IS from the interface.
The shutdown command in the config>router>isis>interface context administratively disables IS-IS on the interface without affecting the IS-IS configuration.
no interface — No IS-IS interfaces are defined.
This command enables the use of bi-directional forwarding (BFD) to control IPv4 adjacencies. By enabling BFD on an IPv4 or IPv6 protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set by the BFD command under the IP interface. This command must be given separately to enable/disable BFD for both IPv4 and IPv6.
The no form of this command removes BFD from the associated adjacency.
no bfd-enable ipv4
This command configures the time interval, in seconds, to send complete sequence number (CSN) PDUs from the interface. IS-IS must send CSN PDUs periodically.
The no form of the command reverts to the default value.
csnp-interval 10 — CSN PDUs are sent every 10 seconds for LAN interfaces.
csnp-interval 5 — CSN PDUs are sent every 5 seconds for point-to-point interfaces.
1 to 65535
This command enables a non-MI capable router to establish an adjacency and operate with an SR OS in a non-zero instance. If the router does not receive IID-TLVs, it will establish an adjacency in a single instance. Instead of establishing an adjacency in the standard instance 0, the router will establish an adjacency in the configured non-zero instance. The router will then operate in the configured non-zero instance so that it appears to be in the standard instance 0 to its neighbor. This feature is supported on point-to-point interfaces, broadcast interfaces are not supported.
The no form of the command disables the functionality so that the router can only establish adjacencies in the standard instance 0.
no default-instance
This command configures an authentication keychain to use for the protocol interface. The keychain allows the rollover of authentication keys during the lifetime of a session.
no hello-auth-keychain
This command configures the authentication key (password) for hello PDUs. Neighboring routers use the password to verify the authenticity of hello PDUs sent from this interface. Both the hello authentication key and the hello authentication type on a segment must match. The hello-authentication-type must be specified.
To configure the hello authentication key in the interface context use the hello-authentication-key in the config>router>isis>interface context.
To configure or override the hello authentication key for a specific level, configure the hello-authentication-key in the config>router>isis>interface>level context.
If both IS-IS and hello-authentication are configured, Hello messages are validated using hello authentication. If only IS-IS authentication is configured, it will be used to authenticate all IS-IS (including hello) protocol PDUs.
When the hello authentication key is configured in the config>router>isis>interface context, it applies to all levels configured for the interface.
The no form of the command removes the authentication-key from the configuration.
no hello-authentication-key — No hello authentication key is configured.
This is useful when a user must configure the parameter, but, for security purposes, the actual unencrypted key value is not provided.
This command enables hello authentication at either the interface or level context. Both the hello authentication key and the hello authentication type on a segment must match. The hello authentication-key statement must also be included.
To configure the hello authentication type at the interface context, use hello-authentication-type in the config>router>isis>interface context.
To configure or override the hello authentication setting for a given level, configure the hello-authentication-type in the config>router>isis>interface>level context.
The no form of the command disables hello authentication.
no hello-authentication-type — hello authentication is disabled
This command configures the IS-IS interface type as either broadcast or point-to-point.
Use this command to set the interface type of an Ethernet link to point-to-point to avoid having to carry the designated IS-IS overhead if the link is used as a point-to-point.
If the interface type is not known at the time the interface is added to IS-IS and subsequently the IP interface is bound (or moved) to a different interface type, then this command must be entered manually.
The no form of the command reverts to the default value.
point-to-point — For IP interfaces on SONET channels.
broadcast — For IP interfaces on Ethernet or unknown type physical interfaces.
This command administratively disables/enables ISIS operation for IPv4.
no ipv4-multicast-disable
This command disables IS-IS IPv6 unicast routing for the interface.
By default IPv6 unicast on all interfaces is enabled. However, IPv6 unicast routing on IS-IS is in effect when the config>router>isis>ipv6-routing mt command is configured.
The no form of the command enables IS-IS IPv6 unicast routing for the interface.
This command configures the interval in seconds between Hello messages issued on this interface at this level.
The no form of the command to reverts to the default value.
3 — Hello interval default for the designated intersystem
9 — Hello interval default for non-designated intersystems
This command configures the number of missing hello PDUs from a neighbor after the router declares the adjacency down.
The no form of the command reverts to the default value.
3 — The router can miss up to 3 Hello messages before declaring the adjacency down.
This command configures IS-IS interface metric for IPv4 multicast for the VPRN instance.
The no form of this command removes the metric from the configuration.
This command configures IS-IS interface metric for IPv6 unicast.
The no form of this command removes the metric from the configuration.
This command configures the metric used for the level on the interface.
In order to calculate the lowest cost to reach a given destination, each configured level on each interface must have a cost. The costs for each level on an interface may be different.
If the metric is not configured, the default of 10 is used unless reference bandwidth is configured.
The no form of the command reverts to the default value.
10 — A metric of 10 for the level on the interface is used.
This command adds the passive attribute which causes the interface to be advertised as an IS-IS interface without running the IS-IS protocol. Normally, only interface addresses that are configured for IS-IS are advertised as IS-IS interfaces at the level that they are configured.
When the passive mode is enabled, the interface or the interface at the level ignores ingress IS-IS protocol PDUs and will not transmit IS-IS protocol PDUs.
The no form of the command removes the passive attribute.
passive — Service interfaces are passive. no passive — All other interfaces are not passive.
This command configures the priority of the IS-IS router interface for designated router election on a multi-access network.
This priority is included in hello PDUs transmitted by the interface on a multi-access network. The router with the highest priority is the preferred designated router. The designated router is responsible for sending LSPs with regard to this network and the routers that are attached to it.
The no form of the command reverts to the default value.
64
If the pre-FEC error rate of the associated DWDM port crosses the configured sd-threshold, this offset-value is added to the IS-IS interface metric. This parameter is only effective if the interface is associated with a DWDM port and the sd-threshold value is configured under that port.
The no form of the command reverts the offset value to 0.
no sd-offset
If the pre-FEC error rate of the associated DWDM port crosses the configured sf-threshold, this offset-value is added to the IS-IS interface metric. This parameter is only effective if the interface is associated with a DWDM port and the sf-threshold value is configured under that port.
The no form of the command reverts the offset value to 0.
no sf-offset
This command applies a route next-hop policy template to the IS-IS interface for the VPRN instance.
When a route next-hop policy template is applied to an interface in IS-IS, it is applied in both level 1 and level 2. When a route next-hop policy template is applied to an interface in OSPF, it is applied in all areas. However, the command in an OSPF interface context can only be executed under the area in which the specified interface is primary and then applied in that area and in all other areas where the interface is secondary. If the user attempts to apply it to an area where the interface is secondary, the command will fail.
If the user excluded the interface from LFA using the command loopfree-alternate-exclude, the LFA policy, if applied to the interface, has no effect.
Finally, if the user applied a route next-hop policy template to a loopback interface or to the system interface, the command will not be rejected, but it will result in no action being taken.
The no form deletes the mapping of a route next-hop policy template to an OSPF or IS-IS interface.
This command instructs IGP to not include a specific interface or all interfaces participating in a specific IS-IS level or OSPF area in the SPF LFA computation. This provides a way of reducing the LFA SPF calculation where it is not needed.
When an interface is excluded from the LFA SPF in IS-IS, it is excluded in both level 1 and level 2. When it is excluded from the LFA SPF in OSPF, it is excluded in all areas. However, the above OSPF command can only be executed under the area in which the specified interface is primary and once enabled, the interface is excluded in that area and in all other areas where the interface is secondary. If the user attempts to apply it to an area where the interface is secondary, the command will fail.
The no form of this command re-instates the default value for this command.
no loopfree-alternate-exclude
This command configures the weighted ECMP load-balancing weight for an IS-IS interface of the VPRN. If the interface becomes an ECMP next-hop for IPv4 or IPv6 route and all the other ECMP next-hops are interfaces with configured (non-zero) load-balancing weights, then the traffic distribution over the ECMP interfaces is proportional to the weights. In other words, the interface with the largest load-balancing-weight should receive the most forwarded traffic if weighted ECMP is applicable.
The no form of this command disables weighted ECMP for the interface and, therefore, effectively disables weighted ECMP for any IP prefix that has this interface as a next-hop.
no load-balancing-weight
This command configures the interval during which LSPs are sent from the interface.To avoid overwhelming neighbors that have less CPU processing power with LSPs, the pacing interval can be configured to limit how many LSPs are sent during an interval. LSPs may be sent in bursts during the interval up to the configured limit. If a value of 0 is configured, no LSPs are sent from the interface.
The no form of the command reverts to the default value.
100 — LSPs are sent in 100 millisecond intervals.
This command assigns an interface to a mesh group. Mesh groups limit the amount of flooding that occurs when a new or changed LSP is advertised throughout an area.
All routers in a mesh group should be fully meshed. When LSPs need to be flooded, only a single copy is received rather than a copy per neighbor.
To create a mesh group, configure the same mesh group value for each interface that is part of the mesh group. All routers must have the same mesh group value configured for all interfaces that are part of the mesh group.
To prevent an interface from flooding LSPs, the optional blocked parameter can be specified. Configure mesh groups carefully. It is easy to created isolated islands that do not receive updates as (other) links fail.
The no form of the command removes the interface from the mesh group.
no mesh-group — the interface does not belong to a mesh group
This command configures the minimum time between LSP PDU retransmissions on a point-to-point interface.
The no form of the command reverts to the default value.
100
1 to 65535
This command configures a route tag to the specified IP address of an interface.
The multicast RTM is used for Reverse Path Forwarding checks. This command controls which IS-IS topology is used to populate the IPv4 multicast RTM.
The no ipv4-multicast-routing form of the command results in none of the IS-IS routes being populated in the IPv4 multicast RTM and would be used if multicast is configured to use the unicast RTM for the RPF check.
ipv4-multicast-routing native
This command specifies whether this IS-IS instance supports IPv4.
The no form of the command disables IPv4 on the IS-IS instance.
ipv4-routing
This command enables IPv6 routing.
The no form of the command disables support for IS-IS IPv6 TLVs for IPv6 routing.
disabled
This command creates the context to configure IS-IS Level 1 or Level 2 area attributes.
A router can be configured as a Level 1, Level 2, or Level 1-2 system. A Level 1 adjacency can be established if there is at least one area address shared by this router and a neighbor. A Level 2 adjacency cannot be established over this interface.
Level 1/2 adjacency is created if the neighbor is also configured as Level 1/2 router and has at least one area address in common. A Level 2 adjacency is established if there are no common area IDs.
A Level 2 adjacency is established if another router is configured as Level 2 or a Level 1/2 router with interfaces configured as Level 1/2 or Level 2. Level 1 adjacencies will not established over this interface.
To reset global and/or interface level parameters to the default, the following commands must be entered independently:
level> no hello-authentication-key level> no hello-authentication-type level> no hello-interval level> no hello-multiplier level> no metric level> no passive level> no priority
level 1 or level 2
By default an interface operates in both Level 1 and Level 2 modes.
This command configures the default metric to be used for the IS-IS interface in the IPv4 multicast topology (MT3).
The no form of this command deletes the specified default metric and reverts to using the system default of 10.
10
This command configures the default metric to be used for the IS-IS interface in the IPv6 multicast topology (MT4).
The no form of this command deletes the specified default metric and reverts to using the system default of 10.
10
1 to 16777215
This command specifies the default metric for IPv6 unicast.
no default-ipv6-unicast-metric
This command specifies the configurable default metric used for all IS-IS interfaces on this level. This value is not used if a metric is configured for an interface.
10
This command configures the external route preference for the IS-IS level.
The external-preference command configures the preference level of either IS-IS level 1 or IS-IS level 2 external routes. By default, the preferences are as listed in the table below.
A route can be learned by the router by different protocols, in which case, the costs are not comparable. When this occurs, the preference decides the route to use.
Different protocols should not be configured with the same preference, if this occurs the tiebreaker is dependent on the default preference table. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used. If multiple routes are learned with an identical preference using the same protocol and the costs (metrics) are equal, then the decision of the route to use is determined by the configuration of the ecmp in the config>router context.
Default preferences are listed in Table 44.
Route Type | Preference | Configurable |
Direct attached | 0 | No |
Static route | 5 | Yes |
MPLS | 7 | — |
OSPF internal routes | 10 | No |
IS-IS Level 1 internal | 15 | Yes 1 |
IS-IS Level 2 internal | 18 | Yes 1 |
OSPF external | 150 | Yes |
IS-IS Level 1 external | 160 | Yes |
IS-IS Level 2 external | 165 | Yes |
TMS | 167 | No |
BGP | 170 | Yes |
BGP | 170 | Yes |
Note:
This command configures the preference level of either IS-IS Level 1 or IS-IS Level 2 internal routes. By default, the preferences are listed in the table below.
A route can be learned by the router by different protocols, in which case, the costs are not comparable. When this occurs, the preference is used to decide to which route will be used.
Different protocols should not be configured with the same preference, if this occurs the tiebreaker is per the default preference table as defined in the table below. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used. If multiple routes are learned with an identical preference using the same protocol and the costs (metrics) are equal, then the decision what route to use is determined by the configuration of the ecmp in the config>router context.
Default preferences are listed in Table 45
Route Type | Preference | Configurable |
Direct attached | 0 | No |
Static route | 5 | Yes |
MPLS | 7 | — |
OSPF internal routes | 10 | No |
IS-IS level 1 internal | 15 | Yes |
IS-IS level 2 internal | 18 | Yes |
OSPF external | 150 | Yes |
IS-IS level 1 external | 160 | Yes 1 |
IS-IS level 2 external | 165 | Yes 1 |
BGP | 170 | Yes |
Note:
This command enables the exclusive use of wide metrics in the LSPs for the level number. Narrow metrics can have values between 1 and 63. IS-IS can generate two TLVs, one for the adjacency and one for the IP prefix. In order to support traffic engineering, wider metrics are required. When wide metrics are used, a second pair of TLVs are added, again, one for the adjacency and one for the IP prefix.
By default, both sets of TLVs are generated. When wide-metrics-only is configured, IS-IS only generates the pair of TLVs with wide metrics for that level.
The no form of the command reverts to the default value.
This command configures the routing level for an instance of the IS-IS routing process.
An IS-IS router and an IS-IS interface can operate at Level 1, Level 2 or both Level 1 and 2.
Table 46 displays configuration combinations and the potential adjacencies that can be formed.
Global Level | Interface Level | Potential Adjacency |
L 1/2 | L 1/2 | Level 1 and/or Level 2 |
L 1/2 | L 1 | Level 1 only |
L 1/2 | L 2 | Level 2 only |
L 2 | L 1/2 | Level 2 only |
L 2 | L 2 | Level 2 only |
L 2 | L 1 | none |
L 1 | L 1/2 | Level 1 only |
L 1 | L 2 | none |
L 1 | L 1 | Level 1 only |
The no form of the command removes the level capability from the configuration.
level-1/2
This command configures a link-group for the router or VPRN instance.
The no form of the command removes the specified link-group.
This command adds a description string to the associated link-group. The string can be up to 256 characters long and can only contain printable characters. If the command is issued in the context of a link-group that already contains a description then the previous description string is replaced.
The no form of the command removes the description from the associated link-group.
revert-members oper-members
This command sets the offset value for the IPv4 multicast address family. If the number of operational links drops below the oper-members threshold, the configured offset is applied to the interface metric for the IPv4 multicast topology
The no form of the command reverts the offset value to 0.
no ipv4-multicast-metric-offset
This command sets the offset value for the IPv4 unicast address family. If the number of operational links drops below the oper-members threshold, the configured offset is applied to the interface metric.
The no form of the command reverts the offset value to 0.
no ipv4-unicast-metric-offset
This command sets the offset value for the IPv6 unicast address family. If the number of operational links drops below the oper-members threshold, the configured offset is applied to the interface metric for the IPv6 topology.
The no form of the command reverts the offset value to 0.
no ipv6-unicast-metric-offset
This command adds or removes a links to the associated link-group. The interface name should already exist before it is added to a link-group.
The no form of the command removes the specified interface from the associated link-group.
This command sets the threshold for the minimum number of operational links for the associated link-group. If the number of operational links drops below this threshold, the configured offsets are applied. For example, oper-members=3. The metric of the member interfaces is increased when the number of interfaces is lower than 3.
The no form of the command reverts the oper-members limit to 1.
oper-members 0
This command sets the threshold for the minimum number of operational links to return the associated link-group to its normal operating state and remove the associated offsets to the IS-IS metrics. If the number of operational links is equal to or greater than the configured revert-member threshold then the configured offsets are removed.
The no form of the command reverts the revert-members threshold back to the default which is equal to the oper-member threshold value.
This command enables Loop-Free Alternate (LFA) computation by SPF under the IS-IS routing protocol level or under the OSPF routing protocol instance level.
When this command is enabled, it instructs the IGP SPF to attempt to pre-compute both a primary next-hop and an LFA next-hop for every learned prefix. When found, the LFA next-hop is populated into the routing table along with the primary next-hop for the prefix.
The no form of this command disables the LFA computation by IGP SPF.
no loopfree-alternate
This command excludes from LFA SPF calculation prefixes that match a prefix entry or a tag entry in a prefix policy.
The implementation already allows the user to exclude an interface in IS-IS or OSPF, an OSPF area, or an IS-IS level from the LFA SPF.
If a prefix is excluded from LFA, then it will not be included in LFA calculation regardless of its priority. The prefix tag will, however, be used in the main SPF. Prefix tags are defined for the IS-IS protocol but not for the OSPF protocol.
The default action of the loopfree-alternate-exclude command, when not explicitly specified by the user in the prefix policy, is a “reject”. Thus, regardless if the user did or did not explicitly add the statement “default-action reject” to the prefix policy, a prefix that did not match any entry in the policy will be accepted into LFA SPF.
The no form deletes the exclude prefix policy.
This command sets the time, in seconds, the router wants the LSPs it originates to be considered valid by other routers in the domain.
Each LSP received is maintained in an LSP database until the lsp-lifetime expires unless the originating router refreshes the LSP. By default, each router refreshes its LSPs every 20 minutes (1200 seconds) so other routers will not age out the LSP.
The LSP refresh timer is derived from this formula: lsp-lifetime/2
The no form of the command reverts to the default value.
1200 — LSPs originated by the router should be valid for 1200 seconds (20 minutes).
This command configures the LSP MTU size. If the size value is changed from the default using CLI or SNMP, then ISIS must be restarted for the change to take effect. This can be done by performing a shutdown command and then a no shutdown command in the config>router>isis context.
Note: Using the exec command to execute a configuration file to change the LSP MTU size from its default value will automatically restart IS-IS for the change to take effect. |
The no form of the command reverts to the default value.
1492
This command configures the IS-IS LSP refresh timer interval for the VPRN instance. When configuring the LSP refresh interval, the value that is specified for lsp-lifetime must also be considered. The LSP refresh interval cannot be greater than 90% of the LSP lifetime.
The no form of the command reverts to the default (600 seconds), unless this value is greater than 90% of the LSP lifetime. For example, if the LSP lifetime is 400, then the no lsp-refresh-interval command will be rejected.
600
This command enables IS-IS multi-topology support.
disabled
This command enables support for the IPv4 topology (MT3) within the associate IS-IS instance.
The no form of this command disables support for the IPv4 topology (MT3) within the associated IS-IS instance.
no ipv4-multicast
This command enables multi-topology TLVs.
The no form of the command disables multi-topology TLVs.
This command enables ISIS to submit routes into the multicast Route Table Manager (RTM).
The no form of the command disables the submission of routes into the multicast RTM.
no multicast-import
This command administratively sets the IS-IS router to operate in the overload state for a specific time period, in seconds, or indefinitely.
During normal operation, the router may be forced to enter an overload state due to a lack of resources. When in the overload state, the router is only used if the destination is reachable by the router and will not used for other transit traffic.
If a time period is specified, the overload state persists for the configured length of time. If no time is specified, the overload state operation is maintained indefinitely.
The overload command can be useful in circumstances where the router is overloaded or used prior to executing a shutdown command to divert traffic around the router.
The no form of the command causes the router to exit the overload state.
no overload
When the router is in an overload state, the router is used only if there is no other router to reach the destination. This command configures the IGP upon bootup in the overload state until one of the following events occur:
If no timeout is specified, IS-IS will go into overload indefinitely after a reboot. After the reboot, the IS-IS status will display a permanent overload state:
This state can be cleared with the config>router>isis>no overload command.
When specifying a timeout value, IS-IS will go into overload for the configured timeout after a reboot. After the reboot, the IS-IS status will display the remaining time the system stays in overload:
The overload state can be cleared before the timeout expires with the config>router>isis>no overload command.
The no form of the command removes the overload-on-boot functionality from the configuration.
no overload-on-boot
Use the show router isis status command to display the administrative and operational state as well as all timers.
Enable use of Purge Originator Identification (POI) TLV for this IS-IS instance. The POI is added to purges and contains the system ID of the router that generated the purge, which simplifies troubleshooting and determining what caused the purge.
The no form of the command removes the POI functionality from the configuration.
no poi-tlv-enable
This command enables authentication of individual ISIS packets of partial sequence number PDU (PSNP) type.
The no form of the command suppresses authentication of PSNP packets.
This command configures the maximum number of prefixes that IS-IS can learn, and use to protect the system from a router that has accidentally advertised a large number of prefixes. If the number of prefixes reaches the configured percentage of this limit, an SNMP trap is sent. If the limit is exceeded, IS-IS will go into overload.
The overload-timeout option controls the length of time that IS-IS is in the overload state when the prefix-limit is reached. The system automatically attempts to restart IS-IS at the end of this duration. If the overload-timeout forever option is used, IS-IS is not restarted automatically and stays in overload until the condition is manually cleared by the administrator. This is also the default behavior when the overload-timeout option is not configured.
The no form of the command removes the prefix-limit.
forever
This command configures the reference bandwidth that provides the basis of bandwidth relative costing.
In order to calculate the lowest cost to reach a specific destination, each configured level on each interface must have a cost. If the reference bandwidth is defined, then the cost is calculated using the following formula:
cost = reference – bandwidth ÷ bandwidth
If the reference bandwidth is configured as 10 Gigabits (10,000,000,000), a 100 M/bps interface has a default metric of 100. In order for metrics in excess of 63 to be configured, wide metrics must be deployed. (See wide-metrics-only in the config>router>isis context.)
If the reference bandwidth is not configured, then all interfaces have a default metric of 10.
The no form of the command reverts to the default value.
no reference-bandwidth — No reference bandwidth is defined. All interfaces have a metric of 10.
This command enabled RIB prioritization for the IS-IS protocol and specifies the prefix list or IS-IS tag value that will be used to select the specific routes that should be processed through the IS-IS route calculation process at a higher priority.
The no rib-priority form of command disables RIB prioritization.
no rib-priority
This command sets the router ID for a specific VPRN context.
If neither the router ID nor system interface are defined, the router ID from the base router context is inherited.
The no form of the command removes the router ID definition from the given VPRN context.
no router-id
This command enables the use of an RSVP-TE shortcut for resolving IGP routes by IS-IS or OSPF routing protocols.
This command instructs IS-IS or OSPF to include RSVP LSPs originating on this node and terminating on the router-id of a remote node as direct links with a metric equal to the operational metric provided by MPLS. If the user enabled the relative-metric option for this LSP, IGP will apply the shortest IGP cost between the endpoints of the LSP plus the value of the offset, instead of the LSP operational metric, when computing the cost of a prefix which is resolved to the LSP.
When a prefix is resolved to a tunnel next-hop, the packet is sent labeled with the label stack corresponding to the NHLFE of the RSVP LSP. Any network event causing an RSVP LSP to go down will trigger a full SPF computation which may result in installing a new route over another RSVP LSP shortcut as tunnel next-hop or over a regular IP next-hop.
When rsvp-shortcut is enabled at the IGP instance level, all RSVP LSPs originating on this node are eligible by default as long as the destination address of the LSP, as configured in configure>router>mpls>lsp>to, corresponds to a router-id of a remote node. RSVP LSPs with a destination corresponding to an interface address or any other loopback interface address of a remote node are automatically not considered by IS-IS or OSPF. The user can, however, exclude a specific RSVP LSP from being used as a shortcut for resolving IGP routes by entering the config>router>mpls>lsp>no igp-shortcut command.
The SPF in OSPF or IS-IS will only use RSVP LSPs as forwarding adjacencies, IGP shortcuts, or as endpoints for LDP-over-RSVP. These applications of RSVP LSPs are mutually exclusive at the IGP instance level. If the user enabled two or more options in the same IGP instance, then forwarding adjacency takes precedence over the shortcut application, which takes precedence over the LDP-over-RSVP application.
When ECMP is enabled on the system and multiple equal-cost paths exist for a prefix, the following selection criteria are used to pick up the set of next-hops to program in the data path:
The ingress IOM will spray the packets for this prefix over the set of tunnel next-hops and IP next-hops based on the hashing routine currently supported for IPv4 packets.
This feature provides IGP with the capability to populate the multicast RTM with the prefix IP next-hop when both the rsvp-shortcut and the multicast-import options are enabled in IGP. The unicast RTM can still make use of the tunnel next-hop for the same prefix. This change is made possible with the enhancement by which SPF keeps track of both the direct first hop and the tunneled first hop of a node which is added to the Dijkstra tree.
The resolution and forwarding of IPv6 prefixes to IPv4 IGP shortcuts is not supported.
The no form of this command disables the resolution of IGP routes using RSVP shortcuts.
no rsvp-shortcut
This command enables IS-IS multi-instance (MI) as described in draft-ginsberg-isis-mi-bis-01. Multiple instances allow instance-specific adjacencies to be formed that support multiple network topologies on the same physical interfaces. Each instance has an LSDB, and each PDU contains a TLV identifying the instance and the topology to which the PDU belongs. A single topology is supported in each instance, so the instance-specific topology identifier (ITID) is set to 0 and cannot be changed.
The standard-multi-instance (based on draft-ginsberg-isis-mi-bis-01) and iid-tlv-enable (based on draft-ietf-isis-mi-02) commands cannot be configured in the same instance, because the MAC addresses and PDUs from the two standards are incompatible.
The no form of the command removes the standard-multi-instance configuration.
no standard-multi-instance
This command configures the IS-IS timer values.
disabled
This command is used to customize LSP generation throttling. Timers that determine when to generate the first, second, and subsequent LSPs can be controlled with this command. Subsequent LSPs are generated at increasing intervals of the second lsp-wait timer until a maximum value is reached.
This command defines the maximum interval, in milliseconds, between two consecutive SPF calculations. Timers that determine when to initiate the first, second and subsequent SPF calculations after a topology change occurs can be controlled with this command. Subsequent SPF runs (if required) will occur at exponentially increasing intervals of the spf-second-wait interval. For example, if the spf-second-wait interval is 1000, then the next SPF will run after 2000 milliseconds, and the next SPF after that will run after 4000 milliseconds, and so on, until it reaches the spf-wait value. The SPF interval will stay at the spf-wait value until there are no more SPF runs scheduled in that interval. After a full interval without any SPF runs, the SPF interval will drop back to the SPF initial-wait value.
no spf-wait
This command enables strict checking of address families (IPv4 and IPv6) for IS-IS adjacencies. When enabled, adjacencies will not come up unless both routers have exactly the same address families configured. If there is an existing adjacency with unmatched address families, it will be torn down. This command is used to prevent black-holing traffic when IPv4 and IPv6 topologies are different. When disabled (no strict-adjacency-check) a BFD session failure for either IPv4 or Ipv6 will cause the routes for the other address family to be removed as well.
When disabled (no strict-adjacency-check), both routers only need to have one common address family to establish the adjacency.
no strict-adjacency-check
This command creates summary-addresses for the specified router or VPRN instance.
n/a
ip-prefix | a.b.c.d (host bits must be 0) |
ipv4-prefix-length | 0 to 32 |
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
ipv6-prefix-length | 0 to 128 |
This command configures the IS-IS system ID. The system ID has a fixed length of 6 octets; it is determined using the following preference:
The system ID is integral to IS-IS; therefore, for the system-id command to take effect, a shutdown and then no shutdown must be performed on the IS-IS instance. This will ensure that the configured and operational system ID are always the same.
The no form of the command removes the system ID from the configuration. The router ID is used when no system ID is specified.
no system-id
This command configures IS-IS to ignore the attached bit on received Level 1 LSPs to disable installation of default routes.
This command configures IS-IS to suppress setting the attached bit on originated Level 1 LSPs to prevent all L1 routers in the area from installing a default route to it.
This command applies one or more (up to 5) route polices as IS-IS import policies.
When a prefix received in an IS-IS LSP is accepted by an entry in an IS-IS import policy, it is installed in the routing table, if it is the most preferred route to the destination.
When a prefix received in an IS-IS LSP is rejected by an entry in an IS-IS import policy, it is not installed in the routing table, even if it has the lowest preference value among all the routes to that destination.
The flooding of LSPs is unaffected by IS-IS import policy actions.
The no form of the command removes all policies from the configuration.
no import
This command allows one IGP to import its routes into RPF RTM while another IGP imports routes only into the unicast RTM. Import policies can redistribute routes from an IGP protocol into the RPF RTM (the multicast routing table). By default, the IGP routes will not be imported into RPF RTM as such an import policy must be explicitly configured.
disabled
This command enables access to the context to enable an OSPF protocol instance.
When an OSPF instance is created, the protocol is enabled. To start or suspend execution of the OSPF protocol without affecting the configuration, use the no shutdown command.
The no form of the command deletes the OSPF protocol instance removing all associated configuration parameters.
no ospf — The OSPF protocol is not enabled.
This command creates an OSPFv3 routing instance and then enters the associated context to configure associated protocol parameters.
When an OSPFv3 instance is created, the protocol is enabled. To start or suspend execution of the OSPF.
The no form of the command deletes the OSPFv3 protocol instance, removing all associated configuration parameters.
no default
This command enables advertisement of a router's capabilities to its neighbors for informational and troubleshooting purposes. A Router Information (RI) LSA as defined in RFC 4970 advertises the following capabilities:
The parameters (link, area & as) control the scope of the capabilities advertisements.
The no form of this command, disables this capability.
no advertise-router-capability
This command creates the context to configure an OSPF area. An area is a collection of network segments within an AS that have been administratively grouped together. The area ID can be specified in dotted decimal notation or as a 32-bit decimal integer.
The no form of the command deletes the specified area from the configuration. Deleting the area also removes the OSPF configuration of all the interfaces, virtual-links, sham-links, and address-ranges etc., that are currently assigned to this area.
no area — No OSPF areas are defined.
This command creates ranges of addresses on an Area Border Router (ABR) for the purpose of route summarization or suppression. When a range is created, the range is configured to be advertised or not advertised into other areas. Multiple range commands may be used to summarize or hide different ranges. In the case of overlapping ranges, the most specific range command applies.
ABRs send summary link advertisements to describe routes to other areas. To minimize the number of advertisements that are flooded, you can summarize a range of IP addresses and send reachability information about these addresses in an LSA.
The no form of the command deletes the range (non) advertisement.
no area-range — No range of addresses are defined.
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
ipv6-prefix-length | 0 to 128 |
The default is advertise.
This command installs a low priority blackhole route for the entire aggregate. Existing routes that make up the aggregate will have a higher priority and only the components of the range for which no route exists are blackholed.
It is possible that when performing area aggregation, addresses may be included in the range for which no actual route exists. This can cause routing loops. To avoid this problem configure the blackhole aggregate option.
The no form of this command removes this option.
blackhole-aggregate
This command creates a context to configure an OSPF interface.
By default interfaces are not activated in any interior gateway protocol such as OSPF unless explicitly configured.
The no form of the command deletes the OSPF interface configuration for this interface. The shutdown command in the config>router>ospf>interface context can be used to disable an interface without removing the configuration for the interface.
no interface — No OSPF interfaces are defined.
If the IP interface name does not exist or does not have an IP address configured an error message will be returned.
If the IP interface exists in a different area it will be moved to this area.
This command is similar to a virtual link with the exception that metric must be included in order to distinguish the cost between the MPLS-VPRN link and the backdoor.
This command enables advertising point-to-point interfaces as subnet routes (network number and mask). When disabled, point-to-point interfaces are advertised as host routes.
This command is not supported in the OSPF3 context.
The no form of the command disables advertising point-to-point interfaces as subnet routes meaning they are advertised as host routes.
advertise-subnet — Advertises point-to-point interfaces as subnet routes.
This command configures OPSFv3 confidentiality authentication.
The no form of the command removes the SA name from the configuration.
This command configures the password used by the OSPF interface or virtual-link to send and receive OSPF protocol packets on the interface when simple password authentication is configured.
This command is not valid in the OSPF3 context.
All neighboring routers must use the same type of authentication and password for proper protocol communication. If the authentication-type is configured as password, then this key must be configured.
By default, no authentication key is configured.
This command is not supported in the OSPF context.
The no form of the command removes the authentication key.
no authentication-key — No authentication key is defined.
This is useful when a user must configure the parameter, but, for security purposes, the actual unencrypted key value is not provided.
This command enables authentication and specifies the type of authentication to be used on the OSPF interface, virtual-link, and sham-link.
This command is not valid in the OSPF3 context.
Both simple password and message-digest authentication are supported.
By default, authentication is not enabled on an interface.
The no form of the command disables authentication on the interface.
This command is not supported in the OSPF context.
no authentication — no authentication is enabled on an interface
This command enables the use of bi-directional forwarding (BFD) to control the state of the associated protocol interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set via the BFD command under the IP interface.
The no form of this command removes BFD from the associated IGP protocol adjacency.
no bfd-enable
This command configures the time, in seconds, that OSPF waits before declaring a neighbor router down. If no hello packets are received from a neighbor for the duration of the dead interval, the router is assumed to be down. The minimum interval must be two times the hello interval.
The no form of the command reverts to the default value.
40
Sham-link — If the dead-interval configured applies to a sham-link, then the interval on both endpoints of the sham-link must have the same dead interval.
This command enables OSPF graceful restart (GR) to minimize service interruption. When the control plane of a GR-capable router fails or restarts, the neighboring routers (GR helpers) temporarily preserve OSPF forwarding information. Traffic continues to be forwarded to the restarting router using the last known forwarding tables. If the control plane of the restarting router becomes operationally and administratively up within the grace period, the restarting router resumes normal OSPF operation. If the grace period expires, then the restarting router is presumed inactive and the OSPF topology is recalculated to route traffic around the failure.
The no form of the command disables graceful restart and removes the graceful restart configuration from the OSPF instance.
no graceful-restart
This command disables helper support for OSPF graceful restart (GR).
When graceful-restart is enabled, the router can be a helper (meaning that the router is helping a neighbor to restart), a restarting router, or both. The router only supports helper mode. It will not act as a restarting router, because the high availability feature set already preserves OSPF forwarding information such that this functionality is not needed. This command is a historical command and should not be disabled. Configuring helper-disable has the effect of disabling graceful restart, because the router only supports helper mode.
The no helper-disable command enables helper support and is the default when graceful restart is enabled.
no helper-disable
This command indicates whether an OSPF restart helper should terminate graceful restart when there is a change to an LSA that would be flooded to the restarting router during the restart process.
The default OSPF behavior is to terminate a graceful restart if an LSA changes, which causes the OSPF neighbor to go down.
The no strict-lsa-checking command disables strict LSA checking.
strict-lsa-checking
This command specifies whether to suppress the setting of the DN bit for OSPF or OSPF3 LSA packets generated by this instance of OSPF or OSPF3 on the router.
The no form of the command enables the OSPF or OSPF3 router to follow the normal procedure to determine whether to set the DN bit.
no ignore-dn-bit
This command applies one or more (up to 5) route polices as OSPF import policies. When a prefix received in an OSPF LSA is accepted by an entry in an OSPF import policy it is installed in the routing table if it is the most preferred route to the destination. When a prefix received in an OSPF LSA is rejected by an entry in an OSPF import policy it is not installed in the routing table, even if it has the lowest preference value among all the routes to that destination. The flooding of LSAs is unaffected by OSPF import policy actions. This command only applies to the 7750 SR.
If an OSPF route has the lowest preference value among all routes to a destination it is installed in the routing table.
The specified name(s) must already be defined.
This command configures the interval between OSPF hellos issued on the interface, virtual link, or sham-link.
The hello interval, in combination with the dead-interval, is used to establish and maintain the adjacency. Use this parameter to edit the frequency that hello packets are sent.
Reducing the interval, in combination with an appropriate reduction in the associated dead-interval, allows for faster detection of link and/or router failures at the cost of higher processing costs.
The no form of this command reverts to the default value.
hello-interval 10 — a 10-second hello interval
This command configures the interface type to be either broadcast or point-to-point.
Use this command to set the interface type of an Ethernet link to point-to-point to avoid having to carry the broadcast adjacency maintenance overhead if the Ethernet link provided the link is used as a point-to-point.
If the interface type is not known at the time the interface is added to OSPF and subsequently the IP interface is bound (or moved) to a different interface type, this command must be entered manually.
The no form of the command reverts to the default value.
point-to-point — if the physical interface is SONET
broadcast — if the physical interface is Ethernet or unknown
This command instructs IGP to not include a specific interface or all interfaces participating in a specific IS-IS level or OSPF area in the SPF LFA computation. This provides a way of reducing the LFA SPF calculation where it is not needed.
When an interface is excluded from the LFA SPF in IS-IS, it is excluded in both level 1 and level 2. When it is excluded from the LFA SPF in OSPF, it is excluded in all areas. However, the above OSPF command can only be executed under the area in which the specified interface is primary and once enabled, the interface is excluded in that area and in all other areas where the interface is secondary. If the user attempts to apply it to an area where the interface is secondary, the command will fail.
The no form of this command re-instates the default value for this command.
no loopfree-alternate-exclude
This command enables filtering of outgoing OSPF LSAs on the selected OSPFv2 or OSPFv3 interface. Three filtering options are provided:
The no form of this command disables OSPF LSA filtering (normal operation).
no lsa-filter-out
This command enables the submission of routes into the multicast Route Table Manager (RTM) by OSPF.
The no form of the command disables the submission of routes into the multicast RTM.
no multicast-import
This command configures a message digest key when MD5 authentication is enabled on the interface, virtual-link or sham-link. Multiple message digest keys can be configured.
This command is not valid in the OSPF3 context.
The no form of the command removes the message digest key identified by the key-id.
No message digest keys are defined.
This is useful when a user must configure the parameter, but, for security purposes, the actual unencrypted key value is not provided.
This command configures an explicit route cost metric for the OSPF interface that overrides the metrics calculated based on the speed of the underlying link.
The no form of the command deletes the manually configured interface metric, so the interface uses the computed metric based on the reference-bandwidth command setting and the speed of the underlying link.
no metric — the metric is based on reference-bandwidth setting and the link speed
This command configures the OSPF packet size used on this interface. If this parameter is not configured OSPF derives the MTU value from the MTU configured (default or explicitly) in the following contexts:
config>port>ethernet config>port>sonet-sdh>path config>port>tdm>t3-e3 config>port>tdm>t1-e1>channel-group
If this parameter is configured, the smaller value between the value configured here and the MTU configured (default or explicitly) in an above-mentioned context is used.
To determine the actual packet size add 14 bytes for an Ethernet packet and 18 bytes for a tagged Ethernet packet to the size of the OSPF (IP) packet MTU configured in this command.
Use the no form of this command to revert to default.
no mtu — Uses the value derived from the MTU configured in the config>port context.
This command adds the passive property to the OSPF interface where passive interfaces are advertised as OSPF interfaces but do not run the OSPF protocol.
By default, only interface addresses that are configured for OSPF will be advertised as OSPF interfaces. The passive parameter allows an interface to be advertised as an OSPF interface without running the OSPF protocol.
While in passive mode, the interface will ignore ingress OSPF protocol packets and not transmit any OSPF protocol packets.
The no form of the command removes the passive property from the OSPF interface.
Service interfaces defined in config>router>service-prefix are passive.
All other interfaces are not passive.
This command configures the priority of the OSPF interface that is used an election of the designated router on on the subnet.
This parameter is only used if the interface is of type broadcast. The router with the highest priority interface becomes the designated router. A router with priority 0 is not eligible to be Designated Router or Backup Designated Router.
The no form of the command reverts the interface priority to the default value.
priority 1
This command specifies the length of time, in seconds, that OSPF will wait before retransmitting an unacknowledged link state advertisement (LSA) to an OSPF neighbor.
The value should be longer than the expected round trip delay between any two routers on the attached network. Once the retransmit-interval expires and no acknowledgement has been received, the LSA will be retransmitted.
The no form of this command reverts to the default interval.
retransmit-interval 5
This command enables RIB prioritization for the OSPF/OSPFv3 protocol. When enabled at the OSPF interface level, all routes learned through the associated OSPF interface will be processed through the OSPF route calculation process at a higher priority.
The no form of rib-priority command disables RIB prioritization at the associated level.
no rib-priority
This command configures the estimated time, in seconds, that it takes to transmit a link state advertisement (LSA) on the interface or virtual link or sham-link.
The no form of this command reverts to the default delay time.
transit-delay 1
This command configures the key rollover interval.
The no form of the command reverts to the default.
10
This command specifies whether or not the OSPF area should be excluded during LFA calculations. When enabled, the OSPF area is excluded from LFA calculations. When disabled (the default), the OSPF area is included in LFA calculations.
The no form of the command includes the OSPF area in LFA calculations.
disabled
This command creates the context to configure an OSPF Not So Stubby Area (NSSA) and adds/removes the NSSA designation from the area.
NSSAs are similar to stub areas in that no external routes are imported into the area from other OSPF areas. The major difference between a stub area and an NSSA is an NSSA has the capability to flood external routes that it learns throughout its area and via an ABR to the entire OSPF domain.
Existing virtual links of a non-stub or NSSA area will be removed when the designation is changed to NSSA or stub.
An area can be designated as stub or NSSA but never both at the same time.
By default, an area is not configured as an NSSA area.
The no form of the command removes the NSSA designation and configuration context from the area.
no nssa — The OSPF area is not an NSSA.
This command enables the generation of a default route and its LSA type (3 or 7) into a Not So Stubby Area (NSSA) by an NSSA Area Border Router (ABR) or Autonomous System Border Router (ASBR).
When configuring an NSSA with no summaries, the ABR will inject a type 3 LSA default route into the NSSA area. Some older implementations expect a type 7 LSA default route.
The no form of the command disables origination of a default route.
no originate-default-route — A default route is not originated.
Configure this parameter to inject a type 7 LSA default route into an NSSA configured with no summaries, instead of a type 3 LSA.
To revert to a type 3 LSA, execute the originate-default-route command without the type-7 parameter.
This command enables the redistribution of external routes into the Not So Stubby Area (NSSA) or an NSSA area border router (ABR) that is exporting the routes into non-NSSA areas.
NSSA or Not So Stubby Areas are similar to stub areas in that no external routes are imported into the area from other OSPF areas. The major difference between a stub area and an NSSA is that the NSSA has the capability to flood external routes that it learns (providing it is an ASBR) throughout its area and via an Area Border Router to the entire OSPF domain.
The no form of the command disables the default behavior to automatically redistribute external routes into the NSSA area from the NSSA ABR.
redistribute-external — External routes are redistributed into the NSSA.
This command enables sending summary (type 3) advertisements into a stub area or Not So Stubby Area (NSSA) on an Area Border Router (ABR). This parameter is particularly useful to reduce the size of the routing and Link State Database (LSDB) tables within the stub or nssa area. By default, summary route advertisements are sent into the stub area or NSSA.
The no form of the command disables sending summary route advertisements and, for stub areas, only the default route is advertised by the ABR.
summaries — Summary routes are advertised by the ABR into the stub area or NSSA.
This command enables access to the context to configure an OSPF stub area and adds/removes the stub designation from the area. External routing information is not flooded into stub areas. All routers in the stub area must be configured with the stub command. An OSPF area cannot be both an NSSA and a stub area. Existing virtual links of a non STUB or NSSA area will be removed when its designation is changed to NSSA or STUB.
By default, an area is not a stub area.
The no form of the command removes the stub designation and configuration context from the area.
no stub — The area is not configured as a stub area.
This command configures the metric used by the area border router (ABR) for the default route into a stub area. The default metric should only be configured on an ABR of a stub area. An ABR generates a default route if the area is a stub area.
The no form of the command reverts to the default value.
default-metric 1
This command configures a virtual link to connect area border routers to the backbone via a virtual link. The backbone area (area 0.0.0.0) must be contiguous and all other areas must be connected to the backbone area. If it is not practical to connect an area to the backbone (see area 0.0.0.2 in the picture below) then the area border routers (routers 1 and 2 in the picture below) must be connected via a virtual link. The two area border routers will form a point-to-point like adjacency across the transit area (area 0.0.0.1 in the picture below). A virtual link can only be configured while in the area 0.0.0.0 context.
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 the command deletes the virtual link.
No virtual link is defined.
The OSPF backbone area, area 0.0.0.0, must be contiguous and all other areas must be connected to the backbone area. The backbone distributes routing information between areas. If it is not practical to connect an area to the backbone (see Area 0.0.0.5 in Figure 47) then the area border routers (such as routers Y and Z) must be connected via a virtual link. The two area border routers form a point-to-point-like adjacency across the transit area (see Area 0.0.0.4).
This command enables OSPF summary and external route calculations in compliance with RFC1583 and earlier RFCs.
RFC1583 and earlier RFCs use a different method to calculate summary and external route costs. To avoid routing loops, all routers in an OSPF domain should perform the same calculation method.
Although it would be favorable to require all routers to run a more current compliancy level, this command allows the router to use obsolete methods of calculation.
This command is not supported in OSPF3.
The no form of the command enables the post-RFC1583 method of summary and external route calculation.
compatible-rfc1583 — RFC1583 compliance is enabled.
This command associates export route policies to determine which routes are exported from the route table to OSPF. Export polices are only in effect if OSPF is configured as an ASBR.
If no export policy is specified, non-OSPF routes are not exported from the routing table manager to OSPF.
If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple export commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.
The no form of the command removes all policies from the configuration.
no export — No export route policies specified.
The specified name(s) must already be defined.
This command enables limits on the number of non-default AS-external-LSA entries that can be stored in the LSDB and specifies a wait timer before processing these after the limit is exceeded.
The limit value specifies the maximum number of non-default AS-external-LSA entries that can be stored in the link-state database (LSDB). Placing a limit on the non-default AS-external-LSAs in the LSDB protects the router from receiving an excessive number of external routes that consume excessive memory or CPU resources. If the number of routes reach or exceed the limit, the table is in an overflow state. When in an overflow state, the router will not originate any new AS-external-LSAs. In fact, it withdraws all the self-originated non-default external LSAs.
The interval specifies the amount of time to wait after an overflow state before regenerating and processing non-default AS-external-LSAs. The waiting period acts like a dampening period preventing the router from continuously running Shortest Path First (SPF) calculations caused by the excessive number of non-default AS-external LSAs.
The external-db-overflow must be set identically on all routers attached to any regular OSPF area. OSPF stub areas and not-so-stubby areas (NSSAs) are excluded.
The no form of the command disables limiting the number of non-default AS-external-LSA entries.
no external-db-overflow — No limit on non-default AS-external-LSA entries.
This command configures the preference for OSPF external routes.
A route can be learned by the router from different protocols in which case the costs are not comparable; when this occurs the preference is used to decide which route will be used.
Different protocols should not be configured with the same preference, if this occurs the tiebreaker is per the default preference table as defined in the following table. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used.
If multiple routes are learned with an identical preference using the same protocol and the costs (metrics) are equal, then the decision of what route to use is determined by the configuration of the ecmp in the config>router context.
The no form of the command reverts to the default value.
external-preference 150 — OSPF external routes have a default preference of 150.
Route Type | Preference | Configurable |
Direct attached | 0 | No |
Static routes | 5 | Yes |
OSPF internal | 10 | Yes 1 |
IS-IS level 1 internal | 15 | Yes |
IS-IS level 2 internal | 18 | Yes |
RIP | 100 | Yes |
OSPF external | 150 | Yes |
IS-IS level 1 external | 160 | Yes |
IS-IS level 2 external | 165 | Yes |
BGP | 170 | Yes |
Note:
This command specifies whether to ignore the DN bit for OSPF LSA packets for this instance of OSPF on the router. When enabled, the DN bit for OSPF LSA packets will be ignored. When disabled, the DN bit will not be ignored for OSPF LSA packets.
This command enables Loop-Free Alternate (LFA) computation by SPF under the IS-IS routing protocol level, or under the OSPF routing protocol instance level.
When this command is enabled, it instructs the IGP SPF to attempt to pre-compute both a primary next-hop and an LFA next-hop for every learned prefix. IS-IS computes the primary SPF first and then computes the LFA SPF. The LFA backup next-hop is only available after the LFA SPF is completed. When found, the LFA next-hop is populated into the routing table along with the primary next-hop for the prefix.
The no form of this command disables the LFA computation by IGP SPF.
no loopfree-alternate
This command changes the overload state of the local router so that it appears to be overloaded. When overload is enabled, the router can participate in OSPF routing, but is not used for transit traffic. Traffic destined to directly attached interfaces continue to reach the router.
To put the IGP in an overload state enter a timeout value. The IGP will enter the overload state until the timeout timer expires or a no overload command is executed.
If the overload command is encountered during the execution of an overload-on-boot command then this command takes precedence. This could occur as a result of a saved configuration file where both parameters are saved. When the file is saved by the system the overload-on-boot command is saved after the overload command.
Use the no form of this command to return to the default. When the no overload command is executed, the overload state is terminated regardless the reason the protocol entered overload state.
no overload
This command creates the context to configure or apply IP interface attributes such as administrative group (admin-group) or Shared Risk Loss Group (SRLG).
This command configures the admin group membership of an interface. The user can apply admin groups to an IES, VPRN, network IP, or MPLS interface.
Each single operation of the admin-group command allows a maximum of five (5) groups to be specified at a time. However, a maximum of 32 groups can be added to a given interface through multiple operations. Once an admin group is bound to one or more interface, its value cannot be changed until all bindings are removed.
The configured admin-group membership will be applied in all levels/areas the interface is participating in. The same interface cannot have different memberships in different levels/areas.
Only the admin groups bound to an MPLS interface are advertised in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF. IES and VPRN interfaces do not have their attributes advertised in TE TLVs.
The no form of this command deletes one or more of the admin-group memberships of an interface. The user can also delete all memberships of an interface by not specifying a group name.
This command configures the SRLG membership of an interface. The user can apply SRLGs to an IES, VPRN, network IP, or MPLS interface.
An interface can belong to up to 64 SRLG groups. However, each single operation of the srlg-group command allows a maximum of five (5) groups to be specified at a time. Once an SRLG group is bound to one or more interface, its value cannot be changed until all bindings are removed.
The configured SRLG membership will be applied in all levels/areas the interface is participating in. The same interface cannot have different memberships in different levels/areas.
Only the SRLGs bound to an MPLS interface are advertised in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF. IES and VPRN interfaces do not have their attributes advertised in TE TLVs.
The no form of this command deletes one or more of the SRLG memberships of an interface. The user can also delete all memberships of an interface by not specifying a group name.
This command applies a route next-hop policy template to an OSPF or IS-IS interface.
When a route next-hop policy template is applied to an interface in IS-IS, it is applied in both level 1 and level 2. When a route next-hop policy template is applied to an interface in OSPF, it is applied in all areas. However, the command in an OSPF interface context can only be executed under the area in which the specified interface is primary and then applied in that area and in all other areas where the interface is secondary. If the user attempts to apply it to an area where the interface is secondary, the command will fail.
If the user excluded the interface from LFA using the command loopfree-alternate-exclude, the LFA policy, if applied to the interface, has no effect.
Finally, if the user applied a route next-hop policy template to a loopback interface or to the system interface, the command will not be rejected, but it will result in no action being taken.
The no form deletes the mapping of a route next-hop policy template to an OSPF or IS-IS interface.
This command excludes from LFA SPF calculation prefixes that match a prefix entry or a tag entry in a prefix policy.
The implementation already allows the user to exclude an interface in IS-IS or OSPF, an OSPF area, or an IS-IS level from the LFA SPF.
If a prefix is excluded from LFA, then it will not be included in LFA calculation regardless of its priority. The prefix tag will, however, be used in the main SPF. Prefix tags are defined for the IS-IS protocol but not for the OSPF protocol.
The default action of the loopfree-alternate-exclude command, when not explicitly specified by the user in the prefix policy, is a “reject”. Thus, regardless if the user did or did not explicitly add the statement “default-action reject” to the prefix policy, a prefix that did not match any entry in the policy will be accepted into LFA SPF.
The no form deletes the exclude prefix policy.
This command is used to to control if external type-2 routes should be re-advertised with a maximum metric value when the system goes into overload state for any reason. When this command is enabled and the router is in overload, all external type-2 routes will be advertised with the maximum metric.
no overload-include-ext-2
This command is used to to determine if the OSPF stub networks should be advertised with a maximum metric value when the system goes into overload state for any reason. When enabled, the system uses the maximum metric value. When this command is enabled and the router is in overload, all stub interfaces, including loopback and system interfaces, will be advertised at the maximum metric.
no overload-include-stub
When the router is in an overload state, the router is used only if there is no other router to reach the destination. This command configures the IGP upon bootup in the overload state until one of the following events occur:
The no overload command does not affect the overload-on-boot function.
The no form of the command removes the overload-on-boot functionality from the configuration.
no overload-on-boot
This command configures the preference for OSPF internal routes.
A route can be learned by the router from different protocols in which case the costs are not comparable, when this occurs the preference is used to decide to which route will be used.
Different protocols should not be configured with the same preference, if this occurs the tiebreaker is per the default preference table as defined in the following table. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used.
If multiple routes are learned with an identical preference using the same protocol and the costs (metrics) are equal, then the decision of what route to use is determined by the configuration of the ecmp in the config>router context.
The no form of the command reverts to the default value.
preference 10 — OSPF internal routes have a preference of 10.
Route Type | Preference | Configurable |
Direct attached | 0 | No |
Static routes | 5 | Yes |
OSPF internal | 10 | Yes 1 |
IS-IS level 1 internal | 15 | Yes |
IS-IS level 2 internal | 18 | Yes |
RIP | 100 | Yes |
OSPF external | 150 | Yes |
IS-IS level 1 external | 160 | Yes |
IS-IS level 2 external | 165 | Yes |
BGP | 170 | Yes |
Note:
This command configures the reference bandwidth in kilobits per second (Kbps) that provides the reference for the default costing of interfaces based on their underlying link speed.
The default interface cost is calculated as follows:
cost = reference – bandwidth ÷ bandwidth
The default reference-bandwidth is 100,000,000 Kbps or 100 Gbps, so the default auto-cost metrics for various link speeds are as as follows:
The reference-bandwidth command assigns a default cost to the interface based on the interface speed. To override this default cost on a particular interface, use the metric metric command in the config>router>ospf>area>interface ip-int-name context.
The no form of the command reverts the reference-bandwidth to the default value.
reference-bandwidth 100000000 — Reference bandwidth of 100 Gbps.
This command enabled RIB prioritization for the OSPF protocol and specifies the prefix list that will be used to select the specific routes that should be processed through the OSPF route calculation process at a higher priority.
The no form of rib-priority command disables RIB prioritization at the associated level.
no rib-priority
This command specifies whether CE-PE functionality is required or not. The OSPF super backbone indicates the type of the LSA generated as a result of routes redistributed into OSPF. When enabled, the redistributed routes are injected as summary, external or NSSA LSAs. When disabled, the redistributed routes are injected as either external or NSSA LSAs only.
no super-backbone
This command specifies whether to suppress the setting of the DN bit for OSPF LSA packets generated by this instance of OSPF on the router. When enabled, the DN bit for OSPF LSA packets generated by this instance of the OSPF router will not be set. When disabled, this instance of the OSPF router will follow the normal proceedure to determine whether to set the DN bit.
no suppress-dn-bit
This command enables the context that allows for the configuration of OSPF timers. Timers control the delay between receipt of a link state advertisement (LSA) requiring a Dijkstra (Shortest Path First (SPF)) calculation and the minimum time between successive SPF calculations.
Changing the timers affect CPU utilization and network reconvergence times. Lower values reduce convergence time but increase CPU utilization. Higher values reduce CPU utilization but increase reconvergence time.
n/a
This command sets the internal OSPF hold down timer for external routes being redistributed into OSPF.
Shorting this delay can speed up the advertisement of external routes into OSPF but can result in additional OSPF messages if that source route is not yet stable.
The no redistribute-delay form of the command resets the timer value back to the default value.
1000ms (1 second)
This command defines the maximum interval between two consecutive SPF calculations in milliseconds. Timers that determine when to initiate the first, second, and subsequent SPF calculations after a topology change occurs can be controlled with this command. Subsequent SPF runs (if required) will occur at exponentially increasing intervals of the spf-second-wait interval. For example, if the spf-second-wait interval is 1000, then the next SPF will run after 2000 milliseconds, and then next SPF will run after 4000 milliseconds, etc., until it reaches the spf-wait value. The SPF interval will stay at the spf-wait value until there are no more SPF runs scheduled in that interval. After a full interval without any SPF runs, the SPF interval will drop back to spf-initial-wait.
The timer must be entered in increments of 100 milliseconds. Values entered that do not match this requirement will be rejected.
Use the no form of this command to return to the default.
no spf-wait
This command allows one IGP to import its routes into RPF RTM while another IGP imports routes only into the unicast RTM.
Import policies can redistribute routes from an IGP protocol into the RPF RTM (the multicast routing table). By default, the IGP routes will not be imported into RPF RTM as such an import policy must be explicitly configured
no unicast-import-disable
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.
no vpn-domain
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.
vpn-tag 0
This command sets the delay before an incremental SPF calculation is performed when LSA types 3, 4, 5, or 7 are received. This allows multiple updates to be processed in the same SPF calculation. Type 1 or type 2 LSAs are considered a topology change and will always trigger a full SPF calculation.
The no incremental-spf-wait form of the command resets the timer value back to the default value.
1000ms (1 second)
This commands sets the internal OSPF delay to allow for the accumulation of multiple LSA so OSPF messages can be sent as efficiently as possible.
Shorting this delay can speed up the advertisement of LSAs to OSPF neighbors but may increase the number of OSPF messages sent.
1000ms (1 second)
This parameter defines the minimum delay that must pass between receipt of the same Link State Advertisements (LSAs) arriving from neighbors. It is recommended that the neighbor’s configured lsa-generate lsa-second-wait interval is equal to or greater than the lsa-arrival timer configured here.
Use the no form of this command to return to the default.
no lsa-arrival
This parameter customizes the throttling of OSPF LSA-generation. Timers that determine when to generate the first, second, and subsequent LSAs can be controlled with this command. Subsequent LSAs are generated at increasing intervals of the lsa-second-wait timer until a maximum value is reached. Configuring the lsa-arrival interval to equal or less than the lsa-second-wait interval configured in the lsa-generate command is recommended.
Use the no form of this command to return to the default.
no lsa-generate
When an LSA is generated, the initial wait period commences. If, within the specified lsa-initial-wait period and another topology change occurs, then the lsa-initial-wait timer applies.
This command configures a Protocol Independent Multicast (PIM) instance in the VPRN service. When an PIM instance is created, the protocol is enabled. PIM is used for multicast routing within the network. Devices in the network can receive the multicast feed requested and non-participating routers can be pruned. The router supports PIM sparse mode (PIM-SM).
The no form of the command deletes the PIM protocol instance removing all associated configuration parameters.
n/a
This command creates a PIM interface with default parameters.
If a manually created interface or modified interface is deleted, the interface will be recreated when the apply-to command is executed. If PIM is not required on a specific interface, then execute a shutdown command.
The apply-to command is saved first in the PIM configuration structure, all subsequent commands either create new structures or modify the defaults as created by the apply-to command.
apply-to none
This command enables the context to configure GRT/VRF extranet for this MVPN instance.
This command configures multicast group IPv4 prefixes for the multicast GRT/VRF with per group mapping extranet functionality. Multiple lines are allowed. Duplicate prefixes are ignored. Operator can either configure specific groups for extranet or specify all groups by using key-word any. The two options are mutually exclusive in configuration.
When the starg option is specified, extranet functionality is enabled for PIM ASM as for the specified group. When the option is not specified (not recommended with PIM ASM), the PIM ASM join will be mapped and data plane will be established, but the control plane will not be updated on SPT switchover, unless the switchover is driven by a CPE router on a receiver side.
The no form of the command deletes specified prefix from the list, or removes mapping of all prefixes if group-prefix any was specified.
n/a
This command specifies the import route policy to be used for determining which routes are accepted from peers. Route policies are configured in the config>router>policy-options context. When an import policy is not specified, BGP routes are accepted by default.
The no form of the command removes the policy association from the IGMP instance.
no import join-policy no import register-policy
This command enables PIM on an interface and enables the context to configure interface-specific parameters. By default interfaces are activated in PIM based on the apply-to command, and do not have to be configured on an individual basis unless the default values must be changed.
The no form of the command deletes the PIM interface configuration for this interface. If the apply-to command parameter is configured, then the no interface form must be saved in the configuration to avoid automatic (re)creation after the next apply-to is executed as part of a reboot.
The shutdown command can be used to disable an interface without removing the configuration for the interface.
Interfaces are activated in PIM based on the apply-to command.
This command configures the period in seconds for periodic refreshes of PIM Assert messages on an interface.
The no form of the command reverts to the default.
60
This command enables the use of bi-directional forwarding (BFD) to control the state of the associated protocol interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set via the BFD command under the IP interface.
The no form of this command removes BFD from the associated IGP protocol adjacency.
no bfd-enable
This command enables the checking of router alert option in the bootstrap messages received on this interface.
no bsm-check-rtr-alert
This command configures the frequency at which PIM Hello messages are transmitted on this interface.
The no form of this command reverts to the default value.
30
This command configures the multiplier to determine the hold time for a PIM neighbor.
The hello-multiplier in conjunction with the hello-interval determines the hold time for a PIM neighbor.
(hello-interval * hello-multiplier) / 10
This allows the PIMv2 default timeout of 3.5 seconds to be supported.
This command enables improved assert processing on this interface. The PIM assert process establishes a forwarder for a LAN and requires interaction between the control and forwarding planes.
The assert process is started when data is received on an outgoing interface. This could impact performance if data is continuously received on an outgoing interface.
When enabled, the PIM assert process is done entirely on the control-plane with no interaction between the control and forwarding plane.
enabled
This command enables PIM to send an instant prune echo when the router starts the prune pending timer for a group on the interface. All downstream routers will see the prune message immediately, and can send a join override if they are interested in receiving the group. Configuring instant-prune-echo is recommended on broadcast interfaces with more than one PIM neighbor to optimize multicast convergence.
The no form of the command disables instant Prune Echo on the PIM interface.
no instant-prune-echo
This command configures the maximum number of groups for which PIM can have downstream state based on received PIM Joins on this interface. This does not include IGMP local receivers on the interface. When this configuration is changed dynamically to a value lower than the currently accepted number of groups, the groups that are already accepted are not deleted. Only new groups will not be allowed. When this object has a value of 0, there is no limit to the number of groups.
This command configures the way subnet matching is done for incoming data packets on this interface. An IP multicast sender is an user entity to be authenticated in a receiving host.
This command configures the option to join P2MP LDP tree towards the multicast source for the VPRN service. If p2mp-ldp-tree-join is enabled, a PIM multicast join received on an interface is processed to join P2MP LDP LSP using the in-band signaled P2MP tree for the same multicast flow. LDP P2MP tree is setup towards the multicast source. Route to source of the multicast node is looked up from the RTM. The next-hop address for the route to source is set as the root of LDP P2MP tree.
The no form of command disables joining P2MP LDP tree for IPv4 or IPv6 or both (if both or none is specified).
no p2mp-ldp-tree-join
This command sets the priority value to become the rendezvous point (RP) that is included in bootstrap messages sent by the router. The RP is sometimes called the bootstrap router. The priority command indicates whether the router is eligible to be a bootstrap router.
The no form of the command disqualifies the router to participate in the bootstrap election.
1 (The router is the least likely to become the designated router.)
This command enables sticky-dr operation on this interface. When enabled, the priority in PIM hellos sent on this interface when elected as the designated router (DR) will be modified to the value configured in dr-priority. This is done to avoid the delays in forwarding caused by DR recovery, when switching back to the old DR on a LAN when it comes back up.
By enabling sticky-dr on this interface, it will continue to act as the DR for the LAN even after the old DR comes back up.
The no form of the command disables sticky-dr operation on this interface.
disabled
This command configures the compatibility mode for enabling the three way hello.
This command sets the the T bit in the LAN Prune Delay option of the Hello Message. This indicates the router's capability to disable Join message suppression.
no tracking-support
This command administratively disables/enables PIM operation for IPv4.
no ipv4-multicast-disable
This command administratively disables/enables PIM operation for IPv6.
ipv6-multicast-disable
This command enables multicast balancing of traffic over ECMP links based on the number of (S, G) distributed over each link. When enabled, each new multicast stream that needs to be forwarded over an ECMP link is compared to the count of (S, G) already using each link, so that the link with the fewest (S, G) is chosen.
This command cannot be used together with the mc-ecmp-hashing-enabled command.
The no form of the command disables multicast ECMP balancing.
This command configures the hold time for multicast balancing over ECMP links.
This command enables hash-based multicast balancing of traffic over ECMP links and causes PIM joins to be distributed over the multiple ECMP paths based on a hash of S and G (and possibly next-hop IP address). When a link in the ECMP set is removed, the multicast flows that were using that link are redistributed over the remaining ECMP links using the same hash algorithm. When a link is added to the ECMP set new joins may be allocated to the new link based on the hash algorithm, but existing multicast flows using the other ECMP links stay on those links until they are pruned.
Hash-based multicast balancing is supported for both IPv4 and IPv6.
This command cannot be used together with the mc-ecmp-balance command. Using this command and the lag-usage-optimization command on mixed port speed LAGs is not recommended, because some groups may be forwarded incorrectly.
The no form of the command disables the hash-based multicast balancing of traffic over ECMP links.
The no mc-ecmp-hashing-enabled form of the command means that the use of multiple ECMP paths if enabled at the config>router or config>service>vprn context is controlled by the existing implementation and CLI commands mc-ecmp-balance.
no mc-ecmp-hashing-enabled
This command specifies whether the router should ignore the designated router state and attract traffic even when it is not the designated router.
An operator can configure an interface (router or IES or VPRN interfaces) to IGMP and PIM. The interface IGMP state will be synchronized to the backup node if it is associated with the redundant peer port. The interface can be configured to use PIM which will cause multicast streams to be sent to the elected DR only. The DR will also be the router sending traffic to the DSLAM. Since it may be required to attract traffic to both routers a flag non-dr-attract-trafffic can be used in the PIM context to have the router ignore the DR state and attract traffic when not DR. While using this flag, the router may not send the stream down to the DSLAM while not DR.
When enabled, the designated router state is ignored. When disabled, no non-dr-attract-traffic, the designated router value is honored.
no non-dr-attract-traffic
This command enables access to the context to configure the rendezvous point (RP) ) of a PIM protocol instance.
An Nokia PIM router acting as an RP must respond to a PIM register message specifying an SSM multicast group address by sending to the first hop router stop register message(s). It does not build an (S, G) shortest path tree toward the first hop router. An SSM multicast group address can be either from the SSM default range of 232/8 or from a multicast group address range that was explicitly configured for SSM.
rp enabled when PIM is enabled.
This command configures a PIM anycast protocol instance for the RP being configured. Anycast enables fast convergence when a PIM RP router fails by allowing receivers and sources to rendezvous at the closest RP.
The no form of the command removes the anycast instance from the configuration.
n/a
This command configures a peer in the anycast RP-set. The address identifies the address used by the other node as the RP candidate address for the same multicast group address range as configured on this node.
This is a manual procedure. Caution should be taken to produce a consistent configuration of an RP-set for a given multicast group address range. The priority should be identical on each node and be a higher value than any other configured RP candidate that is not a member of this RP-set.
Although there is no set maximum of addresses that can be configured in an RP-set, up to 15 multicast addresses is recommended.
The no form of the command removes an entry from the list.
n/a
This command enables auto-RP protocol in discovery mode. In discovery mode, RP-mapping and RP-candidate messages are received and forwarded to downstream nodes. RP-mapping messages are received locally to learn about availability of RP nodes present in the network.
Either bsr-candidate for IPv4 or auto-rp-discovery can be configured; the two mechanisms cannot be enabled together. bsr-candidate for IPv6 and auto-rp-discovery for IPv4 can be enabled together. auto-rp-discovery cannot be enabled together with mdt-type sender-only or mdt-type receiver-only, or wildcard-spmsi configurations.
The no form of the command disables auto-RP.
Note: Chassis mode D or higher must be enabled for auto-rp-discovery. |
no auto-rp-discovery
This command exports policies to control the flow of bootstrap messages from the RP. Up to five policies can be defined.
The no form of this command removes the specified policy names from the configuration.
n/a
This command imports policies to control the flow of bootstrap messages into the RP. Up to five policies can be defined.
The no form of this command removes the specified policy names from the configuration.
n/a
This command enables the context to configure Candidate Bootstrap (BSR) parameters.
Either bsr-candidate for IPv4 or auto-rp-discovery can be configured; the two mechanisms cannot be enabled together. bsr-candidate for IPv6 and auto-rp-discovery for IPv4 can be enabled together.
The no form of the command disables BSR.
no bsr-candidate
This command configures a static bootstrap or rendezvous point (RP) as long as the source is not directly attached to this router.
Use the no form of this command to remove the static RP from the configuration.
No IP address is specified.
This command configures a static bootstrap or rendezvous point (RP) as long as the source is not directly attached to this router.
Use the no form of this command to remove the static RP from the configuration.
No IP address is specified.
ipv6-address | : x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x [0 to FFFF]H | |
d [0 to 255]D |
This command is used to configure the length of a mask that is to be combined with the group address before the hash function is called. All groups with the same hash map to the same RP. For example, if this value is 24, only the first 24 bits of the group addresses matter. This mechanism is used to map one group or multiple groups to an RP.
30
This command is used to configure the length of a mask that is to be combined with the group address before the hash function is called. All groups with the same hash map to the same RP. For example, if this value is 24, only the first 24 bits of the group addresses matter. This mechanism is used to map one group or multiple groups to an RP.
126
This command defines the priority used to become the rendezvous point (RP). The higher the priority value the more likely that this router becomes the RP. If there is a tie, the router with the highest IP address is elected.
This command enables access to the context to configure the rendezvous point (RP) of a PIM IPv6 protocol instance.
A Nokia IPv6 PIM router acting as an RP must respond to an IPv6 PIM register message specifying an SSM multicast group address by sending to the first hop router stop register message(s). It does not build an (S, G) shortest path tree toward the first hop router. An SSM multicast group address can be either from the SSM default range or from a multicast group address range that was explicitly configured for SSM.
ipv6 RP enabled when IPv6 PIM is enabled.
This command configures an IPv6 PIM anycast protocol instance for the RP being configured. Anycast enables fast convergence when a PIM RP router fails by allowing receivers and sources to rendezvous at the closest RP.
The no form of the command removes the anycast instance from the configuration.
n/a
ipv6-address | : x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x [0 to FFFF]H | |
d [0 to 255]D |
This command configures an IPv6 peer in the anycast rp-set. The address identifies the address used by the other node as the RP candidacy address for the same multicast group address range as configured on this node.
This is a manual procedure. Caution should be taken to produce a consistent configuration of an RP- set for a given multicast group address range. The priority should be identical on each node and be a higher value than any other configured RP candidate that is not a member of this rp-set.
Although there is no set maximum of addresses that can be configured in an rp-set, up to 15 multicast addresses is recommended.
The no form of the command removes an entry from the list.
n/a
ipv6-address | : x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x [0 to FFFF]H | |
d [0 to 255]D |
This command enables context to configure IPv6 embedded RP parameters.
This command configures the group address or range of group addresses for which this router can be the rendezvous point (RP).
Use the no form of this command to remove the group address or range of group addresses for which this router can be the RP from the configuration.
n/a
ipv6-address | : x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x [0 to FFFF]H | |
d [0 to 255]D | |
prefix-length | [8 to 128] // for embedded-rp |
prefix-length | [16 to 128] // for rp-candidate |
The group-prefix for a static-rp defines a range of multicast-ip-addresses for which this static RP is applicable.
The no form of the command removes the criterion.
n/a
grp-ipv6-address | : x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x [0 to FFFF]H | |
d [0 to 255]D | |
prefix-length | [8 to 128] |
This command enables the context to configure the candidate rendezvous point (RP) parameters.
enabled when PIM is enabled
This command configures the group address or range of group addresses for which this router can be the rendezvous point (RP).
Use the no form of this command to remove the group address or range of group addresses for which this router can be the RP from the configuration.
n/a
Use this command to define the length of time neighboring router consider this router to be up.
Use the no form of this command to revert to the default value.
150
This command defines the priority used to become the rendezvous point (RP). The higher the priority value, the more likely that this router will become the RP.
Use the no form of this command to revert to the default value.
1
This command enables access to the context to configure a static rendezvous point (RP) of a PIM-SM protocol instance.
n/a
This command configures the static rendezvous point (RP) address.
The no form of this command removes the static RP entry from the configuration.
n/a
The group-prefix for a static-rp defines a range of multicast-ip-addresses for which a certain RP is applicable.
The no form of the command removes the criterion.
n/a
This command changes the precedence of static RP over dyanamically learned Rendezvous Point (RP).
When enabled, the static group-to-RP mappings take precedence over the dynamically learned mappings.
no override
This command configures the sequence of route tables used to find a Reverse Path Forwarding (RPF) interface for a particular multicast route.
By default, only the unicast route table is looked up to calculate RPF interface towards the source/rendezvous point. However, the operator can specify the following:
rtable-u
This command configures a shortest path tree (SPT tree) switchover threshold for a group prefix.
This command specifies whether SSM assert is enabled in compatibility mode for this PIM protocol instance. When enabled, for SSM groups, PIM will consider the SPT bit to be implicitly set to compute the value of CouldAssert (S,G,I) as defined in RFC 4601, Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). When disabled, for SSM groups, PIM will not assume the SPT bit to be set. The SPT bit will be set by Update_SPTbit(S,G,iif) macro defined in RFC 4601.
ssm-assert-compatible-mode disable
This command specifies whether to disable the use of default range (232/8) for SSM so that it can be used by ASM to process (*,G). When enabled, the use of default range is disabled for SSM and it can be used by ASM. When disabled, the SSM default range is enabled.
ssm-default-range-disable
This command enables access to the context to enable a source-specific multicast (SSM) configuration instance.
n/a
Note: The commands described in this section apply only to the 7450 ESS and 7750 SR. |
This command enables the context to configure PPPoE parameters.
This command enables the context to configure the PPPoE-to-DHCP options.
This command enables the original VPLS SAP to be included in the circuit-id option to send to the DHCP server (in case this interface is connected to a VPLS by a CCA MDA).
The no form of the command disables the feature.
no ccag-use-origin-sap
This command configures the local user database to use for PPP Challenge-Handshake Authentication Protocol/Password Authentication Protocol (PAP/CHAP) authentication.
If an authentication policy is also configured, pppoe-access-method must be set to none in this authentication policy to use the local user database (in that case RADIUS authentication will not be used for PPPoE hosts).
This command associates a PPPoE policy on this interface.
default
This command specifies the number of PPPoE hosts per SAP allowed for this group-interface.
1
This command specifies the number of PPPoE hosts allowed for this group interface.
1
This command enables a Multicast Source Discovery Protocol (MSDP) instance. When an MSDP instance is created, the protocol is enabled. To start or suspend execution of the MSDP protocol without affecting the configuration, use the [no] shutdown command.
For the MSDP protocol to function, at least one peer must be configured.
When MSDP is configured and started, an appropriate event message should be generated.
When the no form of the command is executed, all sessions must be terminated and an appropriate event message should be generated.
When all peering sessions are terminated, an event message per peer is not required.
The no form of the command deletes the MSDP protocol instance, removing all associated configuration parameters.
no msdp
This option controls the maximum number of active source messages that will be accepted by Multicast Source Discovery Protocol (MSDP), effectively controlling the number of active sources that can be stored on the system.
The no form of this command reverts the number of source message limit to default operation.
No limit is placed on the number of source active records.
This command configures a rendezvous point (RP) using Multicast Source Discovery Protocol (MSDP) to encapsulate multicast data received in MSDP register messages inside forwarded MSDP source-active messages.
data-encapsulation
This command specifies the policies to export source active state from the source active list into Multicast Source Discovery Protocol (MSDP).
If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple export commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.
The no form of the command removes all policies from the configuration.
No export policies are applied and all SA entries are announced.
If you configure an export policy at the global level, each individual peer inherits the global policy. If you configure an export policy at the group level, each individual peer in a group inherits the group’s policy. If you configure an export policy at the peer level, then policy only applies to the peer where it is configured.
This command enables access to the context to create or modify a Multicast Source Discovery Protocol (MSDP) group. To configure multiple MSDP groups, include multiple group statements.
By default, the group’s options are inherited from the global MSDP options. To override these global options, group-specific options within the group statement can be configured.
If the group name provided is already configured then this command only provides the context to configure the options pertaining to this group.
If the group name provided is not already configured, then the group name must be created and the context to configure the parameters pertaining to the group should be provided. In this case, the $ prompt to indicate that a new entity (group) is being created should be used.
For a group to be of use, at least one peer must be configured.
no group
This command specifies the policies to import source active state from Multicast Source Discovery Protocol (MSDP) into source active list.
If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple import commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.
If you configure an import policy at the global level, each individual peer inherits the global policy.
If you configure an import policy at the group level, each individual peer in a group inherits the group’s policy.
If you configure an import policy at the peer level, then policy only applies to the peer where it is configured.
The no form of the command removes all policies from the configuration.
No import policies are applied and all source active messages are allowed.
This command configures the local end of a Multicast Source Discovery Protocol (MSDP) session. For MSDP to function, at least one peer must be configured. When configuring a peer, you must include this local-address command to configure the local end of the MSDP session. This address must be present on the node and is used to validate incoming connections to the peer and to establish connections to the remote peer.
If the user enters this command, then the address provided is validated and will be used as the local address for MSDP peers from that point. If a subsequent local-address command is entered, it will replace the existing configuration and existing sessions will be terminated.
Similarly, when the no form of this command is entered, the existing local-address will be removed from the configuration and the existing sessions will be terminated.
Whenever a session is terminated, all information pertaining to and learned from that peer will be removed.
Whenever a new peering session is created or a peering session is lost, an event message should be generated.
The no form of this command removes the local-address from the configuration.
No local address is configured.
This command configures groups of peers in a full mesh topology to limit excessive flooding of source-active messages to neighboring peers.
Multicast Source Discovery Protocol (MSDP) peers can be configured grouped in a full-mesh topology that prevents excessive flooding of source-active messages to neighboring peers.
In a meshed configuration, all members of the group must have a peer connection with every other mesh group member. If this rule is not adhered to, then unpredictable results may occur.
mode standard (non-meshed)
This command configures peer parameters. Multicast Source Discovery Protocol (MSDP) must have at least one peer configured. A peer is defined by configuring a local-address that can be used by this node to set up a peering session and the address of a remote MSDP router, It is the address of this remote peer that is configured in this command and it identifies the remote MSDP router address.
After peer relationships are established, the MSDP peers exchange messages to advertise active multicast sources. It may be required to have multiple peering sessions in which case multiple peer statements should be included in the configurations.
By default, the options applied to a peer are inherited from the global or group-level. To override these inherited options, include peer-specific options within the peer statement.
If the peer address provided is already a configured peer, then this command only provides the context to configure the parameters pertaining to this peer.
If the peer address provided is not already a configured peer, then the peer instance must be created and the context to configure the parameters pertaining to this peer should be provided. In this case, the $ prompt to indicate that a new entity (peer) is being created should be used.
The peer address provided will be validated and, if valid, will be used as the remote address for an MSDP peering session.
When the no form of this command is entered, the existing peering address will be removed from the configuration and the existing session will be terminated. Whenever a session is terminated, all source active information pertaining to and learned from that peer will be removed. Whenever a new peering session is created or a peering session is lost, an event message should be generated.
At least one peer must be configured for MSDP to function.
n/a
This command limits the number of Multicast Source Discovery Protocol (MSDP) messages that are read from the TCP session. It is possible that an MSDP/ RP router may receive a large number of MSDP protocol message packets in a particular source active message.
After the number of MSDP packets (including source active messages) defined in the threshold have been processed, the rate of all other MSDP packets is rate limited by no longer accepting messages from the TCP session until the time (seconds) has elapsed.
The no form of this command reverts this active-source limit to default operation.
No limit is placed on the number of MSDP and source active limit messages will be accepted.
This command configures the sequence of route tables used to find a Reverse Path Forwarding (RPF) interface for a particular multicast route.
By default, only the unicast route table is looked up to calculate RPF interface towards the source/rendezvous point. However, the operator can specify the following:
rtable-u
This command configures the value for the SA entries in the cache. If these entries are not refreshed within the timeout value, they are removed from the cache. Normally, the entries are refreshed at least once a minute. But under high load with many of MSDP peers, the refresh cycle could be incomplete. A higher timeout value (more then 90) could be useful to prevent instabilities in the MSDP cache.
90
This command limits the number of active source messages the router accepts from sources in the specified address range.
If the prefix and mask provided is already a configured then this command only provides the context to configure the parameters pertaining to this active source-message filter.
If the prefix and mask provided is not already a configured, then the source node instance must be created and the context to configure the parameters pertaining to this node should be provided. In this case, the $ prompt to indicate that a new entity (source) is being created should be used.
The no form of this message removes the source active rate limiter for this source address range.
n/a. The source active msdp messages are not rate limited based on the source address range.
This command configures a Message Digest 5 (MD5) authentication key to be used with a specific Multicast Source Discovery Protocol (MSDP) peering session. The authentication key must be configured per peer as such no global or group configuration is possible.
Authentication-key. All MSDP messages are accepted and the MD5 signature option authentication key is disabled.
This is useful when a user must configure the parameter, but, for security purposes, the actual unencrypted key value is not provided.
Using the default peer mechanism, a peer can be selected as the default Multicast Source Discovery Protocol (MSDP) peer. As a result, all source-active messages from the peer will be accepted without the usual peer-reverse-path-forwarding (RPF) check.
The MSDP peer-RPF check is different from the normal multicast RPF checks. The peer-RPF check is used to stop source-active messages from looping. A router validates source-active messages originated from other routers in a deterministic fashion.
A set of rules is applied in order to validate received source-active messages, and the first rule that applies determines the peer-RPF neighbor. All source-active messages from other routers are rejected. The rules applied to source-active messages originating at Router S received at Router R from Router N are as follows:
No default peer is established and all active source messages must be RPF checked.
This command enables the context to configure Multicast Listener Discovery (MLD) parameters.
The no form of the command disables MLD.
no mld
This command enables the context to configure an Multicast Listener Discovery (MLD) interface. The interface is a local identifier of the network interface on which reception of the specified multicast address is to be enabled or disabled.
The no form of the command deletes the MLD interface. The shutdown command in the config>router>mld>interface context can be used to disable an interface without removing the configuration for the interface.
no interface — No interfaces are defined.
If the IP interface name does not exist or does not have an IP address configured an error message will be returned.
If the IP interface exists in a different area it will be moved to this area.
This command enables router alert checking for MLD messages received on this interface.
The no form of the command disables the router alert checking.
n/a
This command specifies the import route policy to be used for determining which membership reports are accepted by the router. Route policies are configured in the config>router>policy-options context.
When an import policy is not specified, all the MLD reports are accepted.
The no form of the command removes the policy association from the MLD instance.
no import — No import policy specified.
This command specifies the maximum number of groups for which MLD can have local receiver information based on received MLD reports on this interface. When this configuration is changed dynamically to a value lower than the currently accepted number of groups, the groups that are already accepted are not deleted. Only new groups will not be allowed.
0, no limit to the number of groups.
This command specifies the frequency that the querier router transmits general host-query messages. The host-query messages solicit group membership information and are sent to the all-systems multicast group address, 224.0.0.1.
125
This command configures the frequency at which the querier sends group-specific query messages including messages sent in response to leave-group messages. The lower the interval, the faster the detection of the loss of the last member of a group.
1
This command specifies how long the querier router waits to receive a response to a host-query message from a host.
10
This command tests multicast forwarding on an interface without a receiver host. When enabled, data is forwarded to an interface without receiving membership reports from host members.
n/a
This command enables the context to add a static multicast group either as a (*,G) or one or more (S,G) records. Use MLD static group memberships to test multicast forwarding without a receiver host. When MLD static groups are enabled, data is forwarded to an interface without receiving membership reports from host members.
When static MLD group entries on point-to-point links that connect routers to a rendezvous point (RP) are configured, the static MLD group entries do not generate join messages toward the RP.
The no form of the command removes the IPv6 address from the configuration.
n/a
This command specifies an IPv6 unicast address that sends data on an interface. This enables a multicast receiver host to signal a router the group to receive multicast traffic from, and from the sources that the traffic is expected.
The source command is mutually exclusive with the specification of individual sources for the same group.
The source command, in combination with the group, is used to create a specific (S,G) static group entry.
The no form of the command removes the source from the configuration.
n/a
This command adds a static (*,G) entry. This command can only be enabled if no existing source addresses for this group are specified.
Use the no form of the command to remove the starg entry from the configuration.
n/a
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.
1
This command configures the robust count. The robust-count variable allows tuning for the expected packet loss on a subnet. If a subnet anticipates losses, the robust-count variable can be increased.
2
This command enables the context to configure group ranges which are translated to SSM (S,G) entries. If the static entry needs to be created, it has to be translated from a IGMPv1 IGMPv2 request to a Source Specific Multicast (SSM) join. An SSM translate source can only be added if the starg command is not enabled. An error message is generated if you try to configure the source command with starg command enabled.
This command is used to configure group ranges which are translated to SSM (S,G) entries.
This command specifies the source IP address for the group range. Whenever a (*,G) report is received in the range specified by grp-range start and end parameters, it is translated to an (S,G) report with the value of this object as the source address.
This command enables the RIP protocol on the given VPRN IP interface.
The no form of the command disables the RIP protocol from the given VPRN IP interface.
no rip
This command creates the context to configure the RIPng protocol instance.
When a RIPng instance is created, the protocol is enabled by default. To start or suspend execution of the RIP protocol without affecting the configuration, use the [no] shutdown command.
The no form of the command deletes the RIP protocol instance removing all associated configuration parameters.
no ripng — No RIPng protocol instance defined.
This command sets the authentication password to be passed between RIP neighbors.
The authentication type and authentication key must match exactly for the RIP message to be considered authentic and processed.
The no form of the command removes the authentication password from the configuration and disables authentication.
no authentication-key — Authentication is disabled and the authentication password is empty.
This is useful when a user must configure the parameter, but, for security purposes, the actual unencrypted key value is not provided.
This command defines the type of authentication to be used between RIP neighbors. The type and password must match exactly for the RIP message to be considered authentic and processed.
The no form of the command removes the authentication type from the configuration and effectively disables authentication.
no authentication-type
This command enables checking for zero values in fields specified to be zero by the RIPv1 and RIPv2 specifications.
The no form of the command disables this check and allows the receipt of RIP messages even if the mandatory zero fields are non-zero.
no check-zero
This command enables the use of split-horizon. RIP uses split-horizon with poison-reverse to protect from such problems as “counting to infinity”. Split-horizon with poison reverse means that routes learned from a neighbor through a given interface are advertised in updates out of the same interface but with a metric of 16 (infinity).
The split-horizon disable command enables split horizon without poison reverse. This allows the routes to be re-advertised on interfaces other than the interface that learned the route, with the advertised metric equaling an increment of the metric-in value.
This configuration parameter can be set at three levels: global level (applies to all groups and neighbor interfaces), group level (applies to all neighbor interfaces in the group) or neighbor level (only applies to the specified neighbor interface). The most specific value is used. In particular if no value is set (no split-horizon), the setting from the less specific level is inherited by the lower level.
The no form of the command disables split horizon command which allows the lower level to inherit the setting from an upper level.
enabled
This command specifies the export route policies used to determine which routes are exported to RIP. If no export policy is specified, non-RIP routes will not be exported from the routing table manager to RIP; RIP-learned routes will be exported to RIP neighbors.
If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple export commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.
The no form of the command removes all policies from the configuration.
no export — No export route policies specified.
This command configures the maximum number of routes (prefixes) that can be exported into RIP from the route table.
The no form of the command removes the parameters from the configuration.
no export-limit
This command configures import route policies to determine routes that will be accepted from RIP neighbors. If no import policy is specified, RIP accepts all routes from configured RIP neighbors. Import policies can be used to limit or modify the routes accepted and their corresponding parameters and metrics.
If multiple policy names are specified, the policies are evaluated in the order that they are specified. The first policy that matches is applied. If multiple import commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.
The no form of the command removes all policies from the configuration.
no import — No import route policies specified.
This command sets the maximum number of routes per RIP update message.
The no form of the command resets the maximum number of routes back to the default of 25.
no message-size
This command sets the metric added to routes that were received from a RIP neighbor.
The no form of the command reverts the metric value back to the default.
no metric-in
This command sets the metric added to routes that were exported into RIP and advertised to RIP neighbors.
The no form of the command removes the command from the config and resets the metric-in value back to the default.
no metric-out
This command sets the route preference assigned to RIP routes. This value can be overridden by route policies.
The no form of the command resets the preference to the default.
no preference
This command enables the BGP MED to be used to configure the RIP metric at the BGP to RIP transition on egress routers. BGP always configures the BGP MED to the RIP metric at the ingress router. When propagate-metric is configured, the RIP metric at egress routers is configured as the BGP MED attribute added to the optional value configured with the metric-out command.
no propagate-metric
The RIP metric is configured to the optional value configured with the metric-out command plus 1.
This command configures the type(s) of RIP updates that will be accepted and processed.
If both or version-2 is specified, the RIP instance listens for and accepts packets sent to the broadcast and multicast (224.0.0.9) addresses.
If version-1 is specified, the router only listens for and accepts packets sent to the broadcast address.
This control can be issued at the global, group or interface level. The default behavior accepts and processes both RIPv1 and RIPv2 messages.
The no form of the command resets the type of messages accepted to both.
no receive — Accepts both formats.
This command specifies the type of RIP messages sent to RIP neighbors. This control can be issued at the global, group or interface level. The default behavior sends RIPv2 messages with the multicast (224.0.0.9) destination address.
If version-1 is specified, the router only listens for and accepts packets sent to the broadcast address.
The no form of this command resets the type of messages sent back to the default value.
no send — sends RIPv2 to the broadcast address
This command sets the values for the update, timeout, and flush timers.
The no form of the command resets all timers to their default values of 30, 180, and 120 seconds respectively.
no timers
This command configures the unicast IPv6 address, RIPng updates messages will be sent to if the RIPng send command is set to send unicast.
Multiple unicast-address entries can be configured, in which case unicast messages will be sent to each configured unicast IPv6 address.
The no form of the command deletes the specified IPv6 unicast address from the configuration.
ipv6-address — IPv6 unicast address to which unicast RIPng updates should be sent.
This command creates a context for configuring a RIP group of neighbors. RIP groups are a way of logically associating RIP neighbor interfaces to facilitate a common configuration for RIP interfaces.
The no form of the command deletes the RIP neighbor interface group. Deleting the group will also remove the RIP configuration of all the neighbor interfaces currently assigned to this group.
no group — No group of RIP neighbor interfaces defined
This command creates a context for configuring a RIP neighbor interface.
By default, interfaces are not activated in any interior gateway protocol such as RIP unless explicitly configured.
The no form of the command deletes the RIP interface configuration for this interface. The shutdown command in the config>router>rip>group group-name>neighbor ip-int-name context can be used to disable an interface without removing the configuration for the interface.
no neighbor — No RIP interfaces defined.
If the IP interface name does not exist or does not have an IP address configured an error message will be returned.
This command binds a service to an existing Service Distribution Point (SDP). A spoke SDP is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not transmitted on the port it was received.
The SDP has an operational state which determines the operational state of the SDP within the service. For example, if the SDP is administratively or operationally down, the SDP for the service will be down.
The SDP must already be defined in the config>service>sdp context in order to associate an SDP with a VPRN service. If the SDP-ID is not already configured, an error message is generated. If the SDP-ID does exist, a binding between that SDP-ID and the service is created.
SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a service, no far-end devices can participate in the service.
The no form of this command removes the SDP binding from the service. The SDP configuration is not affected; only the binding of the SDP to a service. Once removed, no packets are forwarded to the far-end router.
No SDP-ID is bound to a service.
This command enables the configuration of static pseudowire status signaling on a spoke-SDP for which signaling for its SDP is set to OFF.
A control-channel-status no shutdown is allowed only if all of the following are true:
The no form of this command removes control channel status signaling from a spoke-SDP. It can only be removed if control channel status is shut down.
no control-channel-status
This command enables the acknowledgment of control channel status messages. By default, no acknowledgment packets are sent.
This command configures the refresh timer for control channel status signaling packets. By default, no refresh packets are sent.
no refresh-timer
This command configures the control channel status request mechanism. When it is configured, control channel status request procedures are used. These augment the procedures for control channel status messaging from RFC 6478. This command is mutually exclusive with a non-zero refresh-timer value.
The control word command provides the option to add a control word as part of the packet encapsulation for pseudowire types for which the control word is optional. These are Ethernet pseudowires (Epipe). ATM N:1 cell mode pseudowires (apipe vc-types atm-vcc and atm-vpc) and VT pseudowire (apipe vc-type atm-cell).
The configuration for the two directions of the pseudowire must match because the control word negotiation procedures described in Section 6.2 of RFC 4447 are not supported. The C-bit in the pseudowire FEC sent in the label mapping message is set to 1 when the control word is enabled. Otherwise, it is set to 0.
The service will only come up if the same C-bit value is signaled in both directions. If a spoke-sdp is configured to use the control word but the node receives a label mapping message with a C-bit clear, the node releases the label with the an “Illegal C-bit” status code as per Section 6.1 of RFC 4447. As soon as the user also enabled the control the remote peer, the remote peer will withdraw its original label and will send a label mapping with the C-bit set to 1 and the VLL service will be up in both nodes. The control word must be enabled to allow MPLS-TP OAM to be used on a static spoke-sdp in a apipe, epipe and cpipe service.
This command enables the context to configure an MPLS-TP Pseudowire Path Identifier for a spoke-sdp. All elements of the PW path ID must be configured in order to enable a spoke-sdp with a PW path ID.
For an IES or VPRN spoke-sdp, the pw-path-id is only valid for ethernet spoke-sdps.
The pw-path-id is only configurable if all of the following is true:
The no form of the command deletes the PW path ID.
no pw-path-id
This command configures the attachment group identifier for an MPLS-TP PW.
This command configures the source individual attachment identifier (SAII) for an MPLS-TP spoke-sdp. If this is configured on a spoke-sdp for which vc-switching is also configured (for example, it is at an S-PE), then the values must match those of the taii-type2 of the mate spoke-sdp.
This command configures the target individual attachment identifier (TAII) for an MPLS-TP spoke-sdp. If this is configured on a spoke-sdp for which vc-switching is also configured (for example, it is at an S-PE), then the values must match those of the saii-type2 of the mate spoke-sdp.
This command binds a service to an existing Service Distribution Point (SDP).
A spoke SDP is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not transmitted on the port it was received.
The SDP has an operational state which determines the operational state of the SDP within the service. For example, if the SDP is administratively or operationally down, the SDP for the service will be down.
The SDP must already be defined in the config>service>sdp context in order to associate an SDP with a service. If the SDP-ID is not already configured, an error message is generated. If the SDP-ID does exist, a binding between that SDP-ID and the service is created.
SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a service, no far-end devices can participate in the service.
Class-based forwarding is not supported on a spoke SDP used for termination on an IES or VPRN services. All packets are forwarded over the default LSP.
The no form of this command removes the SDP binding from the service. The SDP configuration is not affected; only the binding of the SDP to a service. Once removed, no packets are forwarded to the far-end router.
n/a
This command configures an SDP context.
This command enables or disables the use of entropy labels for spoke SDPs on a VPRN.
If entropy-label is configured, the entropy label and ELI are inserted in packets for which at least one LSP in the stack for the far-end of the tunnel used by the service has advertised entropy-label-capability. If the tunnel is RSVP type, entropy-label can also be controlled under the config>router>mpls or config>router>mpls>lsp contexts.
The entropy label and the hash label features are mutually exclusive. The entropy label cannot be configured on a spoke-sdp or service where the hash label feature has already been configured.
no entropy-label
This command enables the use of the hash label on a VLL, VPLS, or VPRN service bound to any MPLS-type encapsulated SDP as well as to a VPRN service using auto-bind-tunnel with the resolution-filter configured as any MPLS tunnel type. This feature is not supported on a service bound to a GRE SDP or for a VPRN service using the autobind mode with the gre option.
When this feature is enabled, the ingress data path is modified such that the result of the hash on the packet header is communicated to the egress data path for use as the value of the label field of the hash label. The egress data path appends the hash label at the bottom of the stack (BoS) and sets the S-bit to 1 to indicate that.
In order to allow for applications whereby the egress LER infers the presence of the Hash Label implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the hash is set before copying into the Hash Label. This means that the value of the hash label will always be in the range [524,288 - 1,048,575] and will not overlap with the signaled/static LSP and signaled/static service label ranges. This also guarantees that the hash label will not match a value in the reserved label range.
The (unmodified) result of the hash continues to be used for the purpose of ECMP and LAG spraying of packets locally on the ingress LER. For VLL services, the result of the hash is overwritten and the ECMP and LAG spraying will be based on service-id when ingress SAP shared queuing is not enabled. However, the hash label will still reflect the result of the hash such that an LSR can use it to perform fine grained load balancing of VLL pseudowire packets.
Packets that are generated in CPM and forwarded labeled within the context of a service (for example, OAM packets) must also include a Hash Label at the BoS and set the S-bit accordingly.
The TTL of the hash label is set to a value of 0.
The no form of this command disables the use of the hash label.
no hash-label
This command configures the SDP context.
This command is used to redirect pseudowire packets to an ingress forwarding plane queue-group for the purpose of rate-limiting.
The ingress pseudowire rate-limiting feature uses a policer in queue-group provisioning model. This model allows the mapping of one or more pseudowires to the same instance of policers, which are defined in a queue-group template.
Operationally, the provisioning model in the case of the ingress pseudowire shaping feature consists of the following steps:
The following are the constraints and rules of this provisioning model when used in the ingress pseudowire rate-limiting feature:
When a pseudowire is redirected to use a policer queue-group, the classification of the packet for the purpose of FC and profile determination is performed according to default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the pseudowire. This is true regardless of whether an instance of the named policer queue-group exists on the ingress FP on which the pseudowire packet is received. The user can apply a QoS filter matching the dot1p in the VLAN tag corresponding to the Ethernet port encapsulation, the EXP in the outer label when the tunnel is an LSP, the DSCP in the IP header if the tunnel encapsulation is GRE, and the DSCP in the payload IP header if the user enabled the ler-use-dscp option and the pseudowire terminates in IES or VPRN service (spoke-interface).
When the policer queue-group name the pseudowire is redirected does not exist, the redirection command is failed. In this case, the packet classification is performed according to default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the network IP interface on which the pseudowire packet is received.
The no version of this command removes the redirection of the pseudowire to the queue-group.
This command configures the egress VC label.
This command configures the ingress VC label.
This command enables the context to configure egress network filter policies for the interface.
This command associates an IP filter policy with an ingress or egress Service Access Point (SAP) or IP interface. An IP filter policy can be associated with spoke SDPs. Filter policies control the forwarding and dropping of packets based on IP or MAC matching criteria.
The filter command is used to associate a filter policy with a specified ip-filter-id with an ingress or egress SAP. The ip-filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation will fail and an error message returned.
In general, filters applied to SAPs (ingress or egress) apply to all packets on the SAP. One exception is non-IP packets are not applied to IP match criteria, so the default action in the filter policy applies to these packets.
The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.
This command is used to redirect pseudowire packets to an egress port queue-group for the purpose of shaping.
The egress pseudowire shaping provisioning model allows the mapping of one ore more pseudowires to the same instance of queues, or policers and queues, which are defined in the queue-group template.
Operationally, the provisioning model consists of the following steps:
One or more spoke-SPDs can have their FCs redirected to use queues only or queues and policers in the same queue-group instance.
The following are the constraints and rules of this provisioning model:
When the queue-group name the pseudowire is redirected to exists and the redirection succeeds, the marking of the packet DEI/dot1p/DSCP and the tunnel DEI/dot1p/DSCP/EXP is performed; according to the relevant mappings of the (FC, profile) in the egress context of the network QoS policy applied to the pseudowire. This is true regardless, whether an instance of the queue-group exists or not on the egress port to which the pseudowire packet is forwarded. If the packet profile value changed due to egress child policer CIR profiling, the new profile value is used to mark the packet DEI/dot1p and the tunnel DEI/dot1p/EXP, and the DSCP/prec will be remarked if enable-dscp-prec-marking is enabled under the policer.
When the queue-group name the pseudowire is redirected does not exist, the redirection command is failed. In this case, the marking of the packet DEI/dot1p/DSCP and the tunnel DEI/dot1p/DSCP/EXP fields is performed according to the relevant commands in the egress context of the network QoS policy applied to the network IP interface to which the pseudowire packet is forwarded.
The no version of this command removes the redirection of the pseudowire to the queue-group.
This command configure a Threat Management Service interface.
The no form of the command removes the interface name from the configuration.
service-id: 1 to 2148007978 svc-name: an existing service name up to 64 characters in length
This command assigns an IP address/IP subnet/broadcast address to the TMS instance for communications between Arbor CP collectors/managers and the TMS instance operating within the Service Router.
The no form of the command removes the IP address information from the interface configuration.
ip-address[/mask] | ip-address a.b.c.d |
mask | 32 |
netmask | a.b.c.d (all 1 bits) |
This command configures a description for the interface.
The no form of the command removes the description from the interface configuration.
This command configures IPv6 for a threat-management service interface.
The no form of the command removes the IP address information from the interface configuration.
This command configures a password for the user.
The no form of the command removes the password.
password | key1 delimvalue1 key2 delim value2 ... | |
delim is one of the following: | ||
'=' value is unencrypted and remain unencrypted | ||
':' value is unencrypted and to be encrypted | ||
'%' value is encrypted and remain encrypted |
This command specifies a chassis slot and MDA to bind the interface to a physical port.
The no form of the command removes the MDA ID from the interface configuration.
<slot>/<mda> | slot | [1 to 10] |
mda | [1 to 2] |
This command enables the context to configure RADIUS proxy commands.
This command configures the name of this RADIUS proxy server.
This command enables the context to configure caching parameters.
The no form of the command disables caching.
This command configures cache key parameters.
The no form of the command removes the parameters from the configuration.
no key
In order to generate the key associated with a RADIUS Access-Accept message, the system uses the attribute of the type specified by the value of tmnxRadProxSrvCacheKeyAttrType, within the associated RADIUS message of the type specified by the value of tmnxRadProxSrvCacheKeyPktType.
In order to generate the key associated with a RADIUS Access-Accept message, the system uses the attribute of the type specified by the value of tmnxRadProxSrvCacheKeyAttrType, within the associated RADIUS message of the type specified by the value of tmnxRadProxSrvCacheKeyPktType.
If the value of tmnxRadProxSrvCacheKeyVendorId is equal to zero, the attribute type specified by tmnxRadProxSrvCacheKeyAttrType must be used if it appears outside of a Vendor-Specific attribute.
If the value of tmnxRadProxSrvCacheKeyVendorId is not equal to zero, the attribute type specified by tmnxRadProxSrvCacheKeyAttrType must be used if it appears as a sub-attribute within a Vendor-Specific attribute with Vendor-Id equal to the value of tmnxRadProxSrvCacheKeyVendorId.
This command configures the timeout, in seconds, after which an entry in the cache will expire.
The no form of the command reverts to the default.
300
This command specifies which RADIUS accounting packets have impact on the cache of this RADIUS proxy server. Use it to configure what RADIUS accounting packets have impact on the cache.
The no form of the command reverts to the default.
no track-accounting
This command configures the name of the default RADIUS server policy associated with this RADIUS proxy server for accounting purposes.
This default policy is used if no policy can be derived from the user name.
The no form of the command removes the policy from the configuration.
This command configures the name of the default RADIUS server policy associated with this RADIUS proxy server for authentication purposes.
This default policy is used if no policy can be derived from the user name.
The no form of the command removes the policy from the configuration.
This command associates an interface to the proxy server.
The no form of the command removes the interface name from the proxy server configuration.
n/a
This command configures how to construct the key for load-balancing RADIUS messages between RADIUS servers.
load-balance-key
This common specifies a python policy. Python policies are configured in the config>python> python-policy name context.
This command configures the secret key associated with the RADIUS server.
The no form of the command removes the key from the configuration.
This command specifies if this RADIUS proxy server itself responds with an Accounting-Response message to each received Accounting-Request instead of proxying them to a configured RADIUS server.
The no form of the command disables the accounting response messages.
disabled
This command configures username-to-RADIUS-server-policy associations.
The no form of the command removes the associations from the configuration.
n/a
This command enables the context to configure RADIUS server parameters.
This command configures RADIUS server parameters.
The no form of the command removes the parameters from the configuration.
This command specifies if this RADIUS server is allowed to process Change of Authorization messages.
This command specifies the RADIUS script policy used to change the RADIUS attributes of the Change-of-Authorization messages.
The no form of the command removes the script policy from the configuration.
n/a
This command specifies the limit of the number of pending RADIUS authentication requests.
4096
This command enters the configuration context of web portal protocol (WPP) under router or vprn.
The no form of this command removes configuration under wpp.
no wpp
This command enters the configuration context of web portal server.
This command either creates a new web portal server or enters an existing web portal server.
no portal
This command cause system stops receiving web portal protocol packet from the web portal server.
shutdown
This command cause system stops receiving web portal protocol packet from all web portal servers defined in the routing instance.
shutdown
This command enters the configuration context of web portal protocol (WPP) under group-interface.
The no form of this command removes configuration under WPP.
no wpp
This command specifies the initial app-profile for the hosts created on the group-interface. This initial app-profile is replaced after hosts pass the web portal authentication.
no initial-app-profile
This command specifies the initial sla-profile for the hosts created on the group-interface. This initial sla-profile is replaced after hosts pass the web portal authentication.
no initial-sla-profile
This command specifies the initial sub-profile for the hosts created on the group-interface. This initial sub-profile will be replaced after hosts pass web portal authentication.
no initial-sub-profile
This command specifies the web portal server that system talks to for the hosts on the group-interface.
no portal
This command enable the behavior that system will restore the initial-sla-profile/initial-sub-profile/initial-aa-profile when hosts disconnects instead of removing them.
restore-disconnected
This command disables web port protocol for the group-interface.
shutdown