8.4. VPRN Services Command Reference

This command creates a text description stored in the configuration file for a configuration context.

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

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.

Default administrative states for services and service entities is described as follows 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.

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 to associate 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 recreated 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. 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 belong to the same customer.

The no form of this 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 shut down and deleted.

This command causes the vrf-export and vrf-target commands to include BGP-VPN routes installed in the VPRN route table. These routes are usually not readvertisable as VPN-IP routes because of split horizon.

When a BGP-VPN route is reexported, the route distinguisher and label values are rewritten according to the configuration of the reexporting VPRN.

Note: This command requires the VPRN context to be shut down and restarted for changes to take effect. This command can be configured only with VPRN loopback interfaces.

Caution: Ensure that routing updates do not loop back to the source when this command is used, otherwise the routes could become unstable.

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

This command enables the context to configure automatic binding of a VPRN service using tunnels to MP-BGP peers.

The user must configure the resolution option to enable auto-bind resolution to tunnels in the TTM. If the resolution option is explicitly set to disabled, auto-binding to tunnels is removed.

If the resolution is set to any, any supported tunnel type in a VPRN context is selected following the TTM preference. If one or more explicit tunnel types are specified using the resolution-filter option, only these tunnel types are selected again following the TTM preference.

The user must set the resolution command 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 (using the configure service vprn spoke-sdp command), 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 enables the context to configure the subset of tunnel types that can be used in the resolution of VPRN prefixes within the automatic binding of VPRN services to tunnels to MP-BGP peers.

The following tunnel types are supported in a VPRN context: RSVP, LDP, and segment routing (SR). The BGP tunnel type is not explicitly configured and is therefore implicit. It is always preferred over any other tunnel type enabled in the auto-bind-tunnel context.

This command specifies the use of LDP tunnel types for the resolution of VPRN prefixes within the automatic binding of VPRN services to tunnels to MP-BGP peers.

When ldp is specified, BGP searches for an LDP LSP with a FEC prefix corresponding to the address of the BGP next hop.

The no form of this command disables the use of LDP tunnel types for the resolution of VPRN prefixes within the automatic binding of VPRN services to tunnels to MP-BGP peers.

This command specifies the use of RSVP tunnel types for the resolution of VPRN prefixes within the automatic binding of VPRN services to tunnels to MP-BGP peers.

When rsvp is specified, BGP searches 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.

The no form of this command disables the use of RSVP tunnel types for the resolution of VPRN prefixes within the automatic binding of VPRN service to tunnels to MP-BGP peers.

This command configures the use of SR-ISIS tunnel types for the resolution of VPRN prefixes within the automatic binding of VPRN service to tunnels to MP-BGP peers.

When this command is specified, an SR tunnel to the BGP next hop is selected in the TTM from the lowest numbered IS-IS instance.

The no form of this command disables the use of SR-ISIS tunnel types for the resolution of VPRN prefixes within the automatic binding of VPRN service to tunnels to MP-BGP peers.

This command configures the use of SR-OSPF tunnel types for the resolution of VPRN prefixes within the automatic binding of VPRN service to tunnels to MP-BGP peers.

When sr-ospf is specified, an SR tunnel to the BGP next hop is selected in the TTM from the lowest numbered OSPF instance.

The no form of this command disables the use of SR-OSPF tunnel types for the resolution of VPRN prefixes within the automatic binding of VPRN service to tunnels to MP-BGP peers.

This command defines the autonomous system (AS) to be used by this VPN routing/forwarding (VRF).

The no form of this command removes the defined AS from this VPRN context.

This command enables only imported BGP-VPN routes from the remote PE to be considered when selecting the primary and backup paths. This command is required to support fast failover of ingress traffic from one remote PE to another remote PE.

Note: 7210 SAS platforms do not consider multiple paths learned from CE BGP peers when selecting primary and backup paths to reach the CE.

This command, in the IP interface context, is used to bind the IP interface to the specified service name.

