Intermittent DSL and PPP Negotiation diags.

After a ongoing issue with an intermittent dsl connection, and the circuit provider not finding any issues with physical cabling part of the diagnostics i took was to ‘debug ppp negotiation’ and see what i could find.

The output of the negotiation is show below, This was extracted in notepad ++.

From the debug we could see that LCP was timing-out. Notice that all the CONFREQ are outgoing messages (O), none are incoming so we are getting no response from the other end. Another a way of showing this is the constant increment on the message ID. we are getting no responses.

Now if attributes were incorrect we would be getting at least a response to tell us they are CONFNAK or CONFREJ but as a result of this we need to look in other areas which could also effect LCP, such as:

* VCI/VPI settings ?
* AAL5MUX or AAL5SNAP ?
* PPPoA or PPPoE ?

CommandS which can verify this are ‘show run’ and ‘show atm pvc’

After a bit of reading i found out that the preffered encapsulation for this circuit was AAL5MUX (this will not always be the case). The CCE device used to configure teh connection was defaulting to AAL5SNAP. This had to then be manually changed.

To manually change the encapsulation i typed the following commands.

 (config)#interface atm 0/0/0
 (config-if)#pvc 0/38
 (config-if-atm-vc)#encapsulation aal5mux ppp dialer

After changing this and then shutting down the correct interfaces. The connection came back up and remained stable.

GNS3 CCP encountered problems

GNS was a brilliant substitute from packet tracer for me. It didn’t have the restricted IOS commands and really did allow me to learn a lot more.

The usual stuff is all over the internet (idle PC/hyper-visors etc..) My first real problem with CCP was getting its not loading and once i resolved this there was an issue with half a screen picture only. Here i’ll show how to corrected this and also how to get your GNS communicating with your PC (as CCP is ran on your machine) or VM machine which also was needed during CCNA security study.

These were the issue’s i came across:

* CCP stuck at Retrieving Port

* Not getting full Screen on CCP

The fixes for these were quite simple, all we need to do is ensure we run as administrator and ensure IE is running in compatibility mode.

To run as administrator we just right click and select run as administrator.

The second issue is a problem with IE and compatibility mode, to resolve this all we need to do is set IE to run in compatibility mode. Go to Internet Explorer then click tools>compatibility view settings and either tick the box ‘display all websites in compatibility mode‘ (you can also add 127.0.0.1 to the allowed sites, but its just easier to tick a box and it may also solve future issues you come across). Compatibility view is really designed for older browsers, but not many of us use the really old ones these days.

CCP should now be up and running. However we also now need to ensure GNS3 can talk to it and this is where we have to set up a new loopback adapter in our machine, and connect it to a router in GNS.

To do this we must use the Add new Hardware Wizard. Click Start>Search and type hddwiz.exe and enter. Once the wizard runs click next choosing Install hardware Manually > Network Adapters > Manufacturer = Microsoft and Network Adapter = Microsoft loopback > Next to install and finish.

The you need to locate this loopback adapter (Network and sharing centre) and configure it an IP. Make sure the IP is in the same subnet as the router interface in GNS that your are connecting to the loopback (so example 172.16.0.1/30 router and 172.16.0.2/30 loopback).

If you have a Virtual Machine you want to configure and run CCP on that, then a network adapter needs to be created for the VM and the IP address details configured on that new adapter.

