Cisco PPP Authentication

As a network engineer, you most probably already had to do with PPP authentication at least once or two times in your daily operation.  Even more, if you are going for a Cisco certification (and not only) you should know some stuff about PPP authentication. For today, I’ve planned to deal with back-to-back PPP authentication.

For this back to back scenario, we have the following simple topology:

When we talk about PPP authentication on a end-to-end line we are dealing with 3 major authentication method:

– PAP

– CHAP

– EAP

Now, when we think at security, we can easily observe that PAP is the less secure one and CHAP or EAP are the strongest one.

PAP (Password Authetication Protocol) transmits unencrypted ASCII passwords over the network and is therefore considered insecure. It should be used only as a last resort when the remote server does not support a stronger authentication protocol, like CHAP or EAP.
CHAP (Challenge-Handshake Authentication Protocol) is a more secure protocol as it uses a three-way handshake and the shared secret (password) is never sent on the wires. Instead a MD5 hash checksum is calculated based on the share secret and this one is sent as a challenge to the other peer.
EAP (Extensible Authentication Protocol) is an authentication framework, not a specific authentication mechanism. It provides some common functions and negotiation of authentication methods called EAP methods. There are currently about 40 different methods defined.

When we think of PPP authentication direction there are 2 types:

– one way authentication

– two ways authentication

Pretty obvious, no?

OK, enough with the theory. If you need some more deep understanding of PPP, there is always Internet. Next, I will show you some simple example with PPP authetication using PAP, CHAP and EAP.

PAP type authentication

Let’s assume that in the scenario above, R1 is sending a challenge to R2. Very important! From PPP authentication configuration, you don’t have to do anything to response to a challenge. This is done automatically.

R1
username R2 password cisco
int s0/0
encapsulation ppp
ppp authentication pap

R2
int s0/0
encapsulation ppp
ppp pap sent-user R2 password cisco

Actually that’s it. As I said, pretty simple. You configure R1 to send an authentication challenge to R2 with “ppp authentication pap”. R2 has to reply to this challenge with a username and a password defined with “ppp pap sent-user R2 password cisco”. This username and password have to be defined on R1. No matter what user and password you define on challenged part to be sent back, that information you have to define on challenger.

CHAP authentication type

Configuring CHAP is even easier. In the example below, I will configure R2 to send a CHAP challenge to R1

R1
username R2 password cisco
int s0/0
encapsulation ppp

R2
username R1 password cisco
int s0/0
encapsulation ppp
ppp authentication chap

By default, CHAP is sending the router hostname the user in the three-way handshake process, so there is no need to specify what user to send like in PAP method. As I said before, this method is more secure than PAP.

EAP authetication type

To be honest I didn’t saw too many PPP connections being authenticated with EAP, but is there and I saw some CCIE lab topics so, you should keep an eye on it. Like the other two method this one is easy to implement and is offering more secure level of authetication than PAP.

R1
username R2 password cisco
int s0/0
encapsulation ppp
ppp authentication eap
ppp eap identity R1
ppp eap password cisco
ppp eap local

R2
username R1 password cisco
int s0/0
encapsulation ppp
ppp authentication eap
ppp eap identity R2
ppp eap password cisco
ppp eap local

I believe that the command syntax is telling pretty much all there is. With “identity” you define the user to be send to the peer, “password” it what word is saying and last option “local” is the quite important. By default EAP needs a RADIUS server for authentication. If you don’t have one (exams, quick testing…) then you want EAP to use local database instead of RADIUS.

This  are the basics of PPP authentication. Even if there are not so much in use, try to remember this small steps as you might need them sometimes.

Other Authentication Related Articles in Internet

New XenServer (Midnight Ride beta) is here!

Citrix launched today the new XenServer with code name Midnight Ride. This version is still a beta one and Citrix decided to make it available for download and testing through it’s Beta Program.  As a participant in the Beta Program, you’ll play a critical role in helping the XenServer product team develop and deliver the next edition of the product and provide valuable insight for enhancements in future releases.
This new version of XenServer—the industry’s only fully capable, free virtual infrastructure solution—and Essentials for XenServer boasts many significant enhancements, including:

  • Granular role-based access controls within XenCenter
  • Dynamic memory control and overcommit
  • Enhanced snapshots, including full system state and one-click revert
  • Administrative logging and audit reports
  • Automation for workload balancing
  • Host power management
  • StorageLink site recovery for business continuity
  • Enhanced CPU compatibility for XenMotion