The system does not attempt to resolve the provided service name until the IP interface is placed into the administratively up state (no shutdown). When the IP interface is administratively up, the system scans the available VPLS services that have the allow-ip-int-binding 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 immediately attempts to resolve the specific name.

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

A VPLS service associated with the specified name that does not have the allow-ip-int-binding flag set, or a non-VPLS service associated with the name, is ignored and is not 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-binding flag is set at the time the name is applied, the VPLS service is automatically resolved to the IP interface if the interface is administratively up or when the interface is placed in the administratively up state.

If the service name is applied to a VPLS service without the allow-ip-int-binding flag set, the system does 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-binding flag set is attached to the VPLS service. Only one IP interface is allowed to attach to a VPLS service context. No error is generated for the remaining non-attached IP interfaces using the service name.

When 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-binding 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.

This command configures a logical IP routing interface for a VPRN. When created, attributes such as 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 IES service ID. The IP interface created is associated with the service core network routing instance and default routing.

Interface names are case sensitive and must be unique within the group of defined IP interfaces defined for config service vprn interface (that is, the network core router instance). 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 if the same IP address and IP address name values are used. Although not recommended, duplicate interface names can exist in different router instances.

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 the IP interface and all the associated configuration. The interface must be administratively shut down before issuing the no interface command.

For IES services, the IP interface must be shut down before the SAP on that interface may be removed.

This command enables the context to define the VPLS routed ip-filter-id optional filter overrides.

This command enables and disables the use of IP DSCP table-based classification to assign forwarding class (FC) and profile on a per-interface ingress basis.

The match-criteria configured in the service ingress policy, which require CAM resources, are ignored. Only meters from the service ingress policy are used (and the meters still require CAM resources). If an IP DSCP classification policy is configured in the VPLS SAP ingress policy, it is not used to assign FC and profile.

The no form of this command disables table-based classification. When disabled, the IP ingress packets within a VPLS service attached to the IP interface use the SAP ingress QoS policy applied to the virtual port used by the packets, when defined.

This command configures an IP DSCP classification policy that is applied to all ingress packets entering the VPLS service. The DSCP classification policy overrides any existing SAP ingress QoS policy applied to SAPs for packets associated with the routing IP interface. The routed override QoS policy is optional, and when it is not defined or removed, the IP routed packets use the existing SAP ingress QoS policy configured on the VPLS virtual port.

The no form of this command removes the IP DSCP classification policy from the ingress IP interface. When removed, the IP ingress routed packets within a VPLS service attached to the IP interface use the SAP ingress QoS policy applied to the virtual port used by the packets, when defined.

This command specifies an IP filter ID that is applied to all ingress packets entering the VPLS service. The filter overrides any existing ingress IP 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 is removed, the IP routed packets use the existing ingress IP filter on the VPLS virtual port.

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

This command enables the context to configure IGMP parameters.

This command enables the context to configure IGMP interface parameters.

This command imports a policy to filter IGMP packets.

The no form of this command removes the policy association from the IGMP instance.

This command enables the IGMP router alert check option.

The no form of this command disables the router alert check.

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 the currently accepted number of sources, the sources that are already accepted are not deleted. Only new sources are not allowed.

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 are not allowed. By default, there is 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.

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.

This command specifies the source address of the multicast group, which is an IPv4 unicast address. By specifying the source address, a multicast receiver host signals to the router that the multicast group only receives multicast traffic from this specific source.

The source command and the specification of individual sources for the same group are mutually exclusive.

The source command, in combination with the group command, is used to create a specific (S,G) static group entry.

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

This command adds a static (*,G) entry. This command can be enabled only if no existing source addresses for this group are specified.

The no form of this command removes the starg entry from the configuration.

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.

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

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

This command configures the frequency that the querier router transmits general host-query messages. The host-query messages solicit group membership information which are sent to the all-systems multicast group address, 224.0.0.1.

