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.
To clear PPP mux statistics, use the clear ppp mux EXEC command.
clear ppp mux [interface interface]
interface |
(Optional) The identifier of the multilink or serial interface for which you want to clear counters. |
If no interface is specified, statistics for all multilink and serial interfaces are cleared.
EXEC
None
The following example clears PPP mux statistics for multilink interface 1:
clear ppp mux interface multilink1
|
|
---|---|
show ppp mux |
Displays PPP mux counters for the specified multilink interface. |
To specify the total number of Real-Time Transport Protocol (RTP) header compression connections that can exist on an interface, use the ip rtp compression-connections command in interface configuration mode. To restore the default value, use the no form of this command.
ip rtp compression-connections number
no ip rtp compression-connections
number |
Number of RTP header compression connections the cache supports, in the range from 3 to 1000. |
For PPP and High-Level Data Link Control (HDLC) interfaces, the default is 16 compression connections.
For Frame Relay interfaces, the default is 256 compression connections.
Interface configuration
You should configure one connection for each RTP call through the specified interface.
Each connection sets up a compression cache entry, so you are in effect specifying the maximum number of cache entries and the size of the cache. Too few cache entries for the specified interface can lead to degraded performance, and too many cache entries can lead to wasted memory.
Note Both ends of the serial connection must use the same number of cache entries.
Note The MGX-RPM-1FE-CP back card supports up to 150 RTP header compression connections on a T1 interface and up to 1000 connections per MLP bundle regardless of whether the bundle contains one T1 interface or four.
The following example changes the number of RTP header compression connections supported to 150:
Router> enable
Router# configure terminal
Router(config)# interface Serial1/0.0
Router(config-if)# encapsulation ppp
Router(config-if)# ip rtp header-compression
Router(config-if)# ip rtp compression-connections 150
Router(config-if)# exit
|
|
---|---|
ip rtp header-compression |
Enables RTP header compression. |
show ip rtp header-compression |
Displays RTP header compression statistics. |
To enable Real-Time Transport Protocol (RTP) header compression, use the ip rtp header-compression command in interface configuration mode. To disable RTP header compression, use the no form of this command.
ip rtp header-compression [passive | iphc-format | ietf-format] [periodic-refresh] [ignore-id]
no ip rtp header-compression [passive | iphc-format | ietf-format] [periodic-refresh] [ignore-id]
Disabled
For PPP interfaces, the default format for header compression is the IPHC format.
For High-Level Data Link Control (HDLC) and Frame Relay interfaces, the default format for header compression is the original proprietary Cisco format. The maximum number of compression connections for the proprietary Cisco format is 256.
Interface configuration
You can compress IP/User Datagram Protocol (UDP)/RTP headers to reduce the size of your packets. Compressing headers is especially useful for RTP because RTP payload size can be as small as 20 bytes, and the uncompressed header is 40 bytes.
Header Compression passive Keyword
By default, the ip rtp header-compression command compresses outgoing RTP traffic. This command includes an optional passive keyword. If you specify the passive keyword, outgoing RTP traffic is compressed only if incoming RTP traffic on the same interface is compressed. If you do not specify the passive keyword, all RTP traffic is compressed.
For PPP interfaces, the passive keyword is ignored. PPP interfaces negotiate the use of header-compression, regardless of whether the passive keyword is specified. Therefore, on PPP interfaces, the passive keyword is replaced by the IPHC format, the default format for PPP interfaces.
Header Compression iphc-format Keyword
This command includes the iphc-format keyword. The iphc-format keyword indicates the type of header compression that will be used. For PPP and HDLC interfaces, when the iphc-format keyword is specified, TCP header-compression is also enabled. For this reason, the ip tcp header-compression command appears in the output of the show running-config command. Since both RTP and TCP header compression are enabled, both UDP and TCP packets are compressed.
The iphc-format keyword includes checking whether the destination port number is even and in the ranges of 16385 to 32767 (for Cisco audio) or 49152 to 65535 (for Cisco video). Valid RTP packets that meet the criteria (that is, the port number is even and within the specified range) are compressed using the compressed RTP packet format. Otherwise, packets are compressed using the less-efficient compressed non-TCP packet format.
Note For Frame Relay interfaces, the iphc-format keyword is not available.
Header Compression ietf-format Keyword
This command includes the ietf-format keyword. The ietf-format keyword indicates the type of header compression that will be used. For HDLC interfaces, the ietf-format compresses only UDP packets. For PPP interfaces, when the ietf-format keyword is specified, TCP header-compression is also enabled. For this reason, the ip tcp header-compression command appears in the output of the show running-config command. Since both RTP and TCP header compression are enabled, both UDP and TCP packets are compressed.
However, with the ietf-format keyword, the requirement of checking whether a destination port number is in a specific range has been removed. Any even destination port number higher than 1024 can be used. Valid RTP packets that meet the criteria (that is, the port number is even and higher than 1024), are compressed using the compressed RTP packet format. Otherwise, packets are compressed using the less-efficient compressed non-TCP packet format.
Note For Frame Relay interfaces, the ietf-format keyword is not available.
Support for Serial Lines
RTP header compression is supported on serial lines using Frame Relay, HDLC, or PPP encapsulation. You must enable compression on both ends of a serial connection.
Unicast or Multicast RTP Packets
This command can compress unicast or multicast RTP packets, and, hence, multicast backbone (MBONE) traffic can also be compressed over slow links. The compression scheme is beneficial only when you have small payload sizes, as in audio traffic.
The following example enables RTP header compression on the Serial1/0.0 subinterface and limits the number of RTP header compression connections to 10. In this example, the optional iphc-format keyword of the ip rtp header-compression command is specified.
Router> enable
Router# configure terminal
Router(config)# interface Serial1/0.0
Router(config-if)# encapsulation ppp
Router(config-if)# ip rtp header-compression iphc-format
Router(config-if)# ip rtp compression-connections 10
Router(config-if)# exit
The following example enables RTP header compression on the Serial2/0.0 subinterface and limits the number of RTP header compression connections to 20. In this example, the optional ietf-format keyword of the ip rtp header-compression command is specified.
Router> enable
Router# configure terminal
Router(config)# interface Serial2/0.0
Router(config-if)# encapsulation ppp
Router(config-if)# ip rtp header-compression ietf-format
Router(config-if)# ip rtp compression-connections 20
Router(config-if)# exit
In the following example, RTP header compression is enabled on the Serial1/0.1 subinterface and the optional periodic-refresh keyword of the ip rtp header-compression command is specified:
Router> enable
Router# configure terminal
Router(config)# interface Serial1/0.1
Router(config-if)# encapsulation ppp
Router(config-if)# ip rtp header-compression iphc-format periodic-refresh
Router(config-if)# ip rtp compression-connections 10
Router(config-if)# exit
To access the command mode that allows you to manually control the relays on the VWIC card, use the mode y-cable command.
mode y-cable
This command has no parameters, it invokes the y-cable mode.
There are no default settings or behaviors.
Redundancy configuration
|
|
---|---|
12.2(8)MC2 |
This command was introduced. |
12.2(15)MC1 |
This command was incorporated in Cisco IOS 12.2(15)MC1. |
12.3(11)T |
This command was incorporated in Cisco IOS 12.3(11)T. |
The following example enables y-cable mode.
mode y-cable
To enable PPP multiplexing/demultiplexing, use the ppp mux command in interface configuration mode. To disable PPP multiplexing/demultiplexing, use the no form of this command.
ppp mux
no ppp mux
This command has no parameters.
PPP multiplexing/demultiplexing is disabled by default.
Interface configuration
The following example enables PPP multiplexing/demultiplexing.
ppp mux
To set the maximum time the processor can wait before sending a superframe, use the ppp mux delay command in interface configuration mode. To set the maximum delay to the default, use the no form of this command.
ppp mux delay integer
no ppp mux delay
Cisco MWR 1941-DC router—The default maximum delay is 0, which indicates that a superframe will be sent when the transmit queue is full.
MGX-RPM-1FE-CP back card—The default maximum delay is 800.
Interface configuration
To use this command, you must first enable PPP multiplexing/demultiplexing.
MGX-RPM-1FE-CP Back Card
When the ppp mux delay command is configured, the maximum number of microseconds that the processor can wait resolves to the nearest 200-microsecond increment. For example, if ppp mux delay 302 is specified, the actual maximum number of microseconds that the processor can wait before sending out a PPP superframe is 400. If ppp mux delay 298 is specified, the actual maximum number of microseconds that the processor can wait before sending out a PPP superframe is 200.
The following example sets the maximum delay to 5 microseconds on the MWR 1941-DC router.
ppp mux delay 5
The following example sets the maximum delay to 200 microseconds on the MGX-RPM-1FE-CP back card.
ppp mux delay 200
To set the maximum length (in bytes) of the PPP superframes, use the ppp mux frame command in interface configuration mode. To set the maximum length to the default, use the no form of this command.
ppp mux frame integer
no ppp mux frame
integer |
The maximum number of bytes in any multiplexed PPP superframe. Possible values: •Cisco MWR 1941-DC router—1 through 512 bytes. •MGX-RPM-1FE-CP back card—0 through 512 bytes. |
The default maximum length is 197.
Interface configuration
To use this command, you must first enable PPP multiplexing/demultiplexing.
The following example sets the maximum superframe length to 80 bytes.
ppp mux frame 80
To set the default receiving PPP protocol ID, use the ppp mux pid command in interface configuration mode. To remove this configuration, use the no form of this command.
ppp mux pid integer
no ppp mux pid
integer |
The default value of the PPP protocol ID. Possible values are 0 through 65534. |
The default is 33 (0x21), which is the IP protocol.
Interface configuration
To use this command, you must first enable PPP multiplexing/demultiplexing.
The following example sets the default PPP protocol ID to 8.
ppp mux pid 8
To set the maximum number of PPP subframes that can be contained in a superframe, use the ppp mux subframe count command in interface configuration mode. To set the maximum number to the default, use the no form of this command.
ppp mux subframe count integer
no ppp mux subframe count
The default maximum is 15.
Interface configuration
To use this command, you must first enable PPP multiplexing/demultiplexing.
The following example sets the maximum subframe count to 20 bytes.
ppp mux subframe count 20
To set the maximum length (in bytes) of the PPP subframes, use the ppp mux subframe length command in interface configuration mode. To set the maximum length to the default, use the no form of this command.
ppp mux subframe length integer
no ppp mux subframe length
integer |
The maximum number of bytes in any single subframe that is to be multiplexed. Possible values: •Cisco MWR 1941-DC router—1 through 512 bytes. •MGX-RPM-1FE-CP back card—0 through 512 bytes. |
The default maximum length is 195.
Interface configuration
|
|
---|---|
12.2(8)MC2 |
This command was introduced. |
12.3(11)T |
This command was incorporated in Cisco IOS 12.3(11)T. |
To use this command, you must first enable PPP multiplexing/demultiplexing. The maximum length of the subframe should be the maximum length of the superframe minus the length of the L2 header.
The following example sets the maximum subframe length to 20 bytes.
ppp mux subframe length 20
To enter redundancy configuration mode, use the redundancy command in global configuration mode.
redundancy
This command has no arguments or keywords.
No default behaviors or values.
Global configuration
Use the redundancy command to enter redundancy configuration mode, where you can define aspects of redundancy such as shelf redundancy for the Cisco AS5800 universal access server.
Cisco 10000 Series Router
Before configuring line card redundancy, install the Y-cables. Before deconfiguring redundancy, remove the Y-cables.
The following restrictions apply to line card redundancy on the Cisco 10000 series router:
•Port-level redundancy is not supported.
•Redundant cards must occupy the two subslots within the same physical line card slot.
•The line card that will act as the primary line card must be the first line card configured, and it must occupy subslot 1.
Cisco 7600 Series Router
From redundancy configuration mode, you can enter the main CPU submode to manually synchronize the configurations that are used by the two supervisor engines.
From the main CPU submode, you can use the auto-sync command to use all of the redundancy commands that are applicable to the main CPU.
To select the type of redundancy mode, use the mode command.
Nonstop forwarding (NSF) with stateful switchover (SSO) redundancy mode supports IPv4. NSF with SSO redundancy mode does not support IPv6, INternetwork Packet Exchange (IPX), and Multiprotocol Label Switching (MPLS).
The following example enables redundancy mode:
Router(config)# redundancy
Router(config-red)#
The following example assigns the configured router shelf to the redundancy pair designated as 25. This command must be issued on both router shelves in the redundant router-shelf pair:
Router(config)# redundancy
Router(config-red)# failover group-number 25
Cisco 10000 Series Router
The following example configures two 4-port channelized T3 half eight line cards that are installed in line card slot 2 for one-to-one redundancy:
Router(config)# redundancy
Router(config-red)# linecard-group 1 y-cable
Router(config-red-lc)# member subslot 2/1 primary
Router(config-red-lc)# member subslot 2/0 secondary
Cisco 7600 Series Router
The following example shows how to enter the main CPU submode:
Router (config)#
redundancy
Router (config-r)#
main-cpu
Router (config-r-mc)#
To display Enhanced Compressed Real-Time Transport Protocol (CRTP) statistics, use the show ip rtp header-compression command in privileged EXEC mode.
show ip rtp header-compression [detail] [interface-type interface-number]
detail |
(Optional) Displays details of each connection. |
interface-type interface-number |
(Optional) The interface type and number. |
No default behavior or values
Privileged EXEC
The detail keyword is not available with the show ip rtp header-compression command on a Route Switch Processor (RSP). However, the detail keyword is available with the show ip rtp header-compression command on a Versatile Interface Processor (VIP). Enter the show ip rtp header-compression interface-type interface-number detail command on a VIP to retrieve detailed information regarding RTP header compression on a specific interface.
The detail keyword is also not supported with the show ip rtp header-compression command on a Cisco MWR 1941-DC router or a MGX-RPM-1FE-CP back card (Cisco IOS Mobile Wireless IP Radio Access Network [IP-RAN] implementation). If specified when the command is entered, the output is not displayed. Additionally, some of the field descriptions displayed by the show ip rtp header-compression command do not apply to the MWR 1941-DC router and MGX-RPM-1FE-CP back card.
The following example displays statistics from ECRTP on an interface:
Router# show ip rtp header-compression
RTP/UDP/IP header compression statistics:
Interface Serial2/0 (compression on, IETF, ECRTP)
Rcvd: 1473 total, 1452 compressed, 0 errors, 0 status msgs
0 dropped, 0 buffer copies, 0 buffer failures
Sent: 1234 total, 1216 compressed, 0 status msgs, 379 not predicted
41995 bytes saved, 24755 bytes sent
2.69 efficiency improvement factor
Connect: 16 rx slots, 16 tx slots,
6 misses, 0 collisions, 0 negative cache hits, 13 free contexts
99% hit ratio, five minute miss rate 0 misses/sec, 0 max
Table 1 describes the significant fields shown in the display.
To display counters for a multilink interface, use the show ppp mux command in EXEC mode.
show ppp mux [interface interface]
interface interface |
(Optional) The identifier of the multilink or serial interface for which you want to view counters. |
If no interface is specified, statistics for all multilink and serial interfaces are displayed.
EXEC
This command is only valid when issued against multilink or PPP interfaces.
The following is an example of the output generated by this command.
show ppp mux interface multilink 1
PPP Multiplex Statistics on Interface Multilink1:
Multiplex:
Total input packets:0
Errored input packets:0
Valid input bytes:0
Total output packets:0
Multiplexed output packets:0
Output bytes:0
Efficiency improvement factor:0%
Demultiplex:
Total input packets:0
Multiplexed input packets:0
Errored input packets:0
Valid input bytes:0
Total output packets:0
Output bytes:0
Efficiency improvement factor:0%
Table 2 describes the significant fields shown in the display.
The efficiency improvement factor is calculated as follows:
Multiplex efficiency improvement factor = 100 * (Total bytes saved) / (Total bytes received)
Where total bytes saved = bytes_received_at_muxer - bytes_sent_at_muxer.
Demultiplex efficiency improvement factor = 100 * (Total bytes saved) / (Total bytes sent)
Where total bytes saved = bytes_sent_at_demuxer - bytes_received_at_demuxer.
|
|
---|---|
ppp mux |
Enables PPP multiplexing/demultiplexing |
To specify that the MWR 1941-DC is being used in a stand-alone configuration (which impacts the relays on the VWIC), use the standalone command. To use the MWR 1941-DC in a redundant configuration, use the no form of this command.
[no] standalone
This command has no attributes.
By default, the MWR 1941-DC is configured to be used in a redundant configuration (no standalone) and the relays are open.
Y-cable configuration
|
|
---|---|
12.2(8)MC2 |
This command was introduced. |
12.3(11)T |
This command was incorporated in Cisco IOS Release 12.3(11)T. |
Issuing the standalone command closes the relays on the VWICs installed in the MWR 1941-DC.
The following example closes the relays so that the MWR 1941-DC can be used as a stand-alone device.
standalone
|
|
---|---|
mode y-cable |
Invokes y-cable mode. |
standby use-interface |
Specifies the interfaces to be used for health and revertive interfaces. |
To designate a loopback interface as a health or revertive interface, use the standby use-interface command.
standby use-interface interface {health | revertive | backhaul}
By default, the MWR 1941-DC is configured to be used in a redundant configuration (no standalone) and the relays are open.
Y-cable configuration
|
|
---|---|
12.2(8)MC2 |
This command was introduced. |
12.3(11)T |
This command was incorporated in Cisco IOS Release 12.3(11)T. |
The loopback interfaces that you specify for health and revertive interfaces must be the same loopback interfaces that you specified in the standby track command. In the standby track command, the decrement value for the revertive interface should always be less than that for other interfaces. We recommend that you use loopback101 for health and loopback102 for revertive.
The interface that you specify for the backhaul must be an MLPPP interface. If you want to use a serial interface as the backhaul, you must first configure that interface to be part of an MLPPP bundle. We recommend you use multilink1 for the backhaul interface.
The following example specifies loopback101 as the health interface and loopback102 as the revertive interface.
standby use-interface loopback101 health
standby use-interface loopback102 revertive
standby use-interface multilink1 backhaul