You can download the Midnight Ride beta now or if you feel that you need to know more about the Citrix’s newest product please register for the On-demand webcast

You can also evaluate the advanced management capabilities in Essentials for XenServer by downloading the Evaluation Virtual Appliance to enable Dynamic Workload Balancing, Provisioning Services and StorageLink in a single, pre-configured environment and utilize all the added features include in Essentials for XenServer, Enterprise Edition.

Related articles in Internet

Converting from old to new with the PIX to ASA Migration Tool

Digging through Internet I’ve found a very good article from David Davis explaining how to make your life easier when migrating from PIX to ASA.

The important thing to note about PIX and ASA configurations are that they are different. In other words, to do one thing on a PIX requires a different command on an ASA. The ASA uses a more “IOS-like” configuration where the PIX has its own “PIX-OS” configuration. Here are just some of the differences between the two:

  • The ASA is different hardware and has different interface names.
  • The ASA uses sub-interface commands, like the Cisco IOS.
  • A PIX will use FIXUP commands for application inspection whereas the ASA will use policy maps.
  • On the PIX,outbound and conduit commands are used versus access lists on the ASA.

There are two ways to perform this conversion — manually or by using the automatic migration tool. You may want to perform the conversion manually if you want more granular control, but Cisco offers a PIX to ASA Migration Tool that can perform this automatically. Let’s look at how it works.

Read the full article at: Converting from old to new with the PIX to ASA Migration Tool


Cisco tips: Track down communication issues – Part 2

In the 1st Part of this series, I’ve described the most common steps that you should follow to troubleshoot a total lack of communication between a Layer 2 device (Cisco switch) and an end user connected device. As I promised here is the second part, in which I’ll try to show you what you can check when you have no problem with connection, but still you encounter a degradation in service. By this degraded service, I understand a scenario when you have packet loss for example, or intermitent connection which will affect communication and more than sure will make user users not very happy.

We will stick with the same scenario when a end user device is connected to a Cisco switch. Remember that until now, we just troubleshoot at the Layer 1 and Layer 2. Today we will stick in the same area, so nothing directly related to IP, routing protocols or complex networking environment.

Scenario 2: You have an end device connected to a switch and you have degraded communication

a) Check for errors on the interface:


In this example there is no errors, but if you find something there, you may want to keep an eye on this port. Try to issue the above command couple of times to see if the errors are increasing in real time, as this is the worst case possible and you should take action immediately. Error on the interface can be caused by faulty interface on the switch or on the other end, ethernet cable issue or wrong configuration

b) Check the interface queue and drop packets


Interface queue is very important and you should check it during your troubleshooting process. With the above command you can see how many packets are in the input / output queue, which is the transmit and receive rate and very important if you have packets dropped from input and output queue. Usually this happens when there is a lot of load on the switch and it cannot process as quick as it’s needed all the packets. This lead us to the next step.

c) Check the CPU load on the switch


The command output is longer but most interesting for this example are the first 2 rows which show load in 60 seconds and in 60 minutes. If you have there peaks up to 100, then it’s bad and the device is having some issues that need to be fixed.

d) Identify what process is keeping the CPU busy


Most of the time, this is easy to read and to see what process is taking all your CPU power. When you see there Fifo Error Detection with 100% than you have to think that maybe there is something wrong with the queue on one of the interfaces and try to find which one is having problem. This is not straighforward and you have to check a lot of things, but can be helpful. To be honest, I see a lot of engineers just reloading the device and then problem is solved (if it was due to a hardware issue and not a configuration mistake).

e) Check for memory issue on the switch


Again, if you run out of memory, bad things can happend to your device and as well to the communication with device connected to the switch. Reloading of the device solved about 90% of this kind of problems. I don’t recommend just unplug the power cable as soon as you see a memory problem. First have a look, maybe there is something you can fix without reloading the device.