This command configures the frequency at which the querier sends group-specific query messages, including messages sent in response to leave-group messages. The shorter the interval, the faster the detection of the loss of the last member of a group.

This command configures how long the querier router waits to receive a response to a host-query message from a host.

This command configures the robust count. The robust-count parameter allows adjusting for the expected packet loss on a subnet. If a subnet anticipates losses, the robust-count can be increased.

This command enables the context to configure group ranges that are translated to SSM (S,G) entries. If the static entry needs to be created, it must be translated from an IGMPv1 or IGMPv2 request to a Source Specific Multicast (SSM) join request. An SSM translate source can be added only when the starg command is not enabled. An error message is generated when attempting to configure the source command while starg command is enabled.

This command configures group ranges that 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 configures the maximum number of remote IPv6 routes that can be held within a VRF context. Local, host, static, and aggregate routes are not counted.

The VPRN service ID must be in a shutdown state before the maximum-ipv6-routes command parameters can be modified.

If the log-only keyword is not specified, and the maximum-ipv6-routes value is set below the existing number of routes in a VRF, the offending RIP peer (if applicable) is brought down (but the VPRN instance remains up). BGP peering remains up, but the exceeding BGP routes are not added to the VRF.

The maximum route threshold can dynamically change to increase the number of supported routes, even when the maximum is already reached. Protocols resubmit the routes that were initially rejected.

The no form of this command disables any limit on the number of routes within a VRF context. Issue the no form of this command only when the VPRN instance is shut down.

This command configures the maximum number of remote routes that can be held within a VRF context. Local, host, static, and aggregate routes are not counted.

The VPRN service ID must be in a shutdown state before maximum-routes command parameters can be modified.

If the log-only parameter is not specified and the maximum-routes value is set below the existing number of routes in a VRF, the offending RIP peer (if applicable) is brought down (but the VPRN instance remains up). BGP peering remains up, but the exceeding BGP routes are not 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 resubmit the routes that were initially rejected.

The no form of this command disables any limit on the number of routes within a VRF context. Issue the no form of this command only when the VPRN instance is shut down.

This command sets the identifier attached to routes the VPN belongs to. Each routing instance must have a unique route distinguisher (within the carrier domain) associated with it. A route distinguisher must be defined for a VPRN to be operationally active.

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 this command removes the router ID definition from the specific VPRN context.

This command configures an optional service name, up to 64 characters, which adds a name identifier to a specific service to use in configuration references and in show commands throughout the system. This helps the service provider/administrator to identify and manage services within the 7210 SAS 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 specific service when it is initially created.

This command enables the context to configure DSCP/dot1p re-marking for select self-generated traffic.

This command configures DSCP/dot1p re-marking for self-generated application traffic. When an application is configured using this command, the specified DSCP name/value is used for all packets generated by this application within the router instance it is configured. The instances can be base router, VPRN service, or management.

Using the value configured in this command:

Only one DSCP name/value can be configured per application. If multiple entries are configured, the subsequent entry overrides the previously configured entry.

The no form of this command reverts 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 for configured applications that matches the specified DSCP are assigned to the corresponding forwarding class. Multiple commands can be entered to define the association of some or all 64 DSCPs to a forwarding class.

All DSCP names that define a DSCP value must be explicitly defined.

The no form of this command removes the DSCP-to-forwarding class association.

This command sets the SNMP community name to be used with the associated VPRN instance.

If an SNMP community name is not specified, SNMP access is not allowed.

The no form of this command removes the SNMP community name from the specific VPRN context.

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 creates static route entries within the associated router instance. When configuring a static route, either next-hop, indirect or black-hole must be configured.

The no form of this command deletes the static route entry. If a static route needs to be removed when multiple static routes exist to the same destination, as many parameters to uniquely identify the static route must be entered.

If a CPE connectivity check target address is already being used as the target address in a different static route, cpe-check parameters must match. If they do not, the new configuration command are rejected.

