The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The Frame Relay Queueing and Fragmentation at the Interface feature introduces support for low-latency queueing (LLQ) and FRF.12 end-to-end fragmentation on a Frame Relay interface. This new feature simplifies the configuration of low-latency, low-jitter quality of service (QoS) by enabling the queueing policy and fragmentation configured on the main interface to apply to all permanent virtual circuits (PVCs) and subinterfaces under that interface. Before the introduction of this feature, queueing and fragmentation had to be configured on each individual PVC. Subrate shaping can also be configured on the interface.
For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Frame Relay Queueing and Fragmentation at the Interface" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS XE software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
•Restrictions for Frame Relay Queueing and Fragmentation at the Interface
•Restrictions for Frame Relay Queueing and Fragmentation at the Interface
•Information About Frame Relay Queueing and Fragmentation at the Interface
•How to Configure Frame Relay Queueing and Fragmentation at the Interface
•Configuration Examples for Frame Relay Queueing and Fragmentation at the Interface
•Feature Information for Frame Relay Queueing and Fragmentation at the Interface
•Interface fragmentation and Frame Relay traffic shaping cannot be configured at the same time.
•Interface fragmentation and class-based fragmentation cannot be configured at the same time.
•Frame Relay switched virtual circuits (SVCs) are not supported.
•Hierarchical shaping and multiple shapers are not supported.
•Frame Relay Queueing and Fragmentation at the Interface Feature Design
When FRF.12 end-to-end fragmentation is enabled on an interface, all PVCs on the main interface and its subinterfaces will have fragmentation enabled with the same configured fragment size. To maintain low latency and low jitter for high-priority traffic, the configured fragment size must be greater than the largest high-priority frames. This configuration will prevent high-priority traffic from being fragmented and queued behind lower-priority fragmented frames. If the size of a high-priority frame is larger than the configured fragment size, the high-priority frame will be fragmented. Local Management Interface (LMI) traffic will not be fragmented and is guaranteed its required bandwidth.
When a low-latency queueing policy map is applied to the interface, traffic through the interface is identified using class maps and is directed to the appropriate queue. Time-sensitive traffic such as voice should be classified as high priority and will be queued on the priority queue. Traffic that does not fall into one of the defined classes will be queued on the class-default queue. Frames from the priority queue and class queues are subject to fragmentation and interleaving. As long as the configured fragment size is larger than the high-priority frames, the priority queue traffic will not be fragmented and will be interleaved with fragmented frames from other class queues. This approach provides the highest QoS transmission for priority queue traffic. Figure 1 illustrates the interface queueing and fragmentation process.
Figure 1 Frame Relay Queueing and Fragmentation at the Interface
Subrate shaping can also be applied to the interface, but interleaving of high-priority frames will not work when shaping is configured. If shaping is not configured, each PVC will be allowed to send bursts of traffic up to the physical line rate.
When shaping is configured and traffic exceeds the rate at which the shaper can send frames, the traffic is queued at the shaping layer using fair queueing. After a frame passes through the shaper, the frame is queued at the interface using whatever queueing method is configured. If shaping is not configured, then queueing occurs only at the interface.
Note For interleaving to work, both fragmentation and the low-latency queueing policy must be configured with shaping disabled.
The Frame Relay Queueing and Fragmentation at the Interface feature supports the following functionality:
•Voice over Frame Relay
•Weighted Random Early Detection
•Frame Relay payload compression
Note When payload compression and Frame Relay fragmentation are used at the same time, payload compression is always performed before fragmentation.
•IP header compression
Simple Configuration
The Frame Relay Queueing and Fragmentation at the Interface feature allows fragmentation, low-latency queueing, and subrate shaping to be configured on a Frame Relay interface queue. The fragmentation and queueing and shaping policy will apply to all PVCs and subinterfaces under the main interface, eliminating the need to configure QoS on each PVC individually.
Flexible Bandwidth
This feature allows PVCs to preserve the logical separation of traffic from different services while reducing bandwidth partitioning between PVCs. Each PVC can send bursts of traffic up to the interface shaping rate or, if shaping is not configured, the physical interface line rate.
•Configuring Class Policy for the Priority Queue
•Configuring Class Policy for the Bandwidth Queues
•Configuring the Shaping Policy Using the Class-Default Class
•Configuring Queueing and Fragmentation on the Frame Relay Interface
•Verifying Frame Relay Queueing and Fragmentation at the Interface
•Monitoring and Maintaining Frame Relay Queueing and Fragmentation at the Interface
To configure a policy map for the priority class, use the following commands beginning in global configuration mode:
To configure a policy map and create class policies that make up the service policy, use the following commands beginning in global configuration mode:
In general, the class-default class is used to classify traffic that does not fall into one of the defined classes. Even though the class-default class is predefined when you create the policy map, you still have to configure it. If a default class is not configured, traffic that does not match any of the configured classes is given best-effort treatment, which means that the network will deliver the traffic if it can, without any assurance of reliability, delay prevention, or throughput.
If you configure shaping in addition to queueing on the interface, use the class-default class to configure the shaping policy. The shaping policy will serve as the parent in a hierarchical traffic policy. The queueing policy will serve as the child policy. The class-default class is used for the shaping policy so that all traffic for the entire interface is shaped and a bandwidth-limited stream can be created.
To configure the shaping policy in the class-default class, use the following commands beginning in global configuration mode:
To configure low-latency queueing and FRF.12 end-to-end fragmentation on a Frame Relay interface, use the following commands beginning in global configuration mode:
To verify the configuration and performance of Frame Relay queueing and fragmentation at the interface, perform the following steps:
Step 1 Enter the show running-config command to verify the configuration.
Router# show running-config
Building configuration...
.
.
.
class-map match-all voice
match ip precedence 5
!
!policy-map llq
class voice
priority 64
policy-map shaper
class class-default
shape peak 96000
service-policy llq
!
!interface Serial1/1
ip address 16.0.0.1 255.255.255.0
encapsulation frame-relay
service-policy output shaper
frame-relay fragment 80 end-to-end
!
Step 2 Enter the show policy-map interface command to display low-latency queueing information, packet counters, and statistics for the policy map applied to the interface. Compare the values in the "packets" and the "pkts matched" counters; under normal circumstances, the "packets" counter is much larger than the "pkts matched" counter. If the values of the two counters are nearly equal, then the interface is receiving a large number of process-switched packets or is heavily congested.
The following sample output for the show policy-map interface command is based on the configuration in Step 1:
Router# show policy-map interface serial 1/1
Serial1/1
Service-policy output:shaper
Class-map:class-default (match-any)
12617 packets, 1321846 bytes
5 minute offered rate 33000 bps, drop rate 0 bps
Match:any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
192000/96000 1992 7968 7968 83 1992
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 12586 1321540 0 0 no
Service-policy :llq
Class-map:voice (match-all)
3146 packets, 283140 bytes
5 minute offered rate 7000 bps, drop rate 0 bps
Match:ip precedence 1
Weighted Fair Queueing
Strict Priority
Output Queue:Conversation 24
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map:class-default (match-any)
9471 packets, 1038706 bytes
5 minute offered rate 26000 bps
Match:any
Step 3 Enter the show interfaces serial command to display information about the queueing strategy, priority queue interleaving, and type of fragmentation configured on the interface. You can determine whether the interface has reached a congestion condition and packets have been queued by looking at the "Conversations" fields. A nonzero value for "max active" counter shows whether any queues have been active. If the "active" counter is a nonzero value, you can use the show queue command to view the contents of the queues.
The following sample output for the show interfaces serial command is based on the configuration in Step 1:
Router# show interfaces serial 1/1
Serial1/1 is up, line protocol is up
Hardware is M4T
Internet address is 16.0.0.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 5/255, rxload 1/255
Encapsulation FRAME-RELAY, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
LMI enq sent 40, LMI stat recvd 40, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Fragmentation type:end-to-end, size 80, PQ interleaves 0
Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
Last input 00:00:03, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:06:34
Input queue:0/75/0/0 (size/max/drops/flushes); Total output drops:0
Queueing strategy:weighted fair
Output queue:0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 33000 bits/sec, 40 packets/sec
40 packets input, 576 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
15929 packets output, 1668870 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up
To monitor and maintain Frame Relay queueing and fragmentation at the interface, use the following commands in privileged EXEC mode:
•Frame Relay Queueing, Shaping, and Fragmentation at the Interface: Example
•Frame Relay Queueing and Fragmentation at the Interface: Example
The following example shows the configuration of a hierarchical policy for low-latency queueing, FRF.12 fragmentation, and shaping on serial interface 3/2. Note that traffic from the priority queue will not be interleaved with fragments from the class-default queue because shaping is configured.
class-map voice
match access-group 101
policy-map llq
class voice
priority 64
policy-map shaper
class class-default
shape average 96000
service-policy llq
interface serial 3/2
ip address 10.0.0.1 255.0.0.0
encapsulation frame-relay
bandwidth 128
clock rate 128000
service-policy output shaper
frame-relay fragment 80 end-to-end
access-list 101 match ip any host 10.0.0.2
The following example shows the configuration of low-latency queueing and FRF.12 fragmentation on serial interface 3/2. Because shaping is not being used, a hierarchical traffic policy is not needed and traffic from the priority queue will be interleaved with fragments from the other queues. Without shaping, the output rate of the interface is equal to the line rate or configured clock rate. In this example, the clock rate is 128,000 bps.
class-map voice
match access-group 101
policy-map llq
class voice
priority 64
class video
bandwidth 32
interface serial 3/2
ip address 10.0.0.1 255.0.0.0
encapsulation frame-relay
bandwidth 128
clock rate 128000
service-policy output llq
frame-relay fragment 80 end-to-end
access-list 101 match ip any host 10.0.0.2
|
|
---|---|
WAN commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples |
|
|
---|---|
No new or modified standards are supported by this functionality. |
— |
|
|
---|---|
No new or modified RFCs are supported by this functionality. |
— |
Table 1 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS XE software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note Table 1 lists only the Cisco IOS XE software release that introduced support for a given feature in a given Cisco IOS XE software release train. Unless noted otherwise, subsequent releases of that Cisco IOS XE software release train also support that feature.