Cisco IOS Dial Technologies Command Reference

 

Syntax Description

 

Command Default

The default mode for subinterfaces is multipoint.

 

Command History

 

Usage Guidelines

Subinterfaces can be configured to support partially meshed Frame Relay networks. (Refer to the Frame Relay chapters in the Cisco IOS Wide-Area Networking Configuration Guide.)

To specify the BRI interface that is created by enabling X.25 on a specified ISDN BRI interface, use the interface bri global configuration command with a subinterface 0 specification.

Examples

The following example configures BRI 0 to call and receive calls from two sites, use PPP encapsulation on outgoing calls, and use Challenge Handshake Authentication Protocol (CHAP) authentication on incoming calls:

The following example creates a BRI 0:0 interface for X.25 traffic over the D channel and then configures the new interface to carry X.25 traffic:

 

Related Commands

 

Syntax Description

 

Command Default

No dialer rotary groups are predefined.

 

Command History

 

Usage Guidelines

Dialer rotary groups allow you to apply a single interface configuration to a set of physical interfaces. This capability allows a group of interfaces to be used as a pool of interfaces for calling many destinations.

Once the interface configuration is propagated to a set of interfaces, those interfaces can be used to place calls using the standard dial-on-demand routing (DDR) criteria. When multiple destinations are configured, any of these interfaces can be used for outgoing calls.

Dialer rotary groups are useful in environments that require multiple calling destinations. Only the rotary group needs to be configured with the dialer map commands. The only configuration required for the interfaces is the dialer rotary-group command indicating that each interface is part of a dialer rotary group.

Although a dialer rotary group is configured as an interface, it is not a physical interface. Instead, it represents a group of interfaces. Interface configuration commands entered after the interface dialer command will be applied to all physical interfaces assigned to specified rotary groups. Individual interfaces in a dialer rotary group do not have individual addresses. The dialer interface has a protocol address, and that address is used by all interfaces in the dialer rotary group.

Examples

The following example identifies interface dialer 1 as the dialer rotary group leader. Interface dialer 1 is not a physical interface, but represents a group of interfaces. The interface configuration commands that follow apply to all interfaces included in this group.

 

Syntax Description

 

Command Default

No multilink bundles are created.

 

Command History

 

Usage Guidelines

Cisco 10000 Series Routers

The following describes the valid multilink interface values for the Cisco 10000 Series Routers:

• 1 to 9999—(PRE-2) Cisco IOS Release 12.2(28)SB and later releases
• 1 to 9999 and 65536 to

– 1 to 9999 and 65536 to 2147483647 (Cisco IOS Release 12.2(31)SB2 and later releases)

– 1 to 9999 and 65536 to 2147483647 (Cisco IOS Release 12.2(31)SB2 and later releases)

the range of the multilink-bundle-number argument is from 1 to 2147483647.

From Cisco ASR 1000 Series Routers Release 3.4.0S onward, the range of the multilink-bundle-number argument is from 1 to 65535.

Examples

The following example shows how to create multilink bundle 1:

 

Related Commands

 

Syntax Description

 

Command Default

No default behavior or values.

 

Command History

 

Usage Guidelines

You must explicitly specify a serial interface. The D channel is always the :23 channel for T1 and the :15 channel for E1.

Examples

The following example configures channel groups on time slots 1 to 11 and ISDN PRI on time slots 12 to 24 of T1 controller 0. Then the examples configures the first two channel groups as serial interfaces 0:0 and 0:1.

The following example configures ISDN PRI on T1 controller 4/1 and then configures the D channel on the resulting serial interface 4/1:23:

 

Related Commands

 

Syntax Description

 

Command Default

A virtual-PPP interface is not configured.

 

Command History

 

Usage Guidelines

Use the interface virtual-ppp command to enter interface configuration mode and configure a virtual interface with PPP encapsulation.

After configuring a virtual-PPP interface, you can configure a pseudowire by using the pseudowire command in interface configuration mode. To disable a virtual-PPP interface that has a configured pseudowire, remove the pseudowire by using the no pseudowire command. Disable the virtual-PPP interface by using the no interface virtual-ppp command in global configuration mode or interface configuration mode.

Examples

The following example shows how to configure a virtual-PPP interface:

The following example shows how to remove a virtual-PPP interface that has a configured pseudowire.You must first remove the configured pseudowire or an error is generated. Note that you can remove the virtual-PPP interface in interface configuration mode, as shown below:

 

Related Commands

 

Syntax Description

 

Command Default

No virtual template interface is defined.

 

Command History

 

Usage Guidelines

A virtual template interface is used to provide the configuration for dynamically created virtual access interfaces. It is created by users and can be saved in NVRAM.

After the virtual template interface is created, it can be configured in the same way as a serial interface.

Virtual template interfaces can be created and applied by various applications such as virtual profiles, virtual private dialup networks (VPDNs), PPP over ATM, protocol translation, and Multichassis Multilink PPP (MMP).

