Cisco Systems 1000 Series Manual De Usuario
8-7
Cisco ASR 1000 Series Aggregation Services Routers Software Configuration Guide
OL-16506-17
Chapter 8 Multilink PPP Support for the Cisco ASR 1000 Series Routers
Cisco IOS XE Scaling Limits for MLP Bundles
Restrictions for MLP over ATM at PTA and LAC
The following restrictions apply to MLP over ATM at PTA and LAC:
•
ATM Autosense is supported to allow the dynamic selection of MLPoA or MLPoEoA.
•
For ATM, the link-level bandwidth is a part of the ATM Permanent Virtual Circuits (PVC)
configuration based on the unspecified bit rate (UBR) or variable bit rate (VBR) configurations. The
bundle bandwidth is the aggregate of the member-link session bandwidth.
configuration based on the unspecified bit rate (UBR) or variable bit rate (VBR) configurations. The
bundle bandwidth is the aggregate of the member-link session bandwidth.
Note
The MLP over Ethernet over ATM at PTA and LAC has the same restrictions as the MLP over ATM at
PTA and LAC.
PTA and LAC.
Restrictions for MLP at LAC
In case of MLP over LNS (Ethernet) LAC switching, the MLP member-link session and the packet
payload is transparent at the LAC device because it does not terminate the MLP session or the bundle
interface. Hence, the LAC device does not bind the number of member-link sessions associated with a
bundle. Similarly, the LFI functionality is transparent at the LAC device because the traffic is switched
or passed through traffic.
payload is transparent at the LAC device because it does not terminate the MLP session or the bundle
interface. Hence, the LAC device does not bind the number of member-link sessions associated with a
bundle. Similarly, the LFI functionality is transparent at the LAC device because the traffic is switched
or passed through traffic.
Restrictions for MLP over LNS
The following restrictions apply to MLP over LNS:
•
MLPoLNS bundles are supported with only Ethernet as the trunk between the LAC and LNS.
•
Layer 2 Tunnel Protocol (L2TP) over IPsec is not supported.
•
QoS (other than downstream Model-F shaping) on interfaces and tunnels towards the customer
premise equipment (CPE) is not supported.
premise equipment (CPE) is not supported.
•
When the CPE client initiates the PPP LCP connection, the multilink negotiation included as part of
the LCP negotiation may fail if the LAC has not yet established connection with the LNS (which is
typically the case). The LNS renegotiates the Multilink LCP options with the CPE client when the
LAC initiates the connection to the LNS. (To allow this renegotiation of LCP options, the lcp
renegotiation always command must be configured in the VPDN group at the LNS).
the LCP negotiation may fail if the LAC has not yet established connection with the LNS (which is
typically the case). The LNS renegotiates the Multilink LCP options with the CPE client when the
LAC initiates the connection to the LNS. (To allow this renegotiation of LCP options, the lcp
renegotiation always command must be configured in the VPDN group at the LNS).
•
Although per-packet load balancing is not supported, the configuration is not blocked and the
functionality is operational (but not tested). Per-packet load balancing cannot be used with
MLPoLNS because MLPoLNS requires a single-path per-destination IP address.
functionality is operational (but not tested). Per-packet load balancing cannot be used with
MLPoLNS because MLPoLNS requires a single-path per-destination IP address.
•
Unlike the MLP over Serial mode or the MLP PTA mode, packets may traverse several network hops
between the CPE and LNS devices in an MLPoLNS network. As a result of this multihop topology,
even on a single-link bundle, MLP encapsulated packets may arrive at the receiver in an out-of-order
state. Hence, the MLPoLNS receiver operates in a loose, lost-fragment detection mode. In this
mode, if an MLP fragment is lost, the received MLP waits for a short time to receive the lost
fragment. In addition, the MLP receiver limits the amount of out-of-order MLP data received before
the fragment is declared lost. In Cisco IOS XE software, the default timeout value is 1 second. This
may create problems in an environment with high packet loss and scaled MLP configurations
because it requires the receiver to potentially buffer large amounts of data for each MLP bundle.
Since the buffer space that is available is a finite resource, worst-case depletion of buffers can bleed
between the CPE and LNS devices in an MLPoLNS network. As a result of this multihop topology,
even on a single-link bundle, MLP encapsulated packets may arrive at the receiver in an out-of-order
state. Hence, the MLPoLNS receiver operates in a loose, lost-fragment detection mode. In this
mode, if an MLP fragment is lost, the received MLP waits for a short time to receive the lost
fragment. In addition, the MLP receiver limits the amount of out-of-order MLP data received before
the fragment is declared lost. In Cisco IOS XE software, the default timeout value is 1 second. This
may create problems in an environment with high packet loss and scaled MLP configurations
because it requires the receiver to potentially buffer large amounts of data for each MLP bundle.
Since the buffer space that is available is a finite resource, worst-case depletion of buffers can bleed