Thursday, March 29, 2018

Cisco MGX 8900 Series Switches

ılılılı RouteXP ılılılı ılılılı
Cisco MGX 8900 Series Switches

The Cisco MGX 8900 Series Multi-service Switch is a high-end multi-service switch designed to scale multi-service networks to OC-192c/STM-64. The Cisco MGX 8900 Series offers service providers the greatest level of choice and control over extensions of existing infrastructure as well as providing a seamless path to future services.
Multiple, simultaneous control planes support unmatched flexibility and scalability in deploying, managing, and modifying a complete range of ATM and Multiprotocol Label Switching (MPLS).
Based on the industry's most extensible architecture, the Cisco MGX 8950 Multiservice Switch provides the greatest flexibility in service provider networks. Multiple, simultaneous control planes support unmatched flexibility and scalability in deploying, managing, and modifying a complete range of ATM and Multiprotocol Label Switching (MPLS).
The Cisco MGX 8950 Multiservice Switch supports carrier-class reliability, availability, and serviceability with an evolutionary architecture using the Cisco QuadNonstop switching fabric set designed to meet the demands of 10-Gbps ATM traffic. 

The Cisco Europa chipset guarantees continuous and full use of 10 Gbps per slot so that all queues are used at the maximum line rate. The Cisco Europa chipset supports available bit rate (ABR) VS/VD traffic management at a 10-Gbps line rate. This results in superior control of jitter and latency at the full 10-Gbps line rate, providing the most reliable and flexible support for traffic demands ranging across voice, bursty IP flows, and delay- and jitter-sensitive applications


Technical Specifications


The following are some of the key features of the Cisco MGX 8950 Multiservice Switch:


• Scalability of up to 180-Gbps fully redundant nonblocking switching within a single chassis
• 10-Gbps ATM interfaces (OC-192c/STM-64)
• Industry-leading broadband density
• OC-3c/STM-1, OC-12c/STM-4, and OC-48c/STM-16 trunk aggregation
• Industry's highest network availability
• Seamless integration with Cisco BPX 8600 Series and Cisco MGX 8000 Series switches

The MGX 8950 4-Port OC-48/STM-4 Channelized/Unchannelized ATM Service Module is a line card for use in the Cisco MGX 8950 in combination with the Cisco MGX 8850 PXM-45/C Processor Switch Module and the Cisco MGX 8950 XM-60 Switching Module. 

This ATM switch service module has four physical 2.5-Gbps interfaces that can be used to deliver high-density OC-48 or STM-16 trunking and User-Network Interface (UNI) or aggregation of sub-OC-48 traffic through port channelization.
Up to 12 MGX 8950 4-Port OC-48/STM-4 Channelized/Unchannelized ATM Service Module can reside in the Cisco MGX 8950 to provide support for up to 48 OC-48/STM-16 interfaces for service providers that require both high bandwidth and high network availability.

The MGX 8950 4-Port OC-48/STM-4 Channelized/Unchannelized ATM Service Module meets service providers' demand for carrier-class availability by offering hot-standby 1+1 card redundancy as well as port redundancy with SONET/SDH automatic protection switching (APS).
Key Features


The main features of the MGX 8950 4-Port OC-48/STM-4 Channelized/Unchannelized ATM Service Module are listed here.

  • Full nonblocking, full-duplex line-rate throughput on all 4 ports
  • Individual port channelisation down to OC-12c/STM-4, OC-3c/STM-1, and DS-3
  • User-Network Interface (UNI) and Private Network-to-Network Interface (PNNI) support on the same physical port
  • Per-virtual-path and per-virtual-circuit traffic shaping and available bit rate (ABR) with virtual source and virtual destination
  • APS (1:1 and 1+1) port redundancy, plus APS 1+1 card redundancy
  • Up to 4 million cell buffers
  • Up to 16 classes of service (CoS) that can be used to support IP or ATM services
  • Support for standards-based PNNI, switched virtual circuit (SVC) and switched virtual path (SVP), soft permanent virtual connection (SPVC) and soft permanent virtual path (SPVP), and Multi-protocol Label Switching (MPLS) services


Introduction to Cisco 800 Series Router

ılılılı RouteXP ılılılı ılılılı
Introduction to Cisco 800 Series Router

The Cisco 800 Series Integrated Services Routers (ISR) enable a variety of WAN technologies, including xDSL, Ethernet, 3G and 4G, and fiber—with a range of performance levels to meet your needs.

The 800 ISRs Router enable voice connectivity and video traffic and provide Wi-Fi—helping you minimize capital expenditures (CapEx) at the branch with a single box.


The 800 ISRs provide encryption, VPN, firewall, and URL filtering (Cloud Web Security), helping you safeguard your customers and data.


Cisco 800 M series Router:-



  • Ideal for small-branch sites, such as gas stations, ATMs, kiosks, vending machines, retail stores, restaurants, IoT locations, or other microbranches
  • Flexible connectivity options and simplified large-scale wireless WAN deployments
  • Integrated security and application services
  • Best in class price-performance ratio
Cisco 810 Series Router:-

  • Ideal for machine-to-machine and device-to-device deployments such as ATMs, point-of-sale, and other applications
  • Available in hardened and non-hardened form factors
  • Lightweight, compact, and low-power consuming
  • Dual-sim option for highly reliable, cellular multi-homing support for always on connectivity
Cisco 860 Series Router:-

  • Recommended for home or small office connectivity for up to 10 users
  • Desktop form factor and fanless design
  • Cost-effective solution for WAN connectivity with DSL or Ethernet option
  • Optional Wi-Fi for a low cost integrated WAN and Wi-Fi solution at the home office
Cisco 880 Series Router:-

  • Recommended for remote workers, small offices, and branch locations with up to 20 users
  • WAN redundancy with optional 3G as backup for business application support
  • Voice support for integrated PBX and IP telephony in the branch
  • Enhanced security and voice and wireless options for a complete converged single-box branch solution