Cisco 10000 Series Router

You can configure up to 4095 total virtual template interfaces on the Cisco 10000 series router.

To ensure proper scaling and to minimize CPU utilization, we recommend the following virtual template interface settings:

• A keepalive timer of 30 seconds or greater using the keepalive command. The default is 10 seconds.
• Do not enable the Cisco Discovery Protocol (CDP). CDP is disabled by default. Use the no cdp enable command to disable CDP, if necessary.
• Disable link-status event messaging using the no logging event link-status command.
• To prevent the virtual-access subinterfaces from being registered with the SNMP functionality of the router and using memory, do not use the router’s SNMP management tools to monitor PPP sessions. Use the no virtual-template snmp command to disable the SNMP management tools.

When a virtual template interface is applied dynamically to an incoming user session, a virtual access interface (VAI) is created.

If you configure a virtual template interface with interface-specific commands, the Cisco 10000 series router does not achieve the highest possible scaling. To verify that the router does not have interface-specific commands within the virtual template interface configuration, use the t est virtual-template number subinterface command.

Examples

Cisco 10000 Series Router

The following example creates a virtual template interface called Virtual-Template1:

Virtual Template with PPP Authentication Example

The following example creates and configures virtual template interface 1:

IPsec Virtual Template Example

The following example shows how to configure a virtual template for an IPsec virtual tunnel interface.

 

Related Commands

 

Syntax Description

 

Command Default

No default behavior or values.

 

Command History

 

Usage Guidelines

Use the ip address negotiated interface command to enable a Cisco router to automatically negotiate its own registered WAN interface IP address from a central server (via PPP/IPCP) and to enable all remote hosts to access the global Internet using this single registered IP address.

Examples

The following example configures an asynchronous interface (interface async1) to obtain its IP address via PPP/IPCP address negotiation:

 

Related Commands

 

Syntax Description

 

Command Default

IP address pooling is disabled globally.

 

Command History

 

Usage Guidelines

The global default IP address pooling mechanism applies to all interfaces that have been left in the default setting of the peer default ip address command.

If any peer default ip address command other than peer default ip address pool (the default) is configured, the interface uses that mechanism and not the global default mechanism. Thus all interfaces can be independently configured, or left unconfigured so that the global default configuration applies. This flexibility minimizes the configuration effort on the part of the administrator.

The ip address-pool dhcp-pool command supports only remote access PPP sessions using an MPLS VPN. IP addresses are obtained from locally configured VRF-associated DHCP pools. A VRF VPN instance is a per-VPN routing information repository that defines the VPN membership of a customer site.

Examples

The following example specifies the DHCP on-demand address pooling mechanism as the global default mechanism for assigning peer IP addresses:

The following example specifies the DHCP proxy client mechanism as the global default mechanism for assigning peer IP addresses:

The following example specifies a local IP address pool named “default” as the global default mechanism for all interfaces that have been left in their default setting:

 

Related Commands

 

Syntax Description

 

Command Default

0 DHCP Inform and Discover messages (network discovery is disabled when both the informs and discovers keywords are set to 0); 15-second timeout period.

 

Command History

 

Usage Guidelines

The ip dhcp-client network-discovery command allows peer routers to dynamically discover Domain Name System (DNS) and NetBIOS name server information configured on a DHCP server using PPP IP Control Protocol (IPCP) extensions. Setting the number of DHCP Inform or Discover messages to 1 or 2 determines how many times the system sends a DHCP Inform or Discover message before stopping network discovery, as follows:

• When the number of DHCP Inform messages is set to 1, once the first Inform messages is sent the system waits for a response from the DHCP server for the specified timeout period. If there is no response from the DHCP server by the end of the timeout period, the system sends a DHCP Discover message when the number of Discover messages is not set to 0. If the number of Discover messages is set to 1, network discovery stops. If the number of Discover messages is set to 2, the system waits again for a response from the DHCP server for the specified timeout period. If there is no response from the DHCP server by the end of this second timeout period, the system sends a second DHCP Discover message and stops network discovery.
• When the number of DHCP Inform messages is set to 2, once the first Inform messages is sent, the system waits for a response from the DHCP server for the specified timeout period. If there is no response from the DHCP server by the end of the timeout period, the system sends another DHCP Inform message. If the number of Discover messages is set to 1, network discovery stops. If the number of Discover messages is set to 2, the system waits again for a response from the DHCP server for the specified timeout period. If there is no response from the DHCP server by the end of this second timeout period, the system sends a second DHCP Discover message and stops network discovery.

Network discovery also stops when the DHCP server responds to DHCP Inform and Discover messages before the configured number of messages and timeout period are exceeded.

Setting the number of messages to 0 disables sending of DHCP Inform and Discover messages, and is the same as entering the no ip dhcp-client network-discovery command. When the ip dhcp-client network-discovery command is disabled, the system falls back to the static configurations made using the async-bootp dns-server and async-bootp nb-server global configuration commands or, as a last resort, to a DNS server address assigned with the ip name-server command.

Examples

The following example sets two DHCP Inform and Discovery messages and a timeout period of
12 seconds:

 

Related Commands

 

Syntax Description

 

Command Default

No routes are associated with a track number.

 

Command History

 

Usage Guidelines

The ip dhcp client command must be configured before the ip address dhcp command is configured on an interface. The ip dhcp client command is checked only when an IP address is acquired from DHCP. If the ip dhcp client command is specified after an IP address has been acquired from DHCP, the ip dhcp client command will not take effect until the next time the router acquires an IP address from DHCP.

Examples

The following example configures DHCP on an Ethernet interface and associates tracked object 123 with routes generated from this interface:

 

Related Commands

 

Syntax Description

 

Command Default

The IP limited broadcast address of 255.255.255.255 is used for transactions if no DHCP server is specified. This default allows automatic detection of DHCP servers.

 

Command History

 

Usage Guidelines

A DHCP server temporarily allocates network addresses to clients through the access server on an as-needed basis. While the client is active, the address is automatically renewed in a minimum of 20-minute increments. When the user terminates the session, the interface connection is terminated so that network resources can be quickly reused. You can specify up to ten servers on the network.

In normal situations, if a SLIP or PPP session fails (for example, if a modem line disconnects), the allocated address will be reserved temporarily to preserve the same IP address for the client when dialed back into the server. This way, the session that was accidentally terminated can often be resumed.

To use the DHCP proxy-client feature, enable your access server to be a proxy-client on asynchronous interfaces by using the ip address-pool dhcp-proxy-client command. If you want to specify which DHCP servers are used on your network, use the ip dhcp-server command to define up to ten specific DHCP servers.

Note To facilitate transmission, configure intermediary routers (or access servers with router functionality) to use an IP helper address whenever the DHCP server is not on the local LAN and the access server is using broadcasts to interact with the DHCP server. Refer to the chapters about configuring IP addressing in the Cisco IOS IP Addressing Services Configuration Guide.

The ip address-pool dhcp-proxy-client command initializes proxy-client status to all interfaces defined as asynchronous on the access server. To selectively disable proxy-client status on a single asynchronous interface, use the no peer default ip address interface command.

Examples

The following command specifies a DHCP server with the IP address of 172.24.13.81:

 

Related Commands

 

Syntax Description

 

Command Default

No default behavior or values.

 

Command History

 

Usage Guidelines

The ip idle-group command is applied to a virtual template interface and configures interesting traffic on either inbound or outbound traffic.

Examples

The following example specifies access list 101 as interesting for inbound IP traffic and access list 102 as interesting for outbound IP traffic:

 

Related Commands

 

Syntax Description

 

Command Default

No address pools are configured. Any pool created without the optional group keyword is a member of the base system group.

 

Command History

 

Usage Guidelines

Use the ip local pool command to create one or more local address pools from which IP addresses are assigned when a peer connects. You may also add another range of IP addresses to an existing pool. To use a named IP address pool on an interface, use the peer default ip address pool interface configuration command. A pool name can also be assigned to a specific user using authentication, authorization, and accounting (AAA) RADIUS and TACACS functions.

If no named local IP address pool is created, a default address pool is used on all point-to-point interfaces after the ip address-pool local global configuration command is issued. If no explicit IP address pool is assigned, but pool use is requested by use of the ip address-pool local command, the special pool named “default” is used.

The optional group keyword and associated group name allows the association of an IP address pool with a named group. Any IP address pool created without the group keyword automatically becomes a member of a base system group.

The optional recycle delay keyword and its associated time indicates the time in seconds to hold the IP address from the pool before making it available for reuse.

An IP address pool name can be associated with only one group. Subsequent use of the same pool name, within a pool group, is treated as an extension of that pool, and any attempt to associate an existing local IP address pool name with a different pool group is rejected. Therefore, each use of a pool name is an implicit selection of the associated pool group.

Note To reduce the chances of inadvertent generation of duplicate addresses, the system allows creation of the special pool named “default” only in the base system group, that is, no group name can be specified with the pool name “default.”

All IP address pools within a pool group are checked to prevent overlapping addresses; however, no checks are made between any group pool member and a pool not in a group. The specification of a named pool within a pool group allows the existence of overlapping IP addresses with pools in other groups, and with pools in the base system group, but not among pools within a group. Otherwise, processing of the IP address pools is not altered by their membership in a group. In particular, these pool names can be specified in peer commands and returned in RADIUS and AAA functions with no special processing.

IP address pools can be associated with Virtual Private Networks (VPNs). This association permits flexible IP address pool specifications that are compatible with a VPN and a VPN routing and forwarding (VRF) instance.

The IP address pools can also be used with the translate commands for one-step vty-async connections and in certain AAA or TACACS+ authorization functions. Refer to the chapter “Configuring Protocol Translation and Virtual Asynchronous Devices” in the Cisco IOS Terminal Services Configuration Guide and the “System Management” part of the Cisco IOS Configuration Fundamentals Configuration Guide for more information.

IP address pools are displayed with the show ip local pool EXEC command.

Examples

The following example creates a local IP address pool named “pool2,” which contains all IP addresses in the range 172.16.23.0 to 172.16.23.255:

The following example configures a pool of 1024 IP addresses:

Note Although not required, it is good practice to precede local pool definitions with a no form of the command to remove any existing pool, because the specification of an existing pool name is taken as a request to extend that pool with the new IP addresses. If the intention is to extend the pool, the no form of the command is not applicable.

The following example configures multiple ranges of IP addresses into one pool:

The following examples show how to configure two pool groups and IP address pools in the base system group:

In the example:

• Group grp1 consists of pools p1-g1, p2-g1, and p3-g1.
• Group grp2 consists of pools p1-g2 and p2-g2.
• Pools lp1 and lp2 are not associated with a group and are therefore members of the base system group.

Note that IP address 10.1.1.1 overlaps groups grp1, grp2, and the base system group. Also note that there is no overlap within any group including the base system group, which is unnamed.

The following examples show configurations of IP address pools and groups for use by a VPN and VRF:

The examples show configuration of two pool groups, including pools in the base system group, as follows:

• Group vpn1 consists of pools p1-vpn1, p2-vpn1, and p3-vpn1.
• Group vpn2 consists of pools p1-vpn2 and p2-vpn2.
• Pools lp1 and lp2 are not associated with a group and are therefore members of the base system group.

Note that IP address 10.1.1.1 overlaps groups vpn1, vpn2, and the base system group. Also note that there is no overlap within any group including the base system group, which is unnamed.

The VPN needs a configuration that selects the proper group by selecting the proper pool based on remote user data. Thus, each user in a given VPN can select an address space using the pool and associated group appropriate for that VPN. Duplicate addresses in other VPNs (other group names) are not a concern, because the address space of a VPN is specific to that VPN.

In the example, a user in group vpn1 is associated with some combination of the pools p1-vpn1, p2-vpn1, and p3-vpn1, and is allocated addresses from that address space. Addresses are returned to the same pool from which they were allocated.

The following example configures a recycle delay of 30 seconds to hold IP addresses in the pool before making them available for reuse:

 

Related Commands

 

Syntax Description

 

Command Default

No static routes are established.

 

Command History

 

Usage Guidelines

The establishment of a static route is appropriate when the Cisco IOS software cannot dynamically build a route to the destination.

When you specify a DHCP server to assign a static route, the interface type and number and administrative distance may be configured also.

If you specify an administrative distance, you are flagging a static route that can be overridden by dynamic information. For example, routes derived with Enhanced Interior Gateway Routing Protocol (EIGRP) have a default administrative distance of 100. To have a static route that would be overridden by an EIGRP dynamic route, specify an administrative distance greater than 100. Static routes have a default administrative distance of 1.

Static routes that point to an interface on a connected router will be advertised by way of Routing Information Protocol (RIP) and EIGRP regardless of whether redistribute static commands are specified for those routing protocols. This situation occurs because static routes that point to an interface are considered in the routing table to be connected and hence lose their static nature. Also, the target of the static route should be included in the network (DHCP) command. If this condition is not met, no dynamic routing protocol will advertise the route unless a redistribute static command is specified for these protocols. With the following configuration:

• RIP and EIGRP redistribute the route if the route is pointing to the Fast Ethernet interface:

RIP and EIGRP do not redistribute the route with the following ip route command because of the split horizon algorithm:

• EIGRP redistributes the route with both of the following commands:

With the Open Shortest Path First (OSPF) protocol, static routes that point to an interface are not advertised unless a redistribute static command is specified.

Adding a static route to an Ethernet or other broadcast interface (for example, ip route 0.0.0.0 0.0.0.0 Ethernet 1/2) will cause the route to be inserted into the routing table only when the interface is up. This configuration is not generally recommended. When the next hop of a static route points to an interface, the router considers each of the hosts within the range of the route to be directly connected through that interface, and therefore it will send Address Resolution Protocol (ARP) requests to any destination addresses that route through the static route.

A logical outgoing interface, for example, a tunnel, needs to be configured for a static route. If this outgoing interface is deleted from the configuration, the static route is removed from the configuration and hence does not show up in the routing table. To have the static route inserted into the routing table again, configure the outgoing interface once again and add the static route to this interface.

The practical implication of configuring the ip route 0.0.0.0 0.0.0.0 ethernet 1/2 command is that the router will consider all of the destinations that the router does not know how to reach through some other route as directly connected to Ethernet interface 1/2. So the router will send an ARP request for each host for which it receives packets on this network segment. This configuration can cause high processor utilization and a large ARP cache (along with memory allocation failures). Configuring a default route or other static route that directs the router to forward packets for a large range of destinations to a connected broadcast network segment can cause your router to reload.

Specifying a numerical next hop that is on a directly connected interface will prevent the router from using proxy ARP. However, if the interface with the next hop goes down and the numerical next hop can be reached through a recursive route, you may specify both the next hop and interface (for example, ip route 0.0.0.0 0.0.0.0 ethernet 1/2 10.1.2.3) with a static route to prevent routes from passing through an unintended interface.

Note Configuring a default route that points to an interface, such as ip route 0.0.0.0 0.0.0.0 ethernet 1/2, displays a warning message. This command causes the router to consider all the destinations that the router cannot reach through an alternate route, as directly connected to Ethernet interface 1/2. Hence, the router sends an ARP request for each host for which it receives packets on this network segment. This configuration can cause high processor utilization and a large ARP cache (along with memory allocation failures). Configuring a default route or other static route that directs the router to forward packets for a large range of destinations to a connected broadcast network segment can cause the router to reload.

The name next-hop-name keyword and argument combination allows you to associate static routes with names in your running configuration. If you have several static routes, you can specify names that describe the purpose of each static route in order to more easily identify each one.

The track number keyword and argument combination specifies that the static route will be installed only if the state of the configured track object is up.

Recursive Static Routing

In a recursive static route, only the next hop is specified. The output interface is derived from the next hop.

For the following recursive static route example, all destinations with the IP address prefix address prefix 192.168.1.1/32 are reachable via the host with address 10.0.0.2:

ip route 192.168.1.1 255.255.255.255 10.0.0.2

A recursive static route is valid (that is, it is a candidate for insertion in the IPv4 routing table) only when the specified next hop resolves, either directly or indirectly, to a valid IPv4 output interface, provided the route does not self-recurse, and the recursion depth does not exceed the maximum IPv4 forwarding recursion depth.

The following example defines a valid recursive IPv4 static route:

The following example defines an invalid recursive IPv4 static route. This static route will not be inserted into the IPv4 routing table because it is self-recursive. The next hop of the static route, 192.168.1.0/30, resolves via the first static route 192.168.1.0/24, which is itself a recursive route (that is, it only specifies a next hop). The next hop of the first route, 192.168.1.0/24, resolves via the directly connected route via the serial interface 2/0. Therefore, the first static route would be used to resolve its own next hop.

It is not normally useful to manually configure a self-recursive static route, although it is not prohibited. However, a recursive static route that has been inserted in the IPv4 routing table may become self-recursive as a result of some transient change in the network learned through a dynamic routing protocol. If this situation occurs, the fact that the static route has become self-recursive will be detected and the static route will be removed from the IPv4 routing table, although not from the configuration. A subsequent network change may cause the static route to no longer be self-recursive, in which case it will be re-inserted in the IPv4 routing table.

Note IPv4 recursive static routes are checked at one-minute intervals. Therefore, a recursive static route may take up to a minute to be inserted into the routing table once its next hop becomes valid. Likewise, it may take a minute or so for the route to disappear from the table if its next hop becomes invalid.

Examples

The following example shows how to choose an administrative distance of 110. In this case, packets for network 10.0.0.0 will be routed to a router at 172.31.3.4 if dynamic information with an administrative distance less than 110 is not available.

Note Specifying the next hop without specifying an interface when configuring a static route can cause traffic to pass through an unintended interface if the default interface goes down.

The following example shows how to route packets for network 172.31.0.0 to a router at 172.31.6.6:

The following example shows how to route packets for network 192.168.1.0 directly to the next hop at 10.1.2.3. If the interface goes down, this route is removed from the routing table and will not be restored unless the interface comes back up.

The following example shows how to install the static route only if the state of track object 123 is up:

The following example shows that using the dhcp keyword in a configuration of Ethernet interfaces 1 and 2 enables the interfaces to obtain the next-hop router IP addresses dynamically from a DHCP server:

The following example shows that using the name next-hop-name keyword and argument combination for each static route in the configuration helps you remember the purpose for each static route.

The name for the static route will be displayed when the show running-configuration command is entered:

 

Related Commands

 

Syntax Description

 

Command Default

No static route is established.

 

Command History

 

Usage Guidelines

A static route is appropriate when the communication server cannot dynamically build a route to the destination.

If you specify an administrative distance, you are flagging a static route that can be overridden by dynamic information. For example, Interior Gateway Routing Protocol (IGRP)-derived routes have a default administrative distance of 100. To have a static route that would be overridden by an IGRP dynamic route, specify an administrative distance greater than 100. Static routes have a default administrative distance of 1.

Static routes that point to an interface will be advertised using RIP, IGRP, and other dynamic routing protocols, regardless of whether redistribute static commands were specified for those routing protocols. These static routes will be advertised because static routes that point to an interface are considered to be connected in the routing table and hence lose their static nature. However, if you define a static route to an interface that is not in one of the networks defined in a network command, no dynamic routing protocols will advertise the route unless a redistribute static command is specified for these protocols.

The user profile name is passed to an authentication, authorization, and accounting (AAA) server as the next hop for large-scale dial-out, and is the name argument with the -out suffix appended. The suffix is automatically supplied and is required because dial-in and user profile names must be unique.

Examples

In the following example, an administrative distance of 110 was chosen. In this case, packets for network 10.0.0.0 will be routed via to the communication server at 172.19.3.4 if dynamic information with an administrative distance less than 110 is not available.

In the following example, packets for network 172.19.0.0 will be routed to the communication server at 172.19.6.6:

In the following example, the user profile named “profile1-out” will be retrieved from the AAA server:

 

Related Commands

 

Syntax Description

 

Command Default

This function is disabled by default. No default values are provided for the arguments.

 

Command History

 

Usage Guidelines

If the bandwidth needed for RTP packet flows exceeds the maximum bandwidth specified, the reserved queue will degrade to a best-effort queue.

This command helps in improving the delay bounds of voice streams by giving them a higher priority.

Note The ip rtp reserve command configuration is retained on the multilink interface on reloading the router. This is displayed in the show running-configuration interface multilink command output.

Examples

The following example reserves a unique queue for traffic to destination UDP ports in the range 32768 to 32788 and reserves 1000 kbps bandwidth for that traffic:

The following example shows the configuration for Multilink interface 7856:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Asynchronous listening is disabled (turned off).

 

Command History

 

Usage Guidelines

After asynchronous listening is turned on by the ip tcp async-mobility server command, use the tunnel command to establish a network layer connection to a remote host. Both commands must be used to enable asynchronous mobility.

Examples

The following example shows how to configure asynchronous mobility. The tunnel command is used to establish a network layer connection with an IBM host named “mktg.”

 

Related Commands

 

Syntax Description

 

Command Default

Telnet Com Port extensions are enabled

 

Command History

 

Usage Guidelines

RFC 2217 Telnet Com Port extensions are used to communicate modem hardware signal status from a modem on a network access server (NAS) to a TCP/IP client. An example would be a client PC using a package such as DialOut/EZ (Tacticalsoftware.com) to provide an emulated COM port via a TCP connection to a Cisco AS5000 NAS with integrated modems.

When Com Port extensions are enabled on the NAS, the binary Telnet option (RFC 856) should be used. The Telnet client must connect to TCP ports 6000+ for individual lines, or 7000+ for rotaries on the Cisco NAS.

Setting the Command to Avoid Interruptions

Although the default settings for the ip telnet comport command are suitable for most applications, in a few cases some settings should be changed for efficient communications. Two possible situations are described below.

• Preventing Data Buffer Overflows

Before the application can send data it must determine the modem’s readiness for transmission. This checking process generates some initial data. If many of these checks occur in a short period of time, the data will be buffered.

Command ip telnet comport can be set to prevent a buffer overflow from of these trivial data events. In this case, the ip telnet comport flow level (range: 1 through 1023) is adjusted. This enables the PC-hosted comm-serv to send a signal to the remote to prevent (SUSPEND) transmission of any data or commands. When the application is actually ready to receive data, the remote can start transmissions.

• Handling DTR Drops

When a Data Terminal Ready (DTR, a signal pin on a serial interface) is dropped during a communcation, the PC application may incorrectly interpret the event as an error. This situation can be prevented by changing the disconnect delay (range is 1 to 360 seconds) of command ip telnet comport. Adding this delay gives the application time to receive and properly act on the DTR drop message before the tcp connection is closed down.

Examples

The following example disables Telnet Com Port extensions:

 

Related Commands

 

Syntax Description

 

Command Default

IP addresses and host names are visible

 

Command History

 

Usage Guidelines

By default, when a Telnet client connects to the server, the client will display a message with the server IP address and host name, as shown in the following example:

The ip telnet hidden command can be configured to hide the IP address of the client or the host name of the client in the message. Configuring the ip telnet hidden addresses command results in the client displaying a message with the IP address of the server hidden, as shown in the following example:

Configuring the ip telnet hidden hostnames command results in the client displaying a message with the host name of the server hidden, as shown in the following example:

Configuring both the ip telnet hidden addresses and ip telnet hidden hostnames commands results in the client displaying a message with both the IP address and the host name of the server hidden, as shown in the following example:

Examples

The following example configures the Telnet client to hide both IP addresses and host name information when connecting to the server:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Telnet connection message suppression is disabled by default.

 

Command History

 

Usage Guidelines

The ip telnet quiet command does not suppress TCP or error messages. It is most useful to Internet service providers, to allow them to hide the onscreen messages displayed during connection, including Internet addresses, from subscription users.

Examples

The following example globally disables onscreen connect messages:

The following example shows the login and logout messages displayed during login and logout when the ip telnet quiet command has not been configured to suppress Cisco IOS software messages:

The following example shows the limited messages displayed during login and logout when the ip telnet quiet command has been configured to suppress Cisco IOS software messages:

 

Related Commands

 

Syntax Description

 

Command Default

no ip telnet timeout retransmit

 

Command History

 

Usage Guidelines

Configure the ip telnet timeout command to specify an explicit maximum period that TCP will attempt to retransmit a segment for a Telnet connection. For the default setting (no ip telnet timeout retransmit), TCP’s retransmit timeout will be based on the estimated round trip time for the connection (typically, seven or eight minutes).

Note If Telnet has no data to transmit, the TCP connection remains indefinitely (regardless of whether the other end is reachable), unless you configure TCP keepalives. This setting has an effect on connections using the Telnet protocol (whether inbound or outbound), not on connections using other protocols such as rlogin and ssh (secure shell).

Examples

The following example sets the TCP retransmit time to a value of 12 hours:

 

Related Commands

 

Syntax Description

 

Command Default

The default ToS value for Telnet packets is 0xC0.

 

Command History

 

Usage Guidelines

Compatibility with older Telnet clients may require the configuration of the ip telnet tos 0 command.

Examples

The following example configures a ToS precedence bit value of 0xF0 in the IP header:

The following example displays the output for an invalid ToS precedence value:

 

Related Commands

 

Syntax Description

 

Command Default

The address of the interface closest to the destination is selected as the source address.

 

Command History

Examples

The following example shows how to configure Virtual Multipoint Interface (VMI) for a UDPTN connection:

Router(config)# ip udptn source-interface vmi 23

 

Related Commands

 

Syntax Description

 

Command Default

No compression of IPX packets during a PPP session. Default number of slots is 16.

 

Command History

 

Usage Guidelines

This interface configuration command enables IPX header compression on PPP links.

Examples

The following example enables IPX header compression for PPP:

 

Related Commands

 

Syntax Description

 

Command Default

IPX client connections are not permitted over PPP.

 

Command History

 

Usage Guidelines

This command enables IPX clients to log in to the router from a device running a virtual terminal protocol, then issue the PPP command at the EXEC prompt to connect to a remote device.

You must first configure a loopback interface with a unique IPX network number. The loopback interface is then assigned to an asynchronous interface, which permits IPX clients to connect to the asynchronous interface.

Examples

The following example configures IPX to run over PPP on asynchronous interface 3:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

By default, ISDN interfaces answer calls as synchronous serial with PPP encapsulation.

 

Command History

 

Usage Guidelines

Use this command only when you want all incoming calls to be answered as V.120. If you want the interface to automatically detect whether the incoming call uses V.120 or PPP encapsulation, use the autodetect encapsulation command.

This command applies only when the incoming call originates on an asynchronous device and needs to terminate in an available vty on the router.

Examples

The following partial example shows that BRI 0 is configured to answer all calls as V.120:

 

Related Commands

 

Syntax Description

 

Command Default

The router does not verify the called party or subaddress number.

 

Command History

 

Usage Guidelines

If you do not specify the isdn answer1 or isdn answer2 command, all calls are processed or accepted. If you specify the isdn answer1 or isdn answer2 command, the router must verify the incoming called-party number and the subaddress before processing or accepting the call. The verification proceeds from right to left for the called-party number; it also proceeds from right to left for the subaddress number.

You can configure just the called-party number or just the subaddress. In such a case, only that part is verified. To configure a subaddress only, include the colon (:) before the subaddress number.

You can declare a digit a “don’t care” digit by configuring it as an x or X. In such a case, any incoming digit is allowed.

Examples

In the following example, 5550122 is the called-party number and 1234 is the subaddress:

In the following example, only the subaddress is configured:

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

The automatic detection of ISDN SPIDs and switch type is disabled.

 

Command History

 

Usage Guidelines

This command applies to North America only. If you are outside of North America, you must use the isdn switch-type (BRI) or isdn switch-type (PRI) interface configuration command to specify the ISDN switch type.

Examples

The following example enables the automatic detection of ISDN SPIDs and switch type:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

This command is disabled by default.

 

Command History

 

Usage Guidelines

This commands starts service audits for all triggers. Use the isdn bcac service audit trigger command to selectively enable and disable audit triggers.

Examples

The following example shows how to configure service audits on serial interface 2:23:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

The default can be to trigger audits on a single channel, a group of channels, or the entire interface, depending upon the type of trigger set. See the “Usage Guidelines” section for the isdn bcac service audit trigger command for the list of triggers.

 

Command History

 

Usage Guidelines

Use this command when the service audit needs to be triggered on the entire interface when a condition to trigger the service audit is triggered for any channel.

Examples

The following example shows how to configure service audits on serial interface 2:23:

 

Related Commands

 

Syntax Description

 

Command Default

All triggers are configured.

 

Command History

 

Usage Guidelines

The service audit procedure can be used by the either the user or network side to bring both ends of the interface into agreement about the service status through an exchange of SERV and SERV ACK messages.

Following is the list of triggers with the conditions that cause them. Triggers 1 through 4 are triggered by single-channel audits. Trigger 5 occurs on the entire interface. Trigger 6 applies to a group of channels, which in some cases may apply to the entire interface.

