7.8. VPRN Services Command Reference

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

The description command associates a text string with a configuration context to help identify the contents in the configuration file.

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 can 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 are described below in Special Cases.

The no form of this command places the entity into an administratively enabled state.

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 a separate routing instance from the one used for service network core routing connectivity. VPRN services allow the IP addressing scheme used by the subscriber to overlap with other addressing schemes used by other VPRN services or by the provider and, potentially, the entire Internet.

IP interfaces defined within the context of a 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, which 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. To change the association between service and customer, the service must be deleted and recreated with a new customer association.

Once a service is created, the use of customer customer-id is optional to navigate into the service configuration context. Attempting to edit a service with an incorrect customer-id results in an error.

Multiple VPRN services are created in order 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 a VPRN service ID belong 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 shut down and deleted.

This command creates an aggregate route.

Use this command to group a number of routes with common prefixes into a single entry in the routing table. This reduces the number of routes that need to be advertised by this router and reduces the number of routes in the routing tables of downstream routers.

Both the original components and the aggregated route (source protocol aggregate) are offered to the Routing Table Manager (RTM). Subsequent policies can be configured to assign protocol-specific characteristics, such as the OSPF tag, to aggregate routes.

Multiple entries with the same prefix but a different mask can be configured; routes are aggregated to the longest mask. If one aggregate is configured as 10.0/16 and another as 10.0.0/24, then route 10.0.128/17 would be aggregated into 10.0/16 and route 10.0.0.128/25 would be aggregated into 10.0.0/24. If multiple entries are made with the same prefix and the same mask, the previous entry is overwritten.

The no form of the command removes the aggregate.

This command specifies the type of automatic binding for the SDP assigned to this service. When auto-bind is used, it is not required that a spoke-SDP be configured for the service.

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

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

This command enables ECMP in the VPRN service context and configures the number of routes for path sharing; for example, the value 2 means two equal-cost routes will be used for cost sharing.

ECMP (Equal-Cost Multipath Protocol) refers to the distribution of packets over two or more outgoing links that share the same routing cost. ECMP provides a fast local reaction to route failures. ECMP is supported on static routes and dynamic (OSPF, IS-IS, and BGP) routes.

ECMP can only be used for routes with the same preference and same protocol. See the static-route command for information on preferences.

When more ECMP routes are available at the best preference than configured in max-ecmp-routes, then the lowest next-hop IP address algorithm is used to select the number of routes configured in max-ecmp-routes.

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 route with the lowest next-hop IP address is used.

The no form of the command disables ECMP path sharing.

This command is used to bind a key group to a VPRN service for inbound or outbound packet processing. When configured in the outbound direction, packets egressing the node use the active-outbound-sa associated with the key group configured. When configured in the inbound direction, received packets must be encrypted using one of the valid security associations configured for the key group.

The encryption (enabled or disabled) configured on an SDP used to terminate a Layer 3 spoke SDP of a VPRN always overrides any VPRN-level configuration for encryption.

Encryption is enabled once the outbound direction is configured.

The no form of the command removes the key group from the service in the specified direction (inbound or outbound).

This command enters the context under which all GRT leaking commands are configured.

This command enables the functions required for looking up routes in the GRT when the lookup in the local VRF fails. If this command is enabled without the use of the static-route option, 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 global routing table lookup function when the lookup in the local VRF fails.

This command enables management traffic from GRT leaking-enabled VPRN instances to reach local interfaces in the base router instance.The local interfaces can be system IP interfaces or loopback interfaces. Management traffic is traffic generated by Telnet, SNMP, and SSH. For a complete list of supported management protocols, see Table 117.

Ping and traceroute responses from the base router interfaces are supported but are not configurable. The allow-local-management command does not control the support for management protocols terminating on VPRN interfaces directly.

This command creates a static route entry in the GRT.

The no form of the command deletes the entry.

This command uses configured route policies to determine which routes are exported from the VRF to the GRT along with all the forwarding information.

On network egress, packets with a source IP address that matches the 7705 SAR system IP address and the destination IP address of the far-end node must perform a GRT lookup in order to be resolved. A route policy can be configured with the IP address prefix or loopback address of the far-end router and with the action to accept. This policy is configured under the config>router>policy-options context, and is installed in the GRT FIB using the export-grt command. The route installed in the GRT FIB will have a next hop of the IPSec tunnel.