f) Check for problems with storm-control implementation


In one of previous posts I have explained how you can use storm-control to limit the available bandwidth on a Cisco switch interface. In the example above I set this bandwidth to 1 % from the available one gigabit (I know is stupid, but imagine a typo mistake). Imagine what effect will this have on the traffic. Everything above 1 % is keeped in the queue until this is full and then silent discarded.

e) As a general rule, have a look into the logs (maybe this should be first step!)

If there are a lot of Spanning-tree reconfiguration, interface flapping or anything else that looks suspicious, be sure to check on this as you can find there the root cause for your problems.

Do you have any other tips in regard to this topic? Anything else you check and can be added here? Be sure to comment below and your suggestion will be taken into consideration.

Cisco Borderless Network – Phase 2

Everywhere where I turn my look in the last days I hear about the quick coming of Phase 2 of Cisco Borderless Network. If you are interested, you can register for the event on Cisco website .

I tried to search some documentation to understand what is Cisco Borderless Network and which is the big difference from Unified Communication , but all I could find is mostly marketing related documents which promise the next network miracle, everything interconnected, controlled and monitored from distance.

Then I turn myself to the Cisco blogging community to see what’s there, but also it seems that the things are not so clear there as well. Everybody know about the 5 phases of the new Cisco service:

  • Phase 1: Borderless Network Services – Delivering innovations IN and ON the network that optimize network availability, performance, and security.
  • Phase 2: Borderless User Services – Embedding key services spanning mobility, security, and application performance across all elements of the network.
  • Phase 3: Borderless Policy – Implementing a unified policy framework for managing security, identity, and access to the network and network resources.
  • Phase 4: Borderless Integration Framework – Bringing end-to-end network-to-endpoint intelligence through open, extensible interfaces into the network.
  • Phase 5: Borderless Experience – Converging services and systems to provide a superior customer and employee experience regardless of location, device, or application.

but I which also look more like a marketing ad, than network related topics. On phase 1, I was lucky enough and I could find some direction on technical blog of Ivan Pepelnjak, and in this phase it seems that everything was about the new ISR G2 release. Ivan have some objective observation about the Phase 1 of Cisco Borderless Network:

  • All the embedded “WAN” ports are Gigabit Ethernet uplinks. Good.
  • They claim up to 5-times higher performance than the previous routers. Average. The ISR series was launched in 2004 and Moore’s law predicts 5.8-times increase.
  • Lots of the old interface modules are supported. Amazing; I’m just hoping it doesn’t hurt the performance.
  • They’ve replaced the old half-hearted attempts to include an x86 generic application platform within a router with the Service Ready Engine (another great marketing invention … sounds so much better than a Linux blade) modules, having up to 4GB of RAM and 1TB of hard disk. I don’t want to know how the people who bought the old AXP platform feel reading these specs.
Now going back to the Phase 2, Jim Duffy on NetworkWorld.com Cisco subnet is presuming that this will include :
  • innovations in Cisco’s switching portfolio and how they are relevant to the company’s business
  • service-enabling solutions for video, energy management and trusted access
  • a competitive switching offer for the price-sensitive market segment
  • enhanced support and services

but still there is enough fog around the subject. I think I will register for the Phase 2 European event, on March 18 maybe I will get some more clues about Cisco Borderless Network.

Skipping all this marketing and technical stuff, I’m wondering if the world is really prepared for this. And when I’m saying world I mean networks. I really don’t know what to say. I mean I know it’s cool and maybe positive from financial perspective to turn off light in some remote location, but how your network will support this. If you turn your look around you’ll see that network engineers have more stressing problems with day by day operation like VoIP services, slow data transfer between data centers and LAN security, just to name a couple of my problems.

Another problem is the word of the day: costs. How much it will cost to implement all of this and will companies be interested in implementing such a solution? I know that from marketing perspective everything looks great, because that’s their job, to make it look great, but network engineers might have a different opinion.

If you have some news or thoughts in regard to this topic, please use with trust the comment form.