6.4. VPRN Services Command Reference

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 as follows in Special Cases.

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

If the ASN was previously changed, the BGP ASN inherits the new value.

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 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 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. 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 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 shutdown 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 vrpn context to be shut down and restarted for changes to take effect. This command can only be configured with VPRN loopback interfaces.

Caution: Prior to enabling the allow-export-bgp-vpn command, ensure that the routing updates do not loop back to the source. Failure to do so may cause the routes to 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.

Users 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 the resolution is set to any, any supported tunnel type in the 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 following tunnel types are supported in a VPRN context in order of preference: RSVP and LDP. 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.

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.

Users must set the resolution to filter to activate the list of tunnel-types configured under the 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 configures the subset of tunnel types that 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 and LDP. 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 defines the autonomous system (AS) to be used by this VPN routing or 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 devices do not consider multiple paths learned from CE BGP peers when selecting primary and backup path to reach the CE.

This command enables the context to configure GRT leaking commands. If all the supporting commands in the context are removed, this command is also removed.

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 specifies the maximum number of remote IPv6 routes that can be held within a VPN 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-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 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 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 specifies the maximum number of remote routes that can be held within a VPN 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 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 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 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 to which the VPN belongs. Each routing instance must have a unique (within the carrier domain) route distinguisher 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 specified VPRN context.

This command configures an optional service name, up to 64 characters, which adds a name identifier to a specified service. The service name can be used for reference in configuration and show commands. This helps the service provider or 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 specified service when it is initially created.

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

This command configures DSCP or 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 in which it is configured. The instances can be base router, VPRN service, or management.

The values configured in this command do the following:

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 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 specified 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, the next-hop, indirect, or black-hole parameters 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 as are required 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, the 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 will be 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 configures 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 using 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 binds a service to an existing 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 service is created.

SDPs must be explicitly associated and bound to a service to allow far-end 7210 SAS devices to 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 binds a service to an existing 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 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 be defined in the config>service>sdp context to associate an SDP with a service. If the sdp 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. When removed, no packets are forwarded to the far-end router.

This command configures an SDP context.

This command configures the SDP context.

This command configures the egress VC label.

This command configures the ingress VC label.

This command associates an IP filter policy with an ingress or egress 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 that has 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 fails and an error message is 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 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 the scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.

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.

This command creates and maintains IP routing interfaces within VPRN service IDs. The interface command can be executed in the context of a 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 IP interfaces defined by the config router interface and config service vprn interface commands. 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 using 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, no IP interface names are 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 interface and all the associated configuration. The interface must be administratively shut down before issuing the no interface command.

