cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4847
Views
0
Helpful
8
Replies

ASA 5505 LCP terminated: loosing connection every so often

2colin-cant
Level 1
Level 1

hi,

i'm a little lost with interpreting the following debug messages of an ASA 5505 running "asa724-k8.bin".

I'm loosing the connection every so often after 20-45 Minutes:

%ASA-3-403503:PPPoE:PPP link down:

%ASA-3-403503:PPPoE:PPP link down:Peer Terminated

%ASA-3-403503:PPPoE:PPP link down:

%ASA-3-403503:PPPoE:PPP link down:LCP down

Debugs are attached.

thanks

colin

8 Replies 8

Not applicable

Error message: %PIX|ASA-3-403503: PPPoE:PPP link down

Explanation : The PPP link has gone down. There are many reasons why this could happen. The first format will display a reason if PPP provides one.

Recommended Action : Check the network link to ensure that the link is connected. The access concentrator could be down. Ensure that your authentication protocol matches the access concentrator. Ensure that your name and password are correct. Check with your ISP or network support person.

Well, so far i found out that i get a "close Session" PADT message from the ISP Side:

===========================================

Debug while loosing connection: BEG

===========================================

ciscoasa#

PPP va close, device = 1

PPPoE: PPPoE:(Rcv) Dest:0021.a0a8.ec70 Src:0090.1a41.45bc

Type:0x8863=PPPoE-Discovery

PPPoE: Ver:1 Type:1 Code:A7=PADT Sess:4178 Len:0

PPPoE: PADT

PPPoE: Shutting down client session

PPPoE: send_padi:(Snd) Dest:ffff.ffff.ffff Src:0021.a0a8.ec70

Type:0x8863=PPPoE-Discovery

PPPoE: Ver:1 Type:1 Code:09=PADI Sess:0 Len:12

PPPoE: Type:0101:SVCNAME-Service Name Len:0

PPPoE: Type:0103:HOSTUNIQ-Host Unique Tag Len:4

PPPoE: 00000001

PPPoE: send_padi:(Snd) Dest:ffff.ffff.ffff Src:0021.a0a8.ec70

Type:0x8863=PPPoE-Discovery

PPPoE: Ver:1 Type:1 Code:09=PADI Sess:0 Len:12

PPPoE: Type:0101:SVCNAME-Service Name Len:0

PPPoE: Type:0103:HOSTUNIQ-Host Unique Tag Len:4

PPPoE: 00000001

PPPoE: padi timer expired

===========================================

Debug while loosing connection: END

===========================================

In the RFC it says, that a PADT Message with a Code of 0xA7 is received, the session will be terminated, this by the ISP side or am i misinterpreting those messages?

Please refer to my attached files for further debug info.

additionaly i found following:

======================

PPP No response to 4 echo-requests

PPP link appears to be disconnected.

PPP ccp lowerdn: fsm=0x4113b60, dev=1, state=3

PPP ccp close: fsm=0x4113b60, dev=1, state=1

PPP xmit, ifc = 2, len: 8 data: ff03c02105030004

PPP va close, device = 1

======================

how do i change those ppp / lcp values?

in order to set them to 0 or similar to ignore ppp / lcp timeouts so that my ppp connection stays up, as nailed up connection.

you really don't want to ignore LCP echo-requests or echo replied. Both LCP exch-request/reply or Link quality reporting are mechanisms for the host to figure if there is a live ppp peer at the other end of the link.

i would have thought that a echo request is periodically sent out every 10 seconds. So your capture indicates that you may have had no ppp peer for up to 40 seconds. The link appears to be disconnected..better kill the existing PPP link re-negotiated again.

Hi There,

Googlin' somewhat, i discovered this post. I currently have the same problem, also with an ASA5505.

Situation is as follows:

- ASA Was configured to use DSL PPPOE, in combination with a site-to-site vpn. Working marvelous

- Fiberoptic connection was delivered, provider KPN. Also PPPOE.

- Fiberconnection configured on second interface, to test.

- Fiberconnection PPPOE seems to be working, so configured this one to automatically use metric 1 als route.

- Reconfigured firewall, and NAT global.

- Reconfigured vpn both sides.

All is working! Job done, you would say.

Now, asa is dropping PPPOE connection from FiberOptic after a while.

Turning on debug pppoe packet/error/event shows similar notifications saying Padi Timer Expired.

How can i fix this? is it a firewall issue, nat, or default route?

Regards, and thanks for sharing.

David Hornstein
Level 7
Level 7

Hi Colin,

To me the PPPoE debug is a bit of a distraction.

It would be wonderful just to see the PPP debug and not a PPPOE PADI etc.. but that's just my preference :-)

If the Service provider is sending PPP LCP echo request, these act almost like a keepalive to verify the PPP link from the PPPoE access concentrator to the client is up and running. If the ASA doesn't respond, the Service providers access concentrator 'thinks' ah this link is down.

The PPPoE access comncentrator send another LCP echo request and the client should send a echo reply.

Usually in a PPP scenario, both ends send LCP echo requests and expect to see LCP echo replies. As both ends of a PPP link want to know if they are sending packets to a real end point, and that this end point is still up and running.

Or if the Service provider doesn't see the LCP echo reply it will be patient and resent a LCP echo request. But if it still doesn't get a response to a echo request, maybe as a result of congestion over the PPPoE interface and Echo replies getting dumped, the service provider will send a PPP LCP terminate request.

It does this as it has to assume that the link is down between the Access concentrator and the ASA PPPoE client, but it send the LCP terminate request so if the remote end of the link is really up, it will have an option to restart ppp negotiation again and bring up the PPPoE link. This i believe what you are seeing.

The ASA should then start to initaite a PPPoE session again. You will keep on seeing;

%ASA-3-403503:PPPoE:PPP link down:

%ASA-3-403503:PPPoE:PPP link down:Peer Terminated

%ASA-3-403503:PPPoE:PPP link down:

%ASA-3-403503:PPPoE:PPP link down:LCP down

As the Service provider is not seeing an appropriate response to it sending LCP echo requests.

The ASA should be responding to LCP echo requests with LCP echo reply, worthwhile checking this in a debug. (LCP echo requests and replied are very different to ICMP echo requests and echo replied)

The problem could be caused by LCP echo-replies being lost due to congestion.

Again, would be wonderful to see how often you are receiving LCP echo-requests from the service provider and the responses.

Interesting to see a wireshark or ethereal capture of only PPP LCP negotiation and LCP packets. To really see where the problem is.

Sorry not much help without seeing a packet capture..

regards Dave

For the hole info/debugs/config snips/ check out, which i aswell posted to the newsgroup:

http://groups.google.ch/group/comp.dcom.sys.cisco/browse_thread/thread/99a99befd9ea75d6?hl=de&q=colin.cant+ASA

Hi Colin,

You asked the questions;

how do i change those ppp / lcp values?

in order to set them to 0 or similar to ignore ppp / lcp timeouts so that my ppp connection stays up, as nailed up connection."

You can't really ignore what is happening.  If PPP send out Link Control protocol (LCP) Echo requests, it wants to see echo-replies.

If it doesn't get any response to the echo-requests,  as you suggested four attempts, then PPP should reset the liink as it has to  assume that the Point to Point (PPP)  link  to a Service provider is down.  If it does get a echo-reply at any time, during it's retry attempts,  it will reset the counter  and assume the PPP link is working.

That really is a fair behaviour for one end of the PPP link.   It's gotta assume that there is a link issue if it fails to get any  echo-replies to it sending out echo-requests.

regards Dave

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: