Document ID: 51161
Updated: Feb 04, 2010
Contents
Introduction
This document describes how to configure an Access Server with virtual template and dialer profile interfaces.
Mixing dialer profile and virtual template interfaces is useful when an incoming user’s connection needs a specific configuration such as routing, timeout, access-list; the dialer profile interface is used for that. This dialer profile interface can be used for outgoing calls.
The other incoming users' connections, for which no specific configuration is required, use the virtual template interface.
Note: These requirements can be also achieved with a per-user configuration with an Authentication, Authorization, and Accounting (AAA) server.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This configuration was developed and tested using Cisco IOS® Software Release 12.3(5) on an AS5300. However, different hardware versions can be used. For example, this document uses an E1 interface but T1 or BRI interfaces can also be used.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to Cisco Technical Tips Conventions.
Background Information
The following example explains how the dialer profile or the virtual template interface is selected by the Access Server for incoming calls:
-
A remote ISDN client dials in the Access Server. It uses clientX as username for Challenge Handshake Authentication Protocol (CHAP) authentication.
-
The authentication phase is taking place, the username (clientX) and the password are received on the D channel interface serial0:15.
-
The IOS software checks whether it can find the command dialer remote-name clientX in a dialer profile interface:
-
If yes, then the dialer profile interface in which dialer remote-name clientX is configured is used to bind the call.
-
If no, then the virtual template is used to bind the call.
-
Some more general information can be found at Virtual Profiles.
Configure
In this section, you are presented with the information to configure the features described in this document.
Note: To find additional information on the commands used in this document, use the Command Lookup Tool (registered customers only) .
Network Diagram
This setup uses ISDN incoming calls. However, this type of configuration can also be used for analog incoming calls. The router named "central" is also able to call client1 and client2.
When dialing into the router central:
-
client1 uses the dialer profile interface dialer1.
-
client2 uses the dialer profile interface dialer2.
-
client3 uses the virtual template 1 (a virtual-access is cloned from the virtual template).
Note: Due to Cisco Bug ID CSCdu05390, it is mandatory to configure a minimum of two dialer-pool interfaces. A router configured with a single dialer profile interface binds all incoming calls to that profile by default, and the virtual template is never utilized for any call.
Configurations
This document uses this configuration:
| Router |
|---|
version 12.3 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname central ! boot-start-marker boot-end-marker ! enable password cisco ! username client1 password 0 cisco1 username client2 password 0 cisco2 username client3 password 0 cisco3 spe 1/0 2/9 firmware location system:/ucode/mica_port_firmware ! ! resource-pool disable ! no aaa new-model ip subnet-zero no ip domain lookup ! virtual-profile virtual template 1 isdn switch-type primary-net5 ! ! ! controller E1 0 clock source line primary pri-group timeslots 1-31 ! controller E1 1 ! controller E1 2 ! controller E1 3 ! ! interface Loopback0 ip address 10.0.0.1 255.255.255.255 ! interface Ethernet0 ! interface virtual template1 !--- Description used for remote users other than !--- client1 and client2. ip unnumbered Loopback0 peer default ip address pool POOL1 ppp authentication chap ! interface Serial0:15 no ip address encapsulation ppp dialer pool-member 1 isdn switch-type primary-net5 isdn incoming-voice modem ppp authentication chap ! interface FastEthernet0 ip address 10.48.74.0 255.255.255.255 duplex auto speed auto ! interface Group-Async1 ip unnumbered Loopback0 encapsulation ppp async mode interactive peer default ip address pool POOL1 ppp authentication chap group-range 1 120 ! interface Dialer1 description used for router client1 ip unnumbered Loopback0 encapsulation ppp dialer pool 1 dialer remote-name client1 dialer string 8101 dialer-group 1 ppp authentication chap ! interface Dialer2 description used for router client2 ip unnumbered Loopback0 encapsulation ppp dialer pool 1 dialer remote-name client2 dialer string 8102 dialer-group 1 no cdp enable ppp authentication chap ! ip local pool POOL1 10.0.0.2 10.0.0.254 ip classless ip route 192.168.1.0 255.255.255.0 Dialer1 no ip http server no ip http secure-server ! dialer-list 1 protocol ip permit no cdp run ! line con 0 exec-timeout 0 0 line 1 120 modem InOut transport input all autoselect ppp line aux 0 line vty 0 4 exec-timeout 0 0 login ! end |
Verify
There is currently no verification procedure available for this configuration.
Troubleshoot
This section provides information you can use to troubleshoot your configuration.
Troubleshooting Commands
Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.
Note: Before issuing debug commands, refer to Important Information on Debug Commands.
The following debugs are turned on:
-
debug isdn q931—display information about call setup and teardown of ISDN network connections (Layer 3) between the local router (user side) and the network.
-
debug dialer events—display debugging information about the packets received on a dialer interface.
-
debug ppp negotiation— display PPP packets transmitted during PPP startup, where PPP options are negotiated.
The output below shows calls from client1 and client3.
Client1 dials in:
!--– Incoming ISDN call from the number 8101.
central#
*Mar 31 09:39:13.377: ISDN Se0:15 Q931: RX <- SETUP pd = 8 callref = 0x4DA5
Sending Complete
Bearer Capability i = 0x8890
Standard = CCITT
Transer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA1838C
Preferred, Channel 12
Calling Party Number i = 0xA1, '8101'
Plan:ISDN, Type:National
Called Party Number i = 0x81, '7050'
Plan:ISDN, Type:Unknown
Locking Shift to Codeset 6
Codeset 6 IE 0x28 i = 'TAC BRI 8101'
!--– The interface Serial0:11 is used.
*Mar 31 09:39:13.393: %LINK-3-UPDOWN: Interface Serial0:11, changed state to up
*Mar 31 09:39:13.397: ISDN Se0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xCDA5
Channel ID i = 0xA9838C
Exclusive, Channel 12
*Mar 31 09:39:13.397: ISDN Se0:15 Q931: TX -> CONNECT pd = 8 callref = 0xCDA5
Channel ID i = 0xA9838C
Exclusive, Channel 12
*Mar 31 09:39:13.397: Se0:11 PPP: Using dialer call direction
*Mar 31 09:39:13.397: Se0:11 PPP: Treating connection as a callin
*Mar 31 09:39:13.397: Se0:11 PPP: Phase is ESTABLISHING, Passive Open
*Mar 31 09:39:13.397: Se0:11 LCP: State is Listen
*Mar 31 09:39:13.429: ISDN Se0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x4DA5
!--– LCP PPP is starting.
*Mar 31 09:39:13.485: Se0:11 LCP: I CONFREQ [Listen] id 64 len 15
*Mar 31 09:39:13.485: Se0:11 LCP: AuthProto CHAP (0x0305C22305)
*Mar 31 09:39:13.485: Se0:11 LCP: MagicNumber 0x19D7AA87 (0x050619D7AA87)
*Mar 31 09:39:13.485: Se0:11 LCP: O CONFREQ [Listen] id 7 len 15
*Mar 31 09:39:13.485: Se0:11 LCP: AuthProto CHAP (0x0305C22305)
*Mar 31 09:39:13.485: Se0:11 LCP: MagicNumber 0x162B43FB (0x0506162B43FB)
*Mar 31 09:39:13.489: Se0:11 LCP: O CONFACK [Listen] id 64 len 15
*Mar 31 09:39:13.489: Se0:11 LCP: AuthProto CHAP (0x0305C22305)
*Mar 31 09:39:13.489: Se0:11 LCP: MagicNumber 0x19D7AA87 (0x050619D7AA87)
*Mar 31 09:39:13.501: Se0:11 LCP: I CONFACK [ACKsent] id 7 len 15
*Mar 31 09:39:13.501: Se0:11 LCP: AuthProto CHAP (0x0305C22305)
*Mar 31 09:39:13.501: Se0:11 LCP: MagicNumber 0x162B43FB (0x0506162B43FB)
*Mar 31 09:39:13.501: Se0:11 LCP: State is Open
*Mar 31 09:39:13.505: Se0:11 PPP: Phase is AUTHENTICATING, by both
!--– Central sends a CHAP challenge to the remote CPE
!--- and gets a response : the username is client1.
*Mar 31 09:39:13.505: Se0:11 CHAP: O CHALLENGE id 5 len 28 from "central"
*Mar 31 09:39:13.509: Se0:11 CHAP: I CHALLENGE id 60 len 28 from "client1"
*Mar 31 09:39:13.509: Se0:11 CHAP: Waiting for Peer to authenticate first
*Mar 31 09:39:13.525: Se0:11 CHAP: I RESPONSE id 5 len 28 from "client1"
*Mar 31 09:39:13.525: Se0:11 PPP: Phase is FORWARDING, Attempting Forward
*Mar 31 09:39:13.525: Se0:11 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Mar 31 09:39:13.529: Se0:11 PPP: Phase is FORWARDING, Attempting Forward
*Mar 31 09:39:13.529: Se0:11 PPP: Phase is AUTHENTICATING, Authenticated User
!--– Since client1 is found in the dialer 1 interface,
!--- the call is bind to this interface.
*Mar 31 09:39:13.529: Se0:11 DDR: Remote name for client1
*Mar 31 09:39:13.529: Se0:11: interface must be fifo queue, force fifo
*Mar 31 09:39:13.529: %DIALER-6-BIND: Interface Se0:11 bound to profile Di1
*Mar 31 09:39:13.533: Se0:11 CHAP: Using hostname from unknown source
*Mar 31 09:39:13.533: Se0:11 CHAP: Using password from AAA
!--– Central validates the response to client1 successfully.
*Mar 31 09:39:13.533: Se0:11 CHAP: O RESPONSE id 60 len 28 from "central"
*Mar 31 09:39:13.533: Se0:11 CHAP: O SUCCESS id 5 len 4
*Mar 31 09:39:13.549: Se0:11 CHAP: I SUCCESS id 60 len 4
*Mar 31 09:39:13.549: Se0:11 PPP: Phase is UP
!--– IPCP is starting.
*Mar 31 09:39:13.549: Se0:11 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar 31 09:39:13.549: Se0:11 IPCP: Address 10.0.0.1 (0x03060A000001)
*Mar 31 09:39:13.549: Se0:11 PPP: Process pending ncp packets
*Mar 31 09:39:13.553: Se0:11 IPCP: I CONFREQ [REQsent] id 60 len 10
*Mar 31 09:39:13.557: Se0:11 IPCP: Address 192.168.1.1 (0x0306C0A80101)
*Mar 31 09:39:13.557: Se0:11 AAA/AUTHOR/IPCP: Start. Her address 192.168.1.1,
we want 0.0.0.0
*Mar 31 09:39:13.557: Se0:11 AAA/AUTHOR/IPCP: Reject 192.168.1.1, using 0.0.0.0
*Mar 31 09:39:13.557: Se0:11 AAA/AUTHOR/IPCP: Done. Her address 192.168.1.1,
we want 0.0.0.0
*Mar 31 09:39:13.557: Se0:11 IPCP: O CONFACK [REQsent] id 60 len 10
*Mar 31 09:39:13.557: Se0:11 IPCP: Address 192.168.1.1 (0x0306C0A80101)
*Mar 31 09:39:13.557: Se0:11 CDPCP: I CONFREQ [Not negotiated] id 60 len 4
*Mar 31 09:39:13.557: Se0:11 LCP: O PROTREJ [Open] id 8 len 10 protocol CDPCP
(0x8207013C0004)
*Mar 31 09:39:13.561: Se0:11 IPCP: I CONFACK [ACKsent] id 1 len 10
*Mar 31 09:39:13.561: Se0:11 IPCP: Address 10.0.0.1 (0x03060A000001)
*Mar 31 09:39:13.561: Se0:11 IPCP: State is Open
!--– The route to client1 is installed
*Mar 31 09:39:13.565: Di1 IPCP: Install route to 192.168.1.1
*Mar 31 09:39:13.565: Se0:11 IPCP: Add link info for cef entry 192.168.1.1
*Mar 31 09:39:13.565: Se0:11 DDR: dialer protocol up
*Mar 31 09:39:14.549: %LINEPROTO-5-UPDOWN:
Line protocol on Interface Serial0:11, changed state to up
*Mar 31 09:39:19.393: %ISDN-6-CONNECT:
Interface Serial0:11 is now connected to 8101 client1
central#show caller user client1 detailed
User: client1, line Se0:11, service PPP
Connected for 00:00:55, Idle for 00:00:49
Timeouts: Limit Remaining Timer Type
00:02:00 00:01:10 Dialer idle
PPP: LCP Open, CHAP (<-->), IPCP
LCP: -> peer, AuthProto, MagicNumber
<- peer, AuthProto, MagicNumber
NCP: Open IPCP
IPCP: <- peer, Address
-> peer, Address
Dialer: Connected 01:10:19 to 8101, inbound
Type is ISDN, group Di1
IP: Local 10.0.0.1, remote 192.168.1.1
Counts: 121 packets input, 2660 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
119 packets output, 2395 bytes, 0 underruns
0 output errors, 0 collisions, 14 interface resets
Client 3 dials in :
!--– Incoming ISDN call from the number 8102.
central#
*Mar 31 09:47:39.925: ISDN Se0:15 Q931: RX <- SETUP pd = 8 callref = 0x4EB0
Sending Complete
Bearer Capability i = 0x8890
Standard = CCITT
Transer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA1838D
Preferred, Channel 13
Calling Party Number i = 0xA1, '8102'
Plan:ISDN, Type:National
Called Party Number i = 0x81, '7050'
Plan:ISDN, Type:Unknown
Locking Shift to Codeset 6
Codeset 6 IE 0x28 i = 'TAC BRI 8102'
!--– The interface Serial0:12 is used.
*Mar 31 09:47:39.941: %LINK-3-UPDOWN: Interface Serial0:12, changed state to up
*Mar 31 09:47:39.941: ISDN Se0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xCEB0
Channel ID i = 0xA9838D
Exclusive, Channel 13
*Mar 31 09:47:39.941: ISDN Se0:15 Q931: TX -> CONNECT pd = 8 callref = 0xCEB0
Channel ID i = 0xA9838D
Exclusive, Channel 13
*Mar 31 09:47:39.945: Se0:12 PPP: Using dialer call direction
*Mar 31 09:47:39.945: Se0:12 PPP: Treating connection as a callin
*Mar 31 09:47:39.945: Se0:12 PPP: Phase is ESTABLISHING, Passive Open
*Mar 31 09:47:39.945: Se0:12 LCP: State is Listen
*Mar 31 09:47:39.969: ISDN Se0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x4EB0
!--– LCP PPP is starting.
*Mar 31 09:47:40.041: Se0:12 LCP: I CONFREQ [Listen] id 141 len 10
*Mar 31 09:47:40.041: Se0:12 LCP: MagicNumber 0x096F6EEF (0x0506096F6EEF)
*Mar 31 09:47:40.041: Se0:12 LCP: O CONFREQ [Listen] id 6 len 15
*Mar 31 09:47:40.041: Se0:12 LCP: AuthProto CHAP (0x0305C22305)
*Mar 31 09:47:40.041: Se0:12 LCP: MagicNumber 0x1632FEB9 (0x05061632FEB9)
*Mar 31 09:47:40.041: Se0:12 LCP: O CONFACK [Listen] id 141 len 10
*Mar 31 09:47:40.041: Se0:12 LCP: MagicNumber 0x096F6EEF (0x0506096F6EEF)
*Mar 31 09:47:40.077: Se0:12 LCP: I CONFACK [ACKsent] id 6 len 15
*Mar 31 09:47:40.077: Se0:12 LCP: AuthProto CHAP (0x0305C22305)
*Mar 31 09:47:40.077: Se0:12 LCP: MagicNumber 0x1632FEB9 (0x05061632FEB9)
*Mar 31 09:47:40.077: Se0:12 LCP: State is Open
*Mar 31 09:47:40.077: Se0:12 PPP: Phase is AUTHENTICATING, by this end
!--– Central sends a CHAP challenge to the remote
!--- CPE and gets a response : the username is client3.
*Mar 31 09:47:40.077: Se0:12 CHAP: O CHALLENGE id 5 len 28 from "central"
*Mar 31 09:47:40.113: Se0:12 CHAP: I RESPONSE id 5 len 28 from "client3"
*Mar 31 09:47:40.113: Se0:12 PPP: Phase is FORWARDING, Attempting Forward
*Mar 31 09:47:40.113: Se0:12 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Mar 31 09:47:40.113: Se0:12 PPP: Phase is FORWARDING, Attempting Forward
*Mar 31 09:47:40.113: Se0:12 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar 31 09:47:40.117: Se0:12 DDR: Remote name for client3
!--- The IOS does not find any dialer interface for client3.
*Mar 31 09:47:40.117: Se0:12 DDR: Authenticated host client3
with no matching dialer profile
!--- The IOS validates the response to client3 successfully.
*Mar 31 09:47:40.117: Se0:12 CHAP: O SUCCESS id 5 len 4
*Mar 31 09:47:40.117: Se0:12 PPP: Phase is FORWARDING
!--- Since there is no dialer pool interface
!--- matching client3, a virtual-access is cloned from the
!--- virtual template1. Here it is the virtual-access2.
*Mar 31 09:47:40.117: Vi2 PPP: Phase is DOWN, Setup
*Mar 31 09:47:40.117: Vi2 PPP: Phase is ESTABLISHING
*Mar 31 09:47:40.121: Se0:12 PPP: Phase is FORWARDED
!--- The virtual-access gets a copy of the last
!--- LCP CONFCAK packets exchanged between client3 and central
!--- when LCP has been negotiated.
*Mar 31 09:47:40.121: Vi2 LCP: I FORCED rcvd CONFACK len 11
*Mar 31 09:47:40.121: Vi2 LCP: AuthProto CHAP (0x0305C22305)
*Mar 31 09:47:40.121: Vi2 LCP: MagicNumber 0x1632FEB9 (0x05061632FEB9)
*Mar 31 09:47:40.121: Vi2 LCP: I FORCED sent CONFACK len 6
*Mar 31 09:47:40.121: Vi2 LCP: MagicNumber 0x096F6EEF (0x0506096F6EEF)
*Mar 31 09:47:40.121: Vi2 PPP: Phase is AUTHENTICATING, by this end
*Mar 31 09:47:40.121: Vi2 PPP: Phase is UP
!--- IPCP is starting.
*Mar 31 09:47:40.121: Vi2 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar 31 09:47:40.121: Vi2 IPCP: Address 10.0.0.1 (0x03060A000001)
*Mar 31 09:47:40.121: Vi2 PPP: Process pending ncp packets
*Mar 31 09:47:40.121: Se0:12 PPP: Process pending ncp packets
*Mar 31 09:47:40.121: %LINK-3-UPDOWN: Interface Virtual-Access2,
changed state to up
*Mar 31 09:47:40.141: Vi2 IPCP: I CONFREQ [REQsent] id 125 len 10
*Mar 31 09:47:40.141: Vi2 IPCP: Address 0.0.0.0 (0x030600000000)
*Mar 31 09:47:40.141: Vi2 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0,
we want 0.0.0.0
*Mar 31 09:47:40.141: Vi2 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0,
we want 0.0.0.0
*Mar 31 09:47:40.141: Vi2 IPCP: Pool returned 10.0.0.3
*Mar 31 09:47:40.141: Vi2 IPCP: O CONFNAK [REQsent] id 125 len 10
*Mar 31 09:47:40.141: Vi2 IPCP: Address 10.0.0.3 (0x03060A000003)
*Mar 31 09:47:40.153: Vi2 IPCP: I CONFACK [REQsent] id 1 len 10
*Mar 31 09:47:40.157: Vi2 IPCP: Address 10.0.0.1 (0x03060A000001)
*Mar 31 09:47:40.173: Vi2 IPCP: I CONFREQ [ACKrcvd] id 126 len 10
*Mar 31 09:47:40.173: Vi2 IPCP: Address 10.0.0.3 (0x03060A000003)
*Mar 31 09:47:40.173: Vi2 IPCP: O CONFACK [ACKrcvd] id 126 len 10
*Mar 31 09:47:40.173: Vi2 IPCP: Address 10.0.0.3 (0x03060A000003)
*Mar 31 09:47:40.173: Vi2 IPCP: State is Open
!--- The route to client3 is installed.
*Mar 31 09:47:40.173: Vi2 IPCP: Install route to 10.0.0.3
*Mar 31 09:47:40.173: Vi2 IPCP: Add link info for cef entry 10.0.0.3
*Mar 31 09:47:40.173: Vi2 DDR: dialer protocol up
*Mar 31 09:47:41.117: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Serial0:12, changed state to up
*Mar 31 09:47:41.121: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Virtual-Access2, changed state to up
*Mar 31 09:47:45.941: %ISDN-6-CONNECT:
Interface Serial0:12 is now connected to 8102 client3
central#
central#show caller user client3 detailed
User: client3, line Se0:14, service PPP
Connected for 00:00:13, Idle for 00:00:12
Timeouts: Limit Remaining Timer Type
00:02:00 00:01:47 Dialer idle
PPP: LCP Open, CHAP (<-)
LCP: -> peer, AuthProto, MagicNumber
<- peer, MagicNumber
Dialer: Connected to 8102, inbound
Type is ISDN, group Se0:15
Counts: 111 packets input, 2349 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
111 packets output, 2202 bytes, 0 underruns
0 output errors, 0 collisions, 14 interface resets
User: client3, line Vi2, service VDP
Connected for 00:00:13, Idle for 00:00:03
Timeouts: Limit Remaining Timer Type
- - -
PPP: LCP Open, CHAP (<-), IPCP
LCP: -> peer, AuthProto, MagicNumber
<- peer, MagicNumber
NCP: Open IPCP
IPCP: <- peer, Address
-> peer, Address
IP: Local 10.0.0.1, remote 10.0.0.3
Counts: 9 packets input, 490 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
9 packets output, 490 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
central#show interface virtual-access 2
Virtual-Access2 is up, line protocol is up
Hardware is Virtual Access interface
Interface is unnumbered. Using address of Loopback0 (10.0.0.1)
MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
Open: IPCP
VDP vaccess, cloned from virtual template1
Vaccess status 0x44, loopback not set
DTR is pulsed for 5 seconds on reset
Last input never, output never, output hang never
Last clearing of "show interface" counters 00:19:01
Input queue: 0/10/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
13 packets input, 554 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
13 packets output, 554 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
central#
Related Information
Open a Support Case 
(Requires a Cisco Service Contract.)
Related Cisco Support Community Discussions
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.