• Trigger 1: Upon receiving an incoming call indicating a channel that is in the out-of-service (OOS) or Maint (maintenance) state.
• Trigger 2: Upon receiving an unsolicited SERV ACK message when the received service status differs from the current status.
• Trigger 3: Upon receiving an unallowed response to a SERV message. An unallowed response means a SERV ACK message, which indicates a higher availability than was sent in the SERV message.
• Trigger 4: Upon receiving an ISDN call clearing message with cause code 44 (requested channel not available) when this message is not caused by “glare,” which is a SETUP message collision requesting the same channel.
• Trigger 5: Once every 24 hours on all channels.
• Trigger 6: Once every hour on all channels that are in the OOS or Far-end state.

Examples

The following example shows how to disable service trigger 4 on serial interface 2:23:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

Original service state is maintained.

 

Command History

 

Usage Guidelines

Use this command when there is a need to change the service state of a channel to In Service when no acknowledgment is received, even after retransmitting the service message the maximum number of allowed times. If this command is not configured, the original service state is maintained.

Examples

The following example shows how to configure an option whereby, on service message exchange failure, the service state of the concerned channel or channels will be set to In Service:

 

Related Commands

 

Syntax Description

 

Command Default

Maximum retransmissions is 2.

 

Command History

 

Usage Guidelines

When a SERV message is sent to the far side, SERV message timer T3M1 or T323 is started. If no SERV ACK message is received before these timers expire, the SERV message is retransmitted. This command determines how many times retransmission occurs.

Examples

The following example shows how to set the maximum service message retransmissions on serial interface 2:23 to 50:

 

Related Commands

 

Syntax Description

 

Command Default

The T3M1 or T323 service message timer defaults to 120000 ms.

 

Command History

 

Usage Guidelines

The T3M1 or T323 service message timer is started when a SERV message is sent to the far side.

Examples

The following example shows how to change the service timers to 600 ms on serial interface 2:23:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

This command is disabled by default.

 

Command History

 

Usage Guidelines

This command updates the service states of all the channels to the far side of the interface by exchanging SERV and SERV ACK messages whenever ISDN Layer 2 comes up.

Use the isdn bcac service update linkup command to bring the service state of the channels on the interface in synchronization with its peer through the exchange of SERV messages. This synchronizing of the service states will be triggered whenever ISDN Layer 2 comes up. This command can be used with the isdn service command in cases where the service state of the channels needs to be synchronized when the ISDN Layer 2 comes up, and in particular, when the ISDN Layer 2 comes up after the router has reloaded.

Examples

The following example shows how to trigger service state updates on serial interface 2:23:

 

Related Commands

 

Syntax Description

This command has no arguments or keywords.

 

Command Default

This command is disabled by default.

 

Command History

 

Usage Guidelines

This command enables functionality of service status for provisioning the B channels, which for the Cisco implementation happens only on reboot.

Examples

The following example shows how to enable the service service status for provisioning the B channels on serial interface 2:23:

 

Related Commands

 

Syntax Description

 

Command Default

Selection default is ascending for the network side; descending for the user side.

 

Command History

 

Usage Guidelines

This command supports ascending, descending, and round-robin B-channel selection schemes. This command is for PRI configuration only.

This command supports ascending and descending B-channel selection by instructing the router to select the lowest or highest available B channel starting at either channel B1 (ascending) or channel B23 for a T1 and channel B31 for an E1 (descending).

In the ascending B-channel selection scheme, for example, if the channel selected for the last call was channel 14, then if channel x, where x is any channel number less than or equal to 14, becomes available by the time a channel is selected for the next call, that channel will be selected for the call.

In the round-robin B-channel selection scheme, the next channel selected is the current channel number x plus 1 for ascending, or current channel number x minus 1 for descending configuration.

When the channel selection software routine reaches channel 1 (the bottom for descending) or channel 23 for T1 and channel 31 for E1 (the top for ascending), the software routine wraps around. An example for a descending configuration: After reaching channel 1, the routine goes back to channel 31 or 23 and then decrements the count from there.

Examples

The following example configures the outgoing B-channel order on a PRI interface to be in ascending order. The router will select the lowest available B channel beginning with channel B1.

The following example configures the outgoing B-channel order on a PRI interface to be round-robin in ascending order.

 

Syntax Description

 

Command Default

Disabled

 

Command History

 

Usage Guidelines

This command gives the impression that a call is active when the channel is actually idle.

Use the b_channel 0 keywords to set a false busy signal on the entire interface.

Use the show isdn command with the status keyword to display the DSL number and channel state.

Examples

The following example sets the entire PRI interface to a false busy signal; the DSL number was obtained using the show isdn command with the status keyword, and then used in the command.

The following example sets the false busy signal on B channel 11; the DSL number was obtained using the show isdn command with the status keyword, and then used in the command.

 

Related Commands