For VPRN services, the IP interface must be shut down 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, 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 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 are 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.

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 are 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, because 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 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) are notified of the fault.

Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Router Configuration Guide for information about the routing and MPLS protocols and features that can 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 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 therefore becomes the forwarding point for all traffic between hosts in that subnet. When the local-proxy-arp 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 a Layer 3 VPN context, the configuration for the VPRN should have a loopback address configured that has the same address as the core instance system address (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 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 be configured only 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.

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 interface. 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 on-link determination.

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.

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.

This command sets the router lifetime.

This command configures Internet Control Message Protocol (ICMP) parameters on a VPRN service.

This command enables responses to 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 replies to mask requests.

The no form of this command disables replies to ICMP mask requests on the router interface.

This commad configures the rate for 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 are 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 specified time interval.

By default, the 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.

This command configures the rate ICMP TTL expired messages are issued by the IP interface.

By default, the 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.

This command configures the rate for ICMP host and network destination unreachable messages issued 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 that can be issued on the interface for a specified time interval.

By default, the generation of ICMP destination unreachable 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 destination unreachable messages on the router interface.

This command configures the maximum IP transmit unit (packet) for the interface.

The MTU that is advertised from the VPRN size is:

MINIMUM((SdpOperPathMtu - EtherHeaderSize), (Configured ip-mtu))

By default (for Ethernet network interface) if no ip-mtu is configured, the packet size is (1568 - 14) = 1554.

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

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters that identify the service access point on the interface and within the 7210 SAS. 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 does 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 be associated with only a single service. A SAP can be defined only 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 shut down, all SAPs on that port become operationally down. When a service is shut down, SAPs for the service are not displayed as operationally down, although all traffic traversing the service is 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 are also deleted.

This command applies a time-based policy (filter or QoS policy) to the SAP. The suite name must already exist in the config>cron context.

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

This command enables accounting and statistical data collection for an interface SAP or interface SAP spoke-SDP, or network port. When applying accounting policies, by default the data 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 does not obtain the results and write them to the billing file. If a subsequent collect-stats command is issued, the counters written to the billing file include all the traffic while the no collect-stats command was in effect.

This command assigns a valid existing Distributed CPU Protection (DCP) policy to a SAP. By default, no DCP policy is associated with the SAP.

The no form of this command disables the use of DCP policies for the SAP.

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 look up an entry in the anti-spoof filter table. The parameter type defines the anti-spoof filter type enforced by the SAP when anti-spoof filtering is enabled.

The following are the default filter types:

The no form of this command disables anti-spoof filtering on the SAP.

This command configures populating static and dynamic hosts into the system ARP cache. When enabled, the host 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 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 are repopulated when all static and dynamic host information for the IP address are removed. Because 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 fails if an existing static subscriber host on the SAP does not have both MAC and IP addresses specified.

When the arp-populate command is enabled, creating a static subscriber host on the SAP without both an IP address and MAC address fails.

The arp-populate command can be enabled on only VPRN interfaces supporting Ethernet encapsulation.

The no form of this command disables ARP cache population functions for static and dynamic hosts on the interface. All static and dynamic host information in the system ARP cache are removed. Any existing static ARP entries previously inactive because of static or dynamic hosts are populated in the system ARP cache.

When arp-populate is enabled, the system does 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 the arp-populate command enabled.

This command configures the minimum time in seconds an ARP entry learned on the IP interface is 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 reverts to the default value.

This command delays making the interface operational by the specified number of seconds.

In environments with many subscribers, it can take time to synchronize the subscriber state between peers when the subscriber interface is enabled (for example, after a reboot). To ensure that the state has time to be synchronized, the delayed-enable timer can be specified. The optional init-only parameter specifies to use the delayed-enable timer only after a reboot.

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 is enabled on the SAP, the host information is populated into the SAP anti-spoof table, allowing ingress packets that match the entry to access 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 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 does 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.

The no form of this command removes a static entry from the system. The specified ip address and mac address must exactly match the IP and MAC addresses of the host 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.

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 this command disables the use of FRF12 headers.

This command specifies the maximum length of a fragment to be transmitted.

The no form of this 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. This provides behavior similar to MLPPP Link Fragment Interleaving (LFI).

When this option is disabled, frames of all the FR SAP forwarding class queues are subject to fragmentation. However, the fragmentation header is 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 reverts to the default value.

This command specifies the scheduling class to use for this SAP.

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 defines a maximum total rate for all egress queues on a service SAP.

The port scheduler mode should be set to “sap-based” scheduling mode before using this command. The egress port scheduler enforces the aggregate queue rate for the SAP as it distributes its bandwidth to all the SAPs configured on the port. The port scheduler stops distributing bandwidth to member queues when it has detected that the aggregate rate limit has been reached.

A SAP aggregate scheduler is created for each instance of the SAP queues created on each of the member ports of the LAG. For a LAG, the port scheduler mode configured for the primary port is used for all the member ports of the LAG.

The scheduler mode is specified by the scheduler-mode command. To implement the agg-rate-limit, the scheduler mode must be specified as “sap-based”. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Interface Configuration Guide for more information about the scheduler-mode command.

The no form of this command removes the aggregate rate limit from the SAP or multi-service site.

This command associates a set of two counters to count total forwarded packets and octets and total dropped packets and octets. When the counter is enabled, the number of resources required increases by twice the number of resources taken up when counter is not used. If the enable-stats keyword is specified during the creation of the meter, the counter is allocated by the software, if available. To free up the counter and relinquish its use, the user can use the no aggregate-meter-rate command, and then recreate the meter using the aggregate-meter-rate command.

If egress rrame-based accounting is used, the SAP egress aggregate meter rate accounts for the Ethernet frame overhead. The system accounts for 12 bytes of IFG and 8 bytes of start delimiter. Frame-based counting does not affect the count of octets maintained by the counter, if it is in use.

Note: Before enabling this command for a SAP, resources must be allocated to this feature from the egress internal TCAM resource pool using the configure system resource-profile egress-internal-tcam egress-sap-aggregate-meter command. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for more information. The egress aggregate meter is not FC aware. The forward and drop decisions are made based on the order the packets are sent out of the SAP by the egress port scheduler.

The no form of this command removes the egress aggregate policer from use.

This command associates an IP filter policy with an ingress or egress 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 that has 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 fails and an error message is 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 is not removed from the system unless the scope of the created filter is set to local.

This command associates a QoS policy with an ingress or egress SAP or IP interface.

QoS ingress and egress policies are important for the enforcement of SLA agreements. The policy ID must be defined before associating the policy with a SAP or IP interface. If the policy-id does not exist, an error is returned.

The qos command associates both ingress and egress QoS policies. The qos command only allows ingress policies to be associated on SAP or IP interface ingress, and only allows egress policies on SAP or IP interface 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 policy of the same or different type replaces the earlier one with the new policy.

On the 7210 SAS-R6 and 7210 SAS-R12 (ingress), using the enable-table-classification keyword enables the use of IP DSCP tables to assign FC and profile on a per-SAP 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). The IP DSCP classification policy configured in the SAP ingress policy is used to assign FC and profile. The default FC is assigned from the SAP ingress policy.