Cisco 890 Series Router:-

  • Recommended for managed service provider (MSP) or enterprise remote offices with up to 50 users
  • High-performance desktop routers enabling multiple applications simultaneously
  • High-density LAN option (up to 8 Gigabit Ethernet ports) for high-speed local connectivity
  • Optional fiber connectivity for FTTH (fiber to the home) deployments

Cisco 3900 Series Integrated Services Routers

ılılılı RouteXP ılılılı ılılılı
Cisco 3900 Series Integrated Services Routers

Lets discuss about the Cisco 3900 Series router who is the replacement of Cisco 3800 Series router. So probably it is used where we have the WAN requirement is almost 150 Mbps or 200 Mbps ( Ethernet and Dedicated Circuits )


The Cisco 3900 Series router builds on the best-in-class offering of the existing Cisco 3800 Series Integrated Services routers by now offering four platforms (Figure 1): the Cisco 3945E, Cisco 3925E, Cisco 3945, and Cisco 3925 Integrated Services routers.

The Cisco 3900 Series offers embedded hardware encryption acceleration, voice- and video-capable DSP slots, optional firewall, intrusion prevention, call processing, voicemail, and application services. In addition, the platforms support the industry’s widest range of wired and wireless connectivity options such as T1/E1, T3/E3, xDSL, copper, and fiber Gigabit Ethernet.

The Cisco 3900 Series offers superior performance and flexibility for flexible network deployments from small business offices to large enterprise offices - all while providing industry-leading investment protection.



The Cisco 3900 Series router is architect to meet the application demands of today’s branch offices with design flexibility for future applications. The modular architecture is designed to support increasing bandwidth requirements, time-division multiplexing (TDM) interconnections, and fully integrated power distribution to modules supporting 802.3af PoE and Cisco ePoE. Table 2 lists the architectural features and benefits of the Cisco 3900 Series router.

The Cisco 3900 Series provides significantly enhanced modular capabilities while maintaining investment protection for customers. Most of the modules available on previous generations of Cisco router, such as the Cisco 3800 Series Integrated Services routers, are supported on the Cisco 3900 Series. 

Additionally, modules used on the Cisco 3900 Series can easily be supported on other routers in the Cisco Integrated Services router portfolio to provide maximum investment protection. Taking advantage of common interface cards across a network greatly reduces the complexity of managing inventory requirements, implementing large network roll-outs, and maintaining configurations across a variety of branch-office sizes.

Cisco IOS Software
Cisco 3900 Series Integrated Services routers deliver innovative technologies running on industry-leading Cisco IOS Software. Developed for wide deployment in the world’s most demanding enterprise, access, and service provider networks, Cisco IOS Software Releases 15M and T support a comprehensive portfolio of Cisco technologies, including the functions and features delivered in Releases 12.4 and 12.4T. New innovations in Release 15.0(1)M span multiple technology areas, including security, voice, high availability, IP Routing and Multicast, quality of service (QoS), IP Mobility, Multiprotocol Label Switching (MPLS), VPNs, and embedded management. Available immediately for the Cisco 3900 Integrated Services Routers, Release 15.0(1)M will be an extended support release.

Cisco IOS Software Licensing and Packaging
A single Cisco IOS Universal image encompassing all functions is delivered with the platforms. You can enable advanced features by activating a software license on the Universal image. In previous generations of access routers, these feature sets required you to download a new software image. Technology packages and feature licenses, enabled through the Cisco software licensing infrastructure, simplify software delivery and decrease the operational costs of deploying new features.
Four major technology licenses are available on the Cisco 3900 Series Integrated Services Routers. The following licenses are available:
   IP Base: This technology package is available as default.
   Data
   Unified Communications
   Security (SEC) or Security with No Payload Encryption (SEC-NPE)
For additional information and details about Cisco IOS Software licensing and packaging on Cisco 3900 Series Integrated Services Routers


Unified Communications, Collaboration, and Voice-Gateway Services
The Cisco 3900 Integrated Services Router is the foundation for collaboration in branch offices of any size and is a critical component of Cisco’s video architecture (Medianet) and enterprise Unified Communications solution. With embedded voice services and a wide range of telephony interfaces supported, the Cisco 3900 Series delivers maximum deployment flexibility for the distributed enterprise. Unified communications is enabled through a rich signaling and media-processing infrastructure, including a variety of protocols, media interworking, signal and media security, transcoding, conferencing, and QoS. 

Cisco Integrated Services Routers feature a wide range of voice-gateway interfaces, supporting a broad array of signaling and physical network interfaces. The performance improvements introduced with the Cisco 3900 Series help ensure that branch-office employees benefit from the same productivity advantages and wide breadth of services and applications as those enjoyed by the headquarters-based employees.


The Cisco 3900 Series enables a full range of existing and emerging video services, with scaling improvement to support Cisco TelePresence conferencing, security, and session control. Cisco Unified Border Element extends these capabilities for business-to-business TelePresence communications.

The Cisco 3900 Series adds support for the new Cisco High-Density Packet Voice Digital Signal Processor Module (PVDM3), which has been optimized for concurrent voice and video support. The PVDM3 modules support all voice-gateway functions of earlier generations of PVDMs, and add higher density and more processing power to support emerging rich-media applications. The Cisco 3900 Series can support up to 4 onboard PVDM3 slots, able to scale up to 768 G.729a channels

Integrated Network Security for Data, Voice, Video, and Mobility
Security is essential to protect a business’ intellectual property while also ensuring business continuity and providing the ability to extend the corporate workplace to employees who need anytime, anywhere access to company resources. As part of the Cisco Self-Defending Network (SDN) - an architectural framework that allows organizations to identify, prevent, and adapt to network security threats - the Cisco 3900 Series Integrated Services Routers facilitate secure data transactions and secure collaboration.
The Cisco IOS Software Security technology package for the Cisco 3900 Series offers a wide array of common security features such as advanced application inspection and control, threat protection, and encryption architectures for enabling more scalable and manageable VPN networks. The Cisco 3900 Series offers onboard hardware-based encryption acceleration to provide greater IPSec throughput with less overhead for the route processor when compared with software-based encryption solutions. Cisco Integrated Services Routers offer a comprehensive and adaptable security solution for branch offices that includes features such as:
   Secure connectivity: Secure collaborative communications with Group Encrypted Transport VPN, Dynamic Multipoint VPN (DMVPN), or Enhanced Easy VPN
   Integrated threat control: Responding to sophisticated network attacks and threats using Cisco IOS Firewall, Cisco IOS Zone-Based Firewall, Cisco IOS IPS, Cisco IOS Content Filtering, and Flexible Packet Matching (FPM)
   Identity management: Intelligently protecting endpoints using technologies such as authentication, authorization, and accounting (AAA) and public key infrastructure (PKI)

Integrated LAN Switching
The Cisco 3900 Integrated Services Routers support the new Cisco Enhanced EtherSwitch  Service Modules, which greatly expand router capabilities by integrating industry-leading Layer 2 or Layer 3 switching with feature sets identical to those found in the Cisco Catalyst 3560-E and Catalyst 2960 Series Switches performing local line-rate switching and routing.


The new Cisco Enhanced EtherSwitch Service Modules take advantage of the increased power capabilities on the Cisco 3900 Series platforms. Additionally, the modules enable Cisco energy and power initiatives: Cisco EnergyWise, Cisco ePoE and per-port PoE power monitoring, and integrated redundant power system (RPS)-enabled PoE boost. These technologies allow you to meet increased endpoint power requirements without increasing the total power consumption of the branch office.


DHCP relay and server

ılılılı RouteXP ılılılı ılılılı
DHCP relay and server

Today I am going to talk about DHCP relay and server in detail. May be many of you will get the point about the DHCP relay and server in details. Let's talk about the start when a computer or different networked device connects to a network, the DHCP patron software program sends a broadcast question soliciting for important statistics. Any DHCP server at the network may additionally service the request.

The DHCP server manages a pool of IP addresses and records approximately patron configuration parameters together with default gateway, area call, the call servers, and time servers. On receiving a request, the server might also respond with unique facts for each patron, as previously configured by means of an administrator, or with a specific address and any other facts legitimate for the entire network and for the time period for which the allocation (lease) is valid.

A consumer generally queries for this facts immediately after booting, and periodically thereafter before the expiration of the facts. when a DHCP client refreshes an challenge, it first of all requests the same parameter values, but the DHCP server can also assign a new cope with primarily based on the venture rules set by means of administrators.

On large networks that consist of a couple of links, a unmarried DHCP server may also carrier the whole community whilst aided by DHCP relay dealers placed on the interconnecting routers. Such sellers relay messages among DHCP clients and DHCP servers positioned on one-of-a-kind subnets.


The DHCP protocol become created in order that clients may want to reap their IP cope with automatically and with out human intervention (yes that used to be an real a part of IT-ing, back within the day). The manner this works is that once a consumer connects to the network, it sends out a “broadcast” packet asking to find the DHCP server.

That was “good enough” till Vlans got here along. Vlans create obstacles  and segment your physical community into several really isolated ones (therefore the name V-LAN). one of the downsides to Vlans is that now the DHCP server and the clients can’t at once talk, due to the fact “broadcast” packets can not “bounce” networks. So, how do you avoid having a DHCP server per-Vlan, and supply the DHCP requests from the customers in a Vlan, lower back to the vital server?

DHCP relays had been invented to over come this actual hassle through basically “routing” or “proxy-ing” the consumer’s requests. The requests are broadcasted through the customers on their neighborhood network, the relay-agent catches them and forwards them to the DHCP server the use of uni cast. The back DHCP answer gets to the relay agent using uni cast as properly, and the relay agent sends the answer on the consumer’s network.

Fig 1.1- DHCP relay and server
Fig 1.1- DHCP relay and server

DHCP provides a framework for passing configuration information dynamically to hosts on a TCP/IP network. A DHCP client is an Internet host using DHCP to obtain configuration parameters such as an IP address.
   
A DHCP relay agent is any host that forwards DHCP packets between clients and servers. Relay agents are used to forward requests and replies between clients and servers when they are not on the same physical subnet. Relay agent forwarding is distinct from the normal forwarding of an IP router, where IP data grams are switched between networks somewhat transparently. By contrast, relay agents receive DHCP messages and then generate a new DHCP message to send on another interface.
Fig 1.2- DHCP relay and server
Fig 1.2- DHCP relay and server
You can configure the DHCP relay agent at both the context and VLAN interface levels of the ACE. 

  • If you configure the DHCP relay agent at the context level, the configuration applies to all interfaces associated with the context. 
  • If you configure the DHCP relay agent at the VLAN interface level, the configuration applies to that particular interface only; the remaining interfaces revert to the context level configuration.  

Monday, March 5, 2018

VTPv2 Transparent Mode

ılılılı RouteXP ılılılı ılılılı
VTPv2 Transparent Mode


#Cisco CCNA Students
#Cisco Switching Techniques
#Cisco CCNP R&S Students

VTP Modes 
You can configure a switch to operate in any one of these VTP modes:
  • Server—In VTP server mode, you can create, modify, and delete VLANs and specify other configuration parameters, such as VTP version and VTP pruning, for the entire VTP domain. VTP servers advertise their VLAN configuration to other switches in the same VTP domain and synchronize their VLAN configuration with other switches based on advertisements received over trunk links. VTP server is the default mode. 
  • Client—VTP clients behave the same way as VTP servers, but you cannot create, change, or delete VLANs on a VTP client.
  • Transparent—VTP transparent switches do not participate in VTP. A VTP transparent switch does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements, but transparent switches do forward VTP advertisements that they receive out their trunk ports in VTP Version 2.
  • Off (configurable only in CatOS switches)—In the three described modes, VTP advertisements are received and transmitted as soon as the switch enters the management domain state. In the VTP off mode, switches behave the same as in VTP transparent mode with the exception that VTP advertisements are not forwarded.

VTP V2 

VTP V2 is not much different than VTP V1. The major difference is that VTP V2 introduces support for Token Ring VLANs. If you use Token Ring VLANs, you must enable VTP V2. Otherwise, there is no reason to use VTP V2. Changing the VTP version from 1 to 2 will not cause a switch to reload.


In VTP version 2, transparent switches do forward received VTP advertisements out of their trunk ports, acting as VTP relays. This occurs regardless of the VTP domain name setting”

Testing

I’m going to use the same network as my previous post on VTPv1 to perform my test. All switches will be put in VTP version 2. Sw1 & Sw3 will be configured as a server, and Sw2 will be configured in transparent mode.
Fig 1.1- VTP Transparent Mode


Sw1#sh vtp status
VTP Version                     : running VTP2
Configuration Revision          : 25
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 5
VTP Operating Mode              : Server
VTP Domain Name                 : test
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled


Sw2#sh vtp status
VTP Version                     : running VTP2
Configuration Revision          : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 5
VTP Operating Mode              : Transparent
VTP Domain Name                 : test
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled


Sw3#sh vtp status
VTP Version                     : 2
Configuration Revision          : 25
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 5
VTP Operating Mode              : Server
VTP Domain Name                 : test
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled

Let’s just add a VLAN on Sw1 and ensure Sw3 gets it. This is just a quick check to ensure my VTP domain is working before we start testing the hypothesis.
Sw1(config)#vlan 100
Sw1(config-vlan)#name vlan100
Sw1(config-vlan)#end


Sw3#sh vlan

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/1, Fa0/2, Fa0/3, Fa0/4
                                                Fa0/5, Fa0/6, Fa0/7, Fa0/8
                                                Fa0/9, Fa0/10, Fa0/11, Fa0/12
                                                Fa0/13, Fa0/14, Fa0/15, Fa0/17
                                                Fa0/18, Fa0/19, Fa0/20, Fa0/21
                                                Fa0/22, Fa0/23, Fa0/24, Gi0/1
                                                Gi0/2
100 vlan100                          active

Good. Let’s test the hypothesis out the CCNP switch book, “In VTP version 2, transparent switches do forward received VTP advertisements out of their trunk ports, acting as VTP relays. This occurs regardless of the VTP domain name setting”. Right, so if we change the domain name on Sw2 (transparent switch), then Sw3 should still receive VTP messages. Let’s do that now.


Sw2(config)#vtp domain nottest
Changing VTP domain name from test to nottest
Sw2(config)#end

On Sw1, let’s add a VLAN and check the VTP information is relayed by Sw2 over to Sw3.


Sw1(config)#vlan 999
Sw1(config-vlan)#name vlan999
Sw1(config-vlan)#end


Sw3#sh vlan

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/1, Fa0/2, Fa0/3, Fa0/4
                                                Fa0/5, Fa0/6, Fa0/7, Fa0/8
                                                Fa0/9, Fa0/10, Fa0/11, Fa0/12
                                                Fa0/13, Fa0/14, Fa0/15, Fa0/17
                                                Fa0/18, Fa0/19, Fa0/20, Fa0/21
                                                Fa0/22, Fa0/23, Fa0/24, Gi0/1
                                                Gi0/2
100  vlan100                          active

So VLAN 999 didn’t propagate over to Sw3. Let’s check the debugs on Sw2 to find out what happened.


*Mar  1 03:07:09.510: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/13 - not in domain test

*Mar  1 03:07:09.510: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/13 - not in domain test

So actually, the frame was dropped because it wasn’t in the same domain.


Conclusion

The hypothesis taken from the CCNP Switch book stated: “In VTP version 2, transparent switches do forward received VTP advertisements out of their trunk ports, acting as VTP relays. This occurs regardless of the VTP domain name setting”
After my testing, I found this information to be incorrect. After changing the VTP domain name on the transparent switch (Sw2), the VTP information was not relayed over to Sw3.

PEAP - Protected EAP Protocol- 802.1X

ılılılı RouteXP ılılılı ılılılı
PEAP - Protected EAP Protocol- 802.1X

One of the major security vulnerabilities from the EAP perspective is that the some of the initial EAP message exchanges, such as EAP-Request/Identity and EAP-Response/Identity, are sent in cleartext. PEAP leverages EAP-TLS (EAP Transport Layer Security) where the initial EAP message exchanges are done over a secure tunnel built between the Client and the Server using TLS. The entire EAP negotiation is protected.

EAP-TLS requires client-side certificate also, while PEAP exempts this requirement. PEAP requires only server-side certificate, uses TLS for the secure tunnel, and goes beyond EAP-TLS adding client authentication and key-exchange.

The PEAP protocol has two phases- the first phase is to establish a secure tunnel using EAP-TLS with Server authentication. The second phase implements the Client authentication based on EAP methods. 


The following flow diagram shows all the messages exchanged between the Client and the Server.





PEAP Phase 1

Like in regular EAP negotiation, the phase 1 starts when the Authenticator sends an EAP-Request/Identity message. Unlike regular EAP where the Client replies with an EAP-Response/Identity message, in PEAP, the Client can reply with an anonymous identity, for example user@anonymous.com. The Client's real identity is sent in Phase 2. It is likely that the Client can send its identity partly, like user@company_name.com, so that the Authenticator can choose a proper Authentication Server based on Company name. 

After the Client EAP-Response/Identity is forwarded to the Authentication Server using RADIUS by the Authenticator, the EAP-TLS starts. The process is same as SSL Connection Setup.

The EAP Server becomes aware of the Client when it receives RADIUS Access-Request message forwarded by the Authenticator. The Server sends an empty EAP-TLS request with the Start flag set and Type field set to 25 (PEAP); EAP-TLS uses Type=13.. Only this message has the Start flag set. The Client sends a Client-Hello message containing all the ciphersuites it supports including a Client-Random ID with Session ID set to 0.

The Server replies with a Server-Hello message containing a Server-Random ID, a Session ID and the agreed ciphersuite. The Server also sends a Certificate including its Public key in a Server Certificate message. It can request a Client Certificate from the Client. This is followed by a Server Hello Done message and waits for the Client to take the next step.

The Client in response sends a Client Key Exchange message after computing the pre_master secret. The Client generates a random number (48 bytes) which is called the pre-master secret, encrypts it using Server's public key and sends to the Server. Only Server can decrypt this message as it holds the Private key. Both, Client and Server, now have the pre-master secret.

The Client and the Server now generate the Master Session Key (MSK) from the Client-Random ID, Server-Random ID and the pre_master secret.

Finally, the Server sends an EAP-Success message to complete the EAP Handshake.

PEAP Phase 2

Phase 2 begins with an EAP Server sending an (optional) EAP-Request/Identity message to the Client, protected by the TLS ciphersuite negotiated in Phase 1. The Client responds with an EAP-Response/Identity message containing its user-id.

The Server will then select an authentication method (aka EAP Type like EAP-MD5, EAP-TLS or EAP-MSCHAPv2, etc) for the Client, and will send an EAP-Request message with the proposed authentication method. The Client can reply with a NAK or accept the authentication method. EAP methods are always encapsulated within EAP Payload TLV. 

Before completing negotiation of EAP method, the Client and the Server must use Crypto Binding TLV. The success or failure of EAP method negotiation is done using EAP Result TLV. 

The Client and the Server now derive the Extended Master Session Key (EMSK) and subsequently the Compound Session Key (CSK). The CSK is 128 bytes which is concatenation of MSK and EMSK. Then the Server sends its CSK and the EAP Success message to the Authenticator.


The Client can then send data to the Authenticator using the derived CSK.

Cisco DSL Router PPPoA – Troubleshooting

ılılılı RouteXP ılılılı ılılılı
Cisco DSL Router PPPoA – Troubleshooting

#Cisco Students
#Cisco DSL Techniques
#Router PPPoA Troubleshooting
#CCIE R&S students
# Cisco System Engineers

There are many reasons why your digital Subscriber Line (DSL) connection may not be functioning properly. The intention of this phase is to isolate the motive of the failure and repair it. the primary troubleshooting step is to decide which layer of your Asynchronous digital Subscriber Line (ADSL) provider is failing. There are 3 layers wherein the failure can occur.
  • Layer 1 – DSL physical connectivity to your ISP's Digital Subscriber Line Access Multiplexer(DSLAM)
  • Layer 2.1 – ATM connectivity
  • Layer 2.2 – Point−to−Point Protocol over ATM (PPPoA), Point−to−Point Protocol over Ethernet (PPPoE), RFC1483 Bridging, or RFC1483 Routing
  • Layer 3 – IP
Fig 1.1 DSL Router PPPoA
Fig 1.1 DSL Router PPPoA

The easiest way to determine which layer you should begin troubleshooting is to issue the command show ip interface brief. The output of this command differs slightly depending on your configuration

827−ESC#show ip interface brief
Interface            IP−Address          OK?          Method           Status          Protocol
ATM0               unassigned          YES            manual             up                 up
ATM0.1            unassigned          YES            unset                up                 up
Ethernet0          10.10.10.1           YES            manual             up                 up


If the statuses of ATM0 and ATM0.1 are up and the protocol is up, begin troubleshooting at Layer 2.
If the ATM interfaces are down, or if they keep coming up and then going down (they don't stay up and up), begin troubleshooting at Layer 1.

Layer-1 Issues
Is the carrier detect (CD) light on the front panel of the Cisco DSL Router on or off?
If the CD light is on, go to the Layer 2 Issues section of this document.
If the CD light is off, continue with the next question.

Is your ISP using a DSLAM that supports the Alcatel chipset?
Verify this information with your ISP.

Is the DSL port on the back of the Cisco DSL Router plugged into the DSL wall jack?
If the DSL port is not plugged into the DSL wall jack, connect the port to the wall with a 4−pin or 6−pin RJ−11 cable. This is a standard telephone cable.

Is the ATM interface in an administratively down state?
To determine if the ATM0 interface is administratively down, issue the following command in enable mode on the router:

Router#show interface atm 0
ATM0 is administratively down, line protocol is down
<... snipped ...>


If the ATM0 interface status is administratively down, issue the no shutdown command under the ATM0 interface.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface atm 0
Router(config−if)#no shut
Router(config−if)#end
Router#write memory


Is the cable pinout correct?
If the ATM0 interface status is down and down, the router is not seeing a carrier on the ADSL line. This generally indicates one of two issues:
1. The active pins on the DSL wall jack are incorrect.
2. Your ISP has not turned up a DSL service on this wall jack.

To determine if the ATM0 interface is down and down, issue the show interface atm 0 command from enable mode of the router:

Router#show interface atm 0
ATM0 is down, line protocol is down
<... snipped ...>


If the ATM interface is down and down—no longer administratively down—take a look at the pinout of your DSL wall jack. The DSL Router makes use of a fashionable RJ−eleven (4−pin or 6−pin) cable to offer the ADSL connection to the wall jack. The center pair of pins on the RJ−eleven cable is used to hold the ADSL sign (pins three and 4 on a 6−pin cable, or pins 2 and 3 on a 4− pin cable). this does not follow to the Cisco 1417 which makes use of pins 2 and 5. in case you are positive you have got the right pins on the wall jack and the ATM0 interface remains down and down, update the RJ−11 cable among the DSL port and your wall jack. If the interface is still down and down after changing the RJ−11 cable, contact your ISP and feature the ISP verify that ADSL service has been enabled on the wall jack you're the usage of. if you aren't sure what pins in your wall jack are energetic, ask your ISP.

If you are using a Cisco 827 as your DSL Customer Premises Equipment (CPE), do you have the correct power supply for the Cisco 827?
If you have verified that your DSL cable is good and that you have the correct pin outs, the next step is to make sure you have the correct power supply for the 827.

Note: The 827 does not use the same power supply as other 800 series routers.
To determine if you have the correct power supply, on the back of the power adapter look for Output +12V 0.1A, −12V 0.1A, +5V 3A, −24V 0.12A, and −71V 0.12A. If your power supply is missing the +12V and −12V feeds, then it is for a different Cisco 800 series router and will not work on the 827.

Note that if you use the wrong power supply, the Cisco 827 will power up but will be unable to train up (connect) to the ISP DSLAM.

Is the DSL operating−mode correct?
If everything up to this point in the Layer 1 troubleshooting procedure is correct, the next step is to make sure you have the correct DSL operating mode. Cisco recommends using dsl operating−mode auto if you are not sure what DMT technology your ISP is using. The commands to configure operating−mode auto detection are as follows:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface atm 0
Router(config−if)#dsl operating−mode auto
Router(config−if)#end
Router#write memory


Layer-2 Issues:-

Do you have the correct Permanent Virtual Circuit (PVC) values (VPI/VCI)?
Complete the following steps to determine whether you have the correct virtual path identifier/virtual circuit identifier (VPI/VCI) values configured on the router.

1. Verify your version of Cisco IOS® software. Important: This will not work with Cisco IOS Software Release 12.1(1)XB.

Router#show version
!−−− Used to determine your Cisco IOS version.
Cisco Internetwork Operating System Software
IOS (tm) C820 Software (C820−OSY656I−M), Version 12.1(3)XG3,
EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
!−−− The two lines immediately preceding appear on one line on the router.
TAC:Home:SW:IOS:Specials for info
Copyright (c) 1986−2000 by cisco Systems, Inc.
Compiled Wed 20−Dec−00 16:44 by detang
Image text−base: 0x80013170, data−base: 0x80725044
<... snipped ...>


2. Configure the router for debug logging.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#logging console
Router(config)#logging buffer
Router(config)#service timestamp debug datetime msec
Router(config)#service timestamp log datetime msec
Router(config)#end
Router#write memory
Building configuration...
[OK]
Router#terminal monitor


3. Enable debugging on the router.
Router#debug atm events
ATM events debugging is on
Router#
2d18h:
2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EF74 length=52
2d18h: Data Cell received on vpi = 8 vci = 35
!−−− Your VPI/VCI.
2d18h:
2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EEC0 length=52
2d18h: Data Cell received on vpi = 8 vci = 35
2d18h:
2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EECC length=52
2d18h: Data Cell received on vpi = 8 vci = 35
2d18h:

2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EED8 length=52
2d18h: Data Cell received on vpi = 8 vci = 35


4. Make sure you have debug ATM events running on the Cisco DSL Router, and then go to a working Internet connection and begin to ping the IP address your ISP statically assigned to you.It does not matter whether you have configured this IP address on the Cisco DSL Router. What is important is that your ATM interface is up/up and that you are pinging the IP address your ISP gave you. If you don't see the expected output after the ping test, contact your ISP for support.

5. Disable debugging on the router.
<< wait 60 seconds >>
Router#undebug all

!−−− Turn off the debug events.
All possible debugging has been turned off.

Verify your VPI/VCI values, and then make the necessary changes to your configuration.
If you do not see output during the 60 seconds of debugging, contact your ISP

Are you receiving data from your ISP?
If you have the correct PVC values, the next step is to verify that you are attempting to negotiate PPP with your ISP. To do this, issue the command show interface atm0 and check the input and output packets.

Router#show interface atm0
ATM0 is up, line protocol is up
Hardware is DSLSAR (with Alcatel ADSL Module)
MTU 4470 bytes, sub MTU 4470, BW 128 Kbit, DLY 16000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5, PVC mode
24 maximum active VCs, 256 VCS per VP, 1 current VCCs
VC idle disconnect time: 300 seconds
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 5 bits/sec, 0 packets/sec
5 minute output rate 7 bits/sec, 0 packets/sec
100 packets input, 5600 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
250 packets output, 1400 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 output buffer failures, 0 output buffers swapped out


If the packet counters are incrementing, you should be receiving PPP negotiation packets from your ISP. If this isn't the case, call your ISP.
If the output bound counters are incrementing, you should be sending PPP negotiation packets. If this isn't the case, check the configuration on the router. If PPP is configured properly, PPP negotiation packets are continually sent out the ATM0 interface.


Is PPP negotiating properly?
If Layer 1 is up and you have the correct VPI/VCI, the next step is to make sure PPP is coming up properly. To accomplish this, you need to run a series of debug commands on the Cisco DSL Router and interpret the output. The primary debug you will use is debug ppp negotiation. The following output of this command is an example of a successful PPP negotiation:

Router#debug ppp negotiation
PPP protocol negotiation debugging is on
Router#
2w3d: Vi1 PPP: No remote authentication for call−out
2w3d: Vi1 PPP: Phase is ESTABLISHING
2w3d: Vi1 LCP: O CONFREQ [Open] id 146 len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: O CONFACK [Open] id 102 Len 15
2w3d: Vi1 LCP: AuthProto CHAP (0x0305C22305)
2w3d: Vi1 LCP: MagicNumber 0xD945AD0A (0x0506D945AD0A)
2w3d: Di1 IPCP: Remove route to 20.20.2.1
2w3d: Vi1 LCP: I CONFACK [ACKsent] id 146 Len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: State is Open
2w3d: Vi1 PPP: Phase is AUTHENTICATING, by the peer
2w3d: Vi1 CHAP: I CHALLENGE id 79 Len 33 from "6400−2−NRP−2"
2w3d: Vi1 CHAP: O RESPONSE id 79 Len 28 from "John"
2w3d: Vi1 CHAP: I SUCCESS id 79 Len 4
2w3d: Vi1 PPP: Phase is UP
2w3d: Vi1 IPCP: O CONFREQ [Closed] id 7 Len 10
2w3d: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
2w3d: Vi1 IPCP: I CONFREQ [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201)
2w3d: Vi1 IPCP: O CONFACK [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201)
2w3d: Vi1 IPCP: I CONFNAK [ACKsent] id 7 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: O CONFREQ [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: I CONFACK [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: State is Open
2w3d: Di1 IPCP: Install negotiated IP interface address 40.1.1.2
2w3d: Di1 IPCP: Install route to 20.20.2.1


There are four main points of failure in a PPP negotiation:
1. No response from the remote device (your ISP).
2. Link Control Protocol (LCP) not open
3. Authentication failure
4. IP Control Protocol (IPCP) failure

No Response from Your ISP
Your ISP not responding should not be a problem since you already verified that packets are incrementing on the ATM0 interface in the inbound direction. However, if you see packets incrementing on ATM0 in the inbound direction, and when you run a debug ppp negotiation you receive the following output, contact your ISP to verify that packets are being sent to the Cisco DSL Router.

Whether its an I or an O packet, a Configure−Negative−Acknowledge (CONFNAK) is indicative of a PPP configuration mismatch. What this means is that one side of the PPP connection is asking for a PPP option that the other side is unable or not configured to perform. If the Cisco DSL Router is sending the CONFNAK (indicated by "O CONFNAK"), the Cisco DSL Router is not able to perform or not configured for the option the ISP is sending. If the CONFNAK is being sent by your ISP (indicated by "I CONFNAK"), you have configured an option on the Cisco DSL Router that your ISP is not willing to perform. The line following the CONFNAK describes the option that is being rejected. In this example output, the option is Challenge Handshake Authentication Protocol (CHAP) but it could be any option. The only place on the Cisco DSL Router where PPP options can be configured is interface dialer 1. Issue the command show run interface dialer 1 to view your interface dialer 1 configuration. If your ISP is sending the I CONFNAK, look for commands under interface dialer 1 that match the line following the CONFNAK and remove them. If the Cisco DSL Router is sending the O CONFNAK, add a command to interface dialer 1 to properly negotiate PPP with your ISP. In the case of the router sending packets, you may need to call the Cisco TAC to determine which command(s) need to be enabled on the Cisco DSL Router.

Authentication Failure
An authentication failure occurs when your ISP is unable to authenticate your PPP username or password. There are two scenarios in which this may occur. The first scenario is an authentication type mismatch, which is caused when you don't properly configure the router. All the authentication configurations listed in this document account for both Password Authentication Protocol (PAP) and CHAP authentication types. For configuration flexibility, you should have both CHAP and PAP configured. If you don't have both configured, you may see output from a debug ppp command like the following:

Router#debug ppp negotiation
00:34:29: Vi1 LCP:OCONFREQ [REQsent] id 53 Len 15
00:34:29: Vi1 LCP: AuthProto CHAP (0x0305C22305)
!−−− Sending CHAP requests.
00:34:29: Vi1 LCP: MagicNumber 0x01B63483 (0x050601B63483)
00:34:29: Vi1 LCP: I CONFREQ [REQsent] id 252 Len 14
00:34:29: Vi1 LCP: AuthProto PAP (0x0304C023)
!−−− Receiving PAP requests from the service provider.
00:34:29: Vi1 LCP: MagicNumber 0xBC5233F9 (0x0506BC5233F9)
00:34:29: Vi1 LCP:


Router# debug ppp negotiation
00:45:44: Vi1 LCP: I CONFREQ [Listen] id 141 Len 15
00:45:44: Vi1 LCP: AuthProto CHAP (0x0305C22305)
!−−− Receiving CHAP requests from the service provider.
00:45:44: Vi1 LCP: MagicNumber 0xBC5C7DDC (0x0506BC5C7DDC)
00:45:44: Vi1 LCP: O CONFREQ [Listen] id 255 Len 14
00:45:44: Vi1 LCP: AuthProto PAP (0x0304C023)
!−−− Sending out PAP requests.
Router#undebug all
!−−− Turn off ppp debug.





To correct both authentication mismatch problems, refer to the appropriate PPPoA implementation option configuration and reconfigure PPP authentication.
The second authentication problem scenario you may encounter is an incorrect PAP username or password. To determine if this is the problem, issue the command debug ppp negotiation. Assuming your router is configured for both CHAP and PAP, as the configuration outlined earlier in this guide shows, your ISP may not be using PAP authentication.
To determine the authentication used by your ISP, check the options in the I CONFREQ packet sent to you from your ISP. If this packet is followed by an option called AuthProto PAP, you are using PAP. If the I CONFREQ is followed by an option called AuthProto CHAP, you are using CHAP and should proceed to How do I know if my CHAP username and password are correct?

How do I know if my PAP username and password are correct?
After you have confirmed that your ISP is using PAP, issue the debug ppp negotiation command to confirm that your PAP username and password are correct.

Router#debug ppp negotiation
*Mar 2 00:50:15.741: Vi1 PPP: Treating connection as a callout
*Mar 2 00:50:15.745: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 2 00:50:15.745: Vi1 PPP: No remote authentication for call−out
*Mar 2 00:50:15.745: Vi1 LCP: O CONFREQ [Closed] id 177 Len 10
*Mar 2 00:50:15.745: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:15.789: Vi1 LCP: I CONFACK [REQsent] id 177 Len 10
*Mar 2 00:50:15.793: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:17.241: Vi1 LCP: I CONFREQ [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.241: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.241: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.245: Vi1 LCP: O CONFACK [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.245: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.245: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.249: Vi1 LCP: State is Open
*Mar 2 00:50:17.249: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 2 00:50:17.249: Vi1 PAP: O AUTH−REQ id 9 Len 14 from "cisco"
!−−− "cisco" is the PAP username configured on this DSL Router.
*Mar 2 00:50:17.297: Vi1 PAP: I AUTH−NAK id 9 Len 27 msg is "Authentication failure"
*Mar 2 00:50:17.301: Vi1 LCP: I TERMREQ [Open] id 204 Len 4
*Mar 2 00:50:17.301: Vi1 LCP: O TERMACK [Open] id 204 Len 4
*Mar 2 00:50:17.305: Vi1 PPP: Phase is TERMINATING [0 sess, 1 load]u
*Mar 2 00:50:19.305: Vi1 LCP: TIMEout: State TERMsent
*Mar 2 00:50:19.305: Vi1 LCP: State is Closed
*Mar 2 00:50:19.305: Vi1 PPP: Phase is DOWN [0 sess, 1 load]


If you have a PAP authentication problem, you should see the LCP state go to Open. Directly following the LCP state change you should see PPP go into an Authenticating phase. If one of the next two lines contains I AUTH−NAK, either your PAP username or PAP password is incorrect. At this point, you need to reconfigure your PAP username and password using the following sequence of commands. Note that your PAP username and password are case sensitive.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config−if)#ppp pap sent−username <username> password <password>
Router(config−if)#end
Router#write memory


How do I know if my CHAP username and password are correct?
After you have confirmed that your ISP is using CHAP, issue the debug ppp negotiation command to
confirm that your CHAP username and password are correct.

Router#debug ppp negotiation
*Mar 3 02:51:47.287: Vi1 PPP: Treating connection as a callout
*Mar 3 02:51:47.287: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 3 02:51:47.291: Vi1 PPP: No remote authentication for call−out
*Mar 3 02:51:47.291: Vi1 LCP: O CONFREQ [Closed] id 188 Len 10
*Mar 3 02:51:47.291: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.339: Vi1 LCP: I CONFREQ [REQsent] id 204 Len 15
*Mar 3 02:51:47.343: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.343: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.343: Vi1 LCP: O CONFACK [REQsent] id 204 Len 15
*Mar 3 02:51:47.347: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.347: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.347: Vi1 LCP: I CONFACK [ACKsent] id 188 Len 10
*Mar 3 02:51:47.351: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.351: Vi1 LCP: State is Open
*Mar 3 02:51:47.351: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 02:51:47.395: Vi1 CHAP: I CHALLENGE id 1 Len 32 from "6400−2−NRP3"
*Mar 3 02:51:47.395: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 02:51:47.399: Vi1 CHAP: Username 6400−2−NRP3 not found
*Mar 3 02:51:47.399: Vi1 CHAP: Using default password
*Mar 3 02:51:47.399: Vi1 CHAP: O RESPONSE id 1 Len 26 from "cisco"
!−−− "cisco" is the CHAP username configured on this DSL Router.
*Mar 3 02:51:47.447: Vi1 CHAP: I FAILURE id 1 Len 26 MSG is "Authentication failure"
*Mar 3 02:51:47.447: Vi1 LCP: I TERMREQ [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 LCP: O TERMACK [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 PPP: Phase is TERMINATING [0 sess, 0 load]
*Mar 3 02:51:49.451: Vi1 LCP: TIMEout: State TERMsent
*Mar 3 02:51:49.451: Vi1 LCP: State is Closed
*Mar 3 02:51:49.451: Vi1 PPP: Phase is DOWN [0 sess, 0 load]
Router#undebug all


If you have a CHAP authentication problem, you should see the LCP state go to Open. Directly following the LCP state change you should see PPP go into an Authenticating phase. From this point you see a series of CHAP lines. If the last of these lines shows I FAILURE, you have the wrong CHAP username and password. Use the following sequence of commands to correct your CHAP username and password. Note that your username and password are case sensitive.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config−if)#ppp chap hostname <username>
Router(config−if)#ppp chap password <password>
Router(config−if)#end
Router#write memory


How do I know when PPP authentication is successful?
The following example shows a successful CHAP negotiation.
Router# debug ppp negotiation
<... snipped ...>
*Mar 3 03:30:09.335: Vi1 LCP: State is Open
*Mar 3 03:30:09.335: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 03:30:09.379: Vi1 CHAP: I CHALLENGE id 41 len 32 from "6400−2−NRP3"
*Mar 3 03:30:09.379: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 03:30:09.379: Vi1 CHAP: Username 6400−2−NRP3 not found
*Mar 3 03:30:09.383: Vi1 CHAP: Using default password
*Mar 3 03:30:09.383: Vi1 CHAP: O RESPONSE id 41 Len 26 from "cisco"
*Mar 3 03:30:09.431: Vi1 CHAP: I SUCCESS id 41 Len 4
!−−− CHAP negotiation was a success.
*Mar 3 03:30:09.431: Vi1 PPP: Phase is UP [0 sess, 1 load]
<... snipped ...>
Router#undebug all


The following example shows a successful PAP negotiation.
Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:33:19.491: Vi1 LCP: State is Open
*Mar 3 03:33:19.491: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]
*Mar 3 03:33:19.495: Vi1 PAP: O AUTH−REQ id 255 Len 16 from "cisco"
*Mar 3 03:33:19.539: Vi1 PAP: I AUTH−ACK id 255 Len 5
*Mar 3 03:33:19.539: Vi1 PPP: Phase is UP [0 sess, 0 load]
!−−− PAP negotiation was a success.
<... snipped ...>
Router#undebug all





Popular Posts