I use Oracle for my Virtual machines (they should come with a ready Virtual adapters, but just in case to add one in oracle VM click on File > Preferences > Network > Add host only adapter. (Ensure that if you are doing it this way that your VM amchine is set up as host only adapter and not NAT in the network settings)

Below is an example

Once we are happy with the adapter and given it an IP address we need to dive into GNS configure a router. Drag a cloud into the topology (representing the interface) select the adapter in the cloud settings (see below). Then connect it up.

Below is an example of the router configuration, ensure in that ip http secure-server, a username, local authentication and ssh is set.

username dan privilege 15 secret dan1234
interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.252
duplex auto
speed auto
ip http authentication local
ip http secure-server
line vty 0 4
login local
transport input ssh

This shows the adapter. If the adapter is not visible you may need to reboot your machine. I have no idea why but this has happened to me a few times.

And that’s it now you should be able to use CCP. The latter adding a interface in GNS is quite useful, especially if you want a server running on a VM and want it connecting to your network.

Also i appreciate this post maybe a little long and dumb’d down in certain areas, im new to this so please be patient. If some of the above information is incorrect please let me know and if true i’ll gladly correct,

Thanks.

PPP Negotiation Process.

PPP is a Data-link communication protocol In order for it to successfully complete it must go through certain phases. There are 3 main components/steps to PPP and its negotiation process:

Step 1: – LCP (Link establishment Phase).
* This is where parameters are specified for th link o be established, both devices need to agree on authentication type, compression, error detection, multilink and ppp callback. Once the values are agreed it can move onto step 2 or 3.

Step 2: – Authentication (PAP,CHAP or EAP).
* This is an optional phase, but if implemented both devices need to know that the device they are speaking to is who they say they are.

Step 3: – NCP ((Network Control Phase).
* This is the laye 2 to layer 3 transition phase. It provides communication with the IP layer (IPCP). Gives us an IP address we can then communicate with.

One way of verifying step 1 is to run a “sh int atm 0/0/0” (will show the lcp status)

LCP REQsent

(LCP OPEN = LCP successful, LCP CLOSED = Indicates LCP failure, LCP REQsent = both sides could not match parameters i.e mis match of encapsulation)

During the process of PPP negotiation the different packets we will see are:

1. (CONFREQ) > The values that are sent to complete stage (request for information).
2. (CONFREJ) > This will be a return packet if the request is not acceptable or not recognizable,
3. (CONFNAK) > This will be the return packet when the request is recongnizable, however some of the values are not accepted i.e Chap is sent but the other end wants to authenticate with PAP.
4. (CONFACK) > When the router values are accepted, (response to the CONFREQ).

There are also:

1. (TERMREQ) > This is when there is a request for a LCP closure
2. (TERMACK) > This is acceptance of the above.
3. (ECHO REQ/REPLY) >- The PPP keep alives for the connection.

Below shows an overview of the process.

DEBUG PPP Negotiation:

The debug PPP negotiation command is useful because it can not only be used as a vital diagnostic tool, but it also shows the full PPP negotiation process.

Below is an extract from a live debug. You can see the router goes through the 3 phases needed for successful PPP negotiation. Now not all PPP negotiation will go through the exact same process, but it still will be quite similar. (i.e. in a scenario where there is no authentication – as this is an optional phase).

The following images shows how to read a debug output.

Below is the extract of the different phases as seen in a debug output.

Here you can see the LCP start. Notices the stage field changes from PPP (global stage) to LCP. The first CONFREQ is an outgoing request with an ID of 1. However it is followed by an incoming request (ID 124), requests specific LCP attributes (CHAP authentication, MRU, Magic number). The router automatically responds to request which is a CONFACK with its matching attributes. Notice that the response has the same ID number. This way we can match the incoming and corresponding outgoing message.

Once both connections have agreed on LCP details they then need to authenticate against one another. In this output you can see that an Incoming challenge is sent from the remote device, This router has responded to the challenge but full authentication has been unsuccessful. We see this sometimes when authentication has to go through multiple hops. Although the response if a fail here, and the lcp establishment needs to start again (always restarts if there is a fail), the next time the router gets to this stage it will bypass this hop “bras-red4.mqd” (or teh bras will just let it through) and the authentication will go straight to the next stage.

This is the last stage on PPP and it is the NCP stage, so that layer 2 can communicate with layer 3. Notice again the change of stage, which now reads ‘IPCP’. It also shows that LCP stage is complete. The key here is the issuing of the gateway IP (the address the IP needs to speak to, to get its credentials) and teh confirmation of this IP. See ID 87. Once the CONFACK is sent. The router now knows it needs to speak to this IP address to progress.