If a static-route command is issued with no cpe-check target but the destination prefix/netmask and next-hop matches a static route that did have an associated cpe-check, the cpe-check test is removed from the associated static route.

This command specifies the export policies to control routes exported from the local VPN routing/forwarding (VRF) to other VRFs on the same or remote PE routers (via MP-BGP).

The no form of this command removes all route policy names from the export list.

This command sets the import policies to control routes imported to the local VPN routing/ forwarding (VRF) from other VRFs on the same or remote PE routers (via MP-BGP). BGP-VPN routes imported with a vrf-import policy 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 on the same router, unless the preference is changed by the policy.

The no form of this command removes all route policy names from the import list.

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 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 this command removes the vrf-target.

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.

The no form of this command disables MVPN membership auto-discovery through BGP.

This command specifies BGP or PIM, for PE-to-PE signaling of CE multicast states.

Changes may only be made to this command when the mvpn node is shutdown.

The no form of this command reverts it back to the default.

This command specifies whether or not to use inter-site shared C-trees.

This command restricts MVPN instances per PE node to a specific role. By default, the MVPN instance on a specific PE node assumes the role of sender and 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 PE node to a specific role prevents the creation of full mesh of MDT/PMSI across all participating PE nodes in the MVPN instance.

The auto-rp-discovery command cannot be enabled together with the mdt-type sender-only, mdt-type receiver-only, or wildcard-spmsi configurations.

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

This command enables the context to configure tunnel parameters for the MVPN.

This command enables the context to specify inclusive provider tunnels

This command configures the type of bootstrap router (BSR) signaling used.

The no form of this command restores the default.

This command enables the use of mLDP LSP for the provider tunnel.

This command administratively disables and enables the use of mLDP LSP for the provider tunnel.

This command enables use of P2MP RSVP as the inclusive or selective provider tunnel

The no form of this command removes the rsvp context, including all the statements in the context.

This command configures the use of an automatically created P2MP LSP as the inclusive or selective provider tunnel. The P2MP LSP is signaled using the parameters specified in the template, such as bandwidth constraints.

The no form of the command removes the configuration.

This command administratively disables the use of RSVP P2MP LSP for the inclusive or selective provider tunnel.

The no form of this command administratively enables the use of RSVP P2MP LSP for the provider tunnel.

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.

The auto-rp-discovery command cannot be enabled together with mdt-type sender-only or mdt-type receiver-only, or wildcard-spmsi configurations.

The no form of this command disables the (C-*, C-*) S-PMSI functionality.

This command enables the context to specify selective provider tunnel parameters.

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.

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

This command provides an option to the user to specify the group range for which a switch from the inclusive provider tunnel to the selective provider tunnel for C-(S,G) must be triggered. This command provides an option to use selective provide tunnel, independent of the multicast data rate (that is, there is no rate-threshold configuration required). For C-(S,G) groups specified with this command, the selective provider tunnel is used.

Note: For C-(S,G) groups not configured with the data-threshold command, the inclusive provider tunnel is used.

Multiple statements are allowed in the configuration to specify multiple group ranges.

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

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 stays on I-PMSI.

This command specifies which UMH selection mechanism to use, highest IP address. The no form of this command resets it back to default.

This command specifies the export policy (up to 15) to control MVPN routes exported from the local VRF to other VRFs on the same or remote PE routers.

This command specifies the import policy (up to 15) to control MVPN routes imported to the local VRF from other VRFs on the same or remote PE routers.

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 this command removes the vrf-target.

This command specifies communities to be sent to peers.

This command specifies communities to be accepted from peers.

This command binds a service to an existing Service Distribution Point (SDP). The SDP defines the transport tunnel to which this VPRN service is bound.

The SDP has an operational state that 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 is down.

The SDP must already exist in the config>service>sdp context before it can be associated with a VPRN service. If the sdp sdp-id is not already configured, an error message is generated. If the sdp-id exists, a binding between the specific sdp-id and the service is created.