By default, no specific QoS policy is associated with the SAP or IP interface for ingress or egress, so the default QoS policy is used.

Note: On the 7210 SAS-R6 and 7210 SAS-R12, when the interface is associated with RVPLS, the behavior of the qos command is affected. See the enable-table-classification and routed-override-qos-policy commands for information about classification behavior for RVPLS.

The no form of this command removes the QoS policy association from the SAP or IP interface, and the QoS policy reverts to the default value.

This command enables the context to configure ingress SAP 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 enables the context to configure the SAP aggregate policer. The rate of the SAP aggregate policer must be specified by the user. The user can optionally specify the burst size for the SAP aggregate policer. The aggregate policer monitors the traffic on different FCs and determines the destination of the packet. The packet is either forwarded to an identified profile or dropped.

Note: The sum of the CIR rates of the individual FCs configured under the SAP cannot exceed the PIR rate configured for the SAP. Though the 7210 SAS does not block this configuration, it is not recommended for use.

Table 86 lists information about the final disposition of the packet based on the operating rate of the per-FC policer and the per-SAP aggregate policer.

When the SAP aggregate policer is configured, the per-FC policer can be configured only in “trtcm2” mode (RFC 4115).

Note: The meter modes “srtcm” and “trtcm1” are used in the absence of an aggregate meter.

The SAP ingress meter counters increment the packet or octet counts based on the final disposition of the packet.

If ingress frame-based accounting is used, the SAP aggregate meter rate accounts for the Ethernet frame overhead. The system accounts for 12 bytes of IFG and 8 bytes of start delimiter.

The no form of this command removes the aggregate policer from use.

This command, within the SAP ingress contexts, enables the context for specific overrides to one or more meters created on the SAP through the SAP ingress QoS policies.

The no form of this command removes existing meter overrides.

This command, within the SAP ingress contexts, enables the context for specific overrides to a specific meter created on the SAP through a sap-ingress QoS policies.

The no form of this command is used to remove any existing overrides for the specified meter-id.

This command overrides specific attributes of the specified meter adaptation rule parameters. The adaptation rule controls the method used by the system to derive the operational CIR and PIR settings when the meter 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 this 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.

This command provides a mechanism to override the default CBS for the meter. The size parameter specifies the maximum burst size that can be transmitted by the source while still complying with the CIR. If the transmitted burst is lower than the CBS value, the packets are marked as in-profile by the meter to indicate that the traffic is complying with meter configured parameters.

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