Up to five policies can be exported to the GRT FIB.

The no form of the command restores the default of not exporting routes to the GRT FIB.

This command limits the number of IPv4 routes that can exported from the VRF to the GRT. Setting the limit to 0 overrides the maximum limit. Setting the value to 0 does not limit the number of routes exported from the VRF to the GRT. Configuring the export-limit between 1 and 256 will limit the number of routes to the specified value.

The no form of the command resets the limit to the default of allowing five routes per route policy to be exported from the VRF to the GRT.

This command limits the number of IPv6 routes that can be exported from the VRF to the GRT. Setting the limit to 0 overrides the maximum limit. Setting the value to 0 does not limit the number of routes exported from the VRF to the GRT. Configuring the export-limit between 1 and 256 will limit the number of routes to the specified value.

The no form of the command resets the limit to the default of allowing five routes per route policy to be exported from the VRF to the GRT.

This command specifies the maximum number of IPv6 routes that can be held within a VPN virtual routing /forwarding (VRF) context. Local, host, static, and aggregate routes are not counted.

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

If the log-only parameter is not specified and the maximum-ipv6-routes value is set to a value below the existing number of IPv6 routes in a VRF, then the extra IPv6 routes will not be added to the VRF.

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

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

This command specifies the maximum number of IPv4 routes that can be held within a VPN virtual routing /forwarding (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 to a value below the existing number of IPv4 routes in a VRF, then the extra IPv4 routes will not be added to the VRF.

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

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

This command sets the identifier that gets attached to routes to which the VPN belongs. 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.

AS numbers can be either 2-byte or 4-byte values.

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.

This command configures a service name that can be used for reference in configuration and show commands.

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

This set of commands configures DSCP marking for self-generated IP traffic or dot1p marking for self-generated non-IP traffic (specifically, IS-IS and ARP traffic).

When an IP or Layer 3 application is configured using the dscp-app-name parameter, the specified DSCP name or DSCP value is used for all packets generated by this application within the router instance in which it is configured. The value set in this command sets the DSCP value in the egress IP header. The egress QoS policy will not overwrite this value.

When a Layer 2 application is configured using the dot1p-app-name parameter, the specified dot1p priority value is used for all packets generated by this application within the router instance in which it is configured.

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

The fc-queue option redirects SGT applications to egress data queues rather than the default control queue by assigning them to a forwarding class. If this option is configured, the profile state must be set. All packets that are assigned to this forwarding class will be considered in-profile or out-of-profile based on the configuration. In case of congestion, the in-profile packets are preferentially queued over the out-of-profile packets.

If the fc-queue option is used with the dscp-app-name application, any configuration done using the sgt-qos>dscp command is ignored for packets generated by this application, as illustrated in the following examples:

sgt-qos>application telnet dscp cp1

sgt-qos>dscp cp1 fc af

sgt-qos>application ftp dscp cp1 fc-queue be profile out

sgt-qos>dscp cp1 fc af

In the first example, all packets generated by the Telnet application use DSCP CP1 and map to FC AF as configured in the dscp command. The dot1p bits of the outgoing packets are marked from the value that FC AF points to in the egress QoS policy.

In the second example, all packets generated by the FTP application use DSCP CP1 and map to FC BE as dictated by the fc-queue redirection. The dot1p bits of the outgoing packets are marked from the value that FC BE points to in the egress QoS policy. Because redirection is configured, the mapping configured with the dscp command is ignored.

Note: The above behavior applies to all SGT IP applications with the exception of VRRP, where the dot1p value is always set to 7, regardless of the value in the FC egress QoS policy.

If the fc-queue option is used with the dot1p-app-name application, the dot1p bits of the outgoing packets are marked with the value set with the dot1p-priority parameter, regardless of the value in the FC egress queue policy.

The no form of this command resets the DSCP or dot1p value for the application to its default value and resets the application to use the egress control queue.

This command creates a mapping between the DSCP of the self-generated traffic and the forwarding class. The forwarding class dot1p SAP egress QoS policy mapping is used to mark the dot1p bits of the Layer 3 or IP application. For example, configuring the dscp-name parameter as be and the fc-name parameter as l1 results in marking the dot1p bits of the outgoing Ethernet frame, which is transporting self-generated IP traffic with DSCP bits set to BE, to the value that FC L1 points to in the SAP egress QoS policy (as configured in the config>qos>sap-egress>fc context).

Note: The dot1p class of service may not apply to all IP traffic and is dependent on the egress port encapsulation type.

Based on this configured FC, the SAP egress QoS policy for the egress forwarding complex sets the IEEE 802.1 dot1p bits.

Multiple commands can be entered to associate some or all of the 64 DSCP values with the forwarding class. For undefined code points, packets are assigned to the default forwarding class for the DSCP value. Table 124 lists the default forwarding class for each DSCP value.

The no form of the command resets the DSCP value to its default forwarding class.

Note: If the fc-queue option is configured in the sgt-qos>application dscp-app-name command, the mapping created with this command is ignored for packets generated by the applications that are configured with the option.

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 the command removes the SNMP community name from the given VPRN context.

This command enters the context to specify the source address and application that should be used in all unsolicited packets.

This command configures the application to use the IPv4 source address.

The no form of the command removes the application name from using the IPv4 source address.

This command configures the application to use the IPv6 source address.

The no form of the command removes the application name from using the IPv6 source address.

This command binds a service to an existing Service Distribution Point (SDP).

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 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 sdp-id is not already configured, an error message is generated. If the sdp-id exists, 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 routers can participate in the service. Alternatively, auto-bind can be used. With auto-bind, no vprn>spoke-sdp configuration is required. When both auto-bind and spoke-sdp are configured, spoke-sdp takes precedence. Spoke-sdp must be deconfigured for auto-bind to take effect.

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 is affected. Once the SDP is removed, no packets are forwarded to the far-end router.

This command creates static route entries within the associated router instance.

When configuring an IPv4 static route, the next-hop, ipsec-tunnel, or black-hole parameter, indicating the type of static route, must be configured. Multiple types of static routes (next-hop, ipsec-tunnel, black-hole) can be applied to the same IPv4 prefix. If a static route that is forwarding traffic goes down, the default route will be used instead. The preference parameter is used to specify the order in which the routes are applied. If a blackhole static route has the same preference as another route with the same prefix, the blackhole route takes a lower precedence.

For an IPv6 static route, ipsec-tunnel must be used.

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 enter as many parameters as necessary to uniquely identify that static route.

If a CPE connectivity check target address is already being used as the target address in a different static route, then cpe-check parameters must match. If they do not match, the new configuration command will be 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, then the cpe-check test will be removed from the associated static route.

This command designates the type of VPRN instance being configured for hub and spoke topologies.

The no form of the command resets to the default of a fully meshed VPRN.

This command specifies the export policies to control routes exported from the local VPN virtual routing/ forwarding table (VRF) to other VRFs on the same or remote PE routers (via MP-BGP). The policy (and policy-name) are defined under the config>router>policy-options>policy-statement command.

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

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

The no form of the 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 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 route target from the VRF.

This command enables the BGP protocol on the VPRN service.

The no form of this command disables the BGP protocol on the VPRN service.

This command enables the advertising of inactive BGP routes 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.

The no form of this command disables the advertising of inactive BGP routes to other BGP peers.

This command is used to set the router ID in the BGP aggregator path attribute to 0 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 only the router ID (set to 0) to the aggregator path attribute. This command is used at the group level to revert to the value defined under the global level, and 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 the 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 global level.

The no form of the command used at the neighbor level reverts to the value defined at the group level.

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 the BGP loop detection mechanism. It should be used carefully.

This command associates an authentication keychain with the BGP protocol. The keychain is a collection of keys used to authenticate BGP messages from remote neighbors. The keychain allows the rollover of authentication keys during the lifetime of a session and also supports stronger authentication algorithms than clear text and MD5.

The keychain must already be defined in the config>system>security>keychain context.

Either the authentication-key command or the auth-keychain command can be used by BGP, but both cannot be supported at the same time. If both commands are configured, the auth-keychain configuration will be applied and the authentication-key command will be ignored.

By default, authentication is not enabled.

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 MD5 message-based digest.

The authentication key can be any combination of ASCII characters up to 255 characters long.

Either the authentication-key command or the auth-keychain command can be used by BGP, but both cannot be supported at the same time. If both commands are configured, the auth-keychain configuration will be applied and the authentication-key command will be ignored.

The no form of the command removes the authentication password from the configuration and effectively disables authentication.