SDPs must be explicitly associated and bound to a service to allow far-end 7210 SAS 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. When the SDP binding is removed, no packets are forwarded to the far-end router.

This command creates a logical IP routing interface for a VPRN. When created, attributes like an IP address and 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.

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 7210 SAS.

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. When 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.

The no form of this command removes the IP address assignment from the IP interface. When the no address command is entered, the interface becomes operationally 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 is reinitialized.

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 is 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 are counted in the normal discard counters for the egress SAP.

By default, directed broadcasts are not allowed and are discarded at this egress IP interface.

The no form of this command disables the forwarding of directed broadcasts out of the IP interface.

This command configures the BFD parameters for the associated IP interface. If no parameters are defined, the default value is 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) are notified of the fault.

Note: Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Router Configuration Guide for information about the list of routing and MPLS protocols and features that use BFD for protection on 7210 SAS platforms.

The no form of this command removes BFD from the associated IGP protocol adjacency.

This command enables the context to configure DHCPv6 relay parameters for the interface.

The no form of this command disables DHCPv6 relay.

This command enables the context to configure DHCPv6 relay information options.

The no form of this command disables DHCPv6 relay information options.

This command send interface ID options in the DHCPv6 relay packet.

The no form of this command disables the sending of interface ID options in the DHCPv6 relay packet.

This command sends the remote ID option in the DHCPv6 relay packet. The client DHCP Unique Identifier (DUID) is used as the remote ID.

The no form of this command disables the sending of the remote ID option in the DHCPv6 relay packet.

This command configures an IPv6 address to the DHCPv6 server used to send the relay packets to.

The no form of this command disables the specified IPv6 address.

This command assigns the source IPv6 address of the DHCPv6 relay messages.

The no form of this command disables the specified IPv6 address.

This command enables local proxy ARP on an IP interface. When this command is enabled, the system responds with its own MAC address to all ARP requests for IP addresses belonging to the subnet, and therefore becomes the forwarding point for all traffic between hosts in that subnet.

When this command is enabled, ICMP redirects on the ports associated with the service are automatically blocked.

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 an L3 VPN context, the configuration for the VPRN should have a loopback address configured that has the same address as the system address of the core instance (BGP next-hop).

This command enables a proxy ARP policy for the interface.

The no form of this command disables the proxy ARP capability.

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.

This command assigns up to 64 secondary IP addresses to the interface, including the primary IP address. Each address can be configured in an IP address, IP subnet, or broadcast address format.

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 appears 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 is replaced with the new MAC address.

When the unnumbered keyword is used, this command configures a static ARP entry associating an unnumbered interface with a MAC address for the core router instance. This static ARP appears in the core routing ARP table. A static ARP can only be configured if it exists on the network attached to the unnumbered interface.

If an entry for a particular unnumbered interface already exists and a new MAC address is configured for the interface, the existing MAC address is replaced with the new MAC address.

The no form of this command removes a static ARP entry.

This command configures router advertisement properties. By default, it is disabled for all IPv6 enabled interfaces.

The no form of this command disables all IPv6 interfaces. However, the no interface interface-name command disables a specific interface.

This command configures router advertisement properties on a specific interface. The interface must already exist in the config>router>interface context.

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.

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.

This command configures the maximum interval between sending router advertisement messages.

This command configures the minimum interval between sending ICMPv6 neighbor discovery router advertisement messages.

This command configures the MTU for the nodes to use to send packets on the link.

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 about other servers in the network.

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.

This command specifies whether the prefix can be used for stateless address autoconfiguration.

This command specifies whether the prefix can be used for onlink determination.

This command configures the remaining length of time in seconds that this prefix continues 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.

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

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

This command configures how long this router should be considered reachable by other nodes on the link after receiving a reachability confirmation.

This command configures the retransmission frequency of neighbor solicitation messages.