On Wed, 16 Oct 2002, Mohammed AbdusSami wrote: > Following is the stop record of my accounting configuration. The cause > of termination of this is PORT-ERROR. Can you please me what does it > means.
As Hugh sugested, this is really a NAS-specific issue. But... > Mon Oct 14 04:12:16 2002 > NAS-IP-Address = 212.26.73.240 > NAS-Port = 132 > NAS-Port-Type = Async > User-Name = "[EMAIL PROTECTED]" > Called-Station-Id = "3602428" > Calling-Station-Id = "33610711" > Acct-Status-Type = Stop > Acct-Authentic = RADIUS > Service-Type = Framed-User > Acct-Session-Id = "000DDA8A" > Framed-Protocol = PPP > Framed-IP-Address = 212.24.231.64 > Acct-Terminate-Cause = Port-Error > Acct-Input-Octets = 980238 > Acct-Output-Octets = 9946394 > Acct-Input-Packets = 11304 > Acct-Output-Packets = 10777 > Acct-Session-Time = 8201 > Acct-Delay-Time = 0 > Timestamp = 1034557936 Is this from a Cisco? If so, these snippages are probably relevant: ===================================8<=================================== Date: Mon, 2 Apr 2001 08:35:24 -0700 From: Dennis Peng <[EMAIL PROTECTED]> To: Neale Banks <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: Acct-Terminate-Cause = Port-Error ? "Port Error" indicates that there was a failure in PPP keepalives, ie we were sending out LCP echo requests, and didn't receive a LCP echo reply response 5 times in a row. Perhaps the lower layer already went away and this wasn't signalled properly? Or modem was retraining for a long time? It's hard to say. Is this is on an async interface? Keepalives are turned off by default on async interfaces, so I assume you have it enabled? Dennis ===================================8<=================================== ===================================8<=================================== Date: Mon, 02 Apr 2001 16:49:56 -0800 (PST) From: Aaron Leonard <[EMAIL PROTECTED]> To: Neale Banks <[EMAIL PROTECTED]> Cc: Dennis Peng <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: Acct-Terminate-Cause = Port-Error ? > On Mon, 2 Apr 2001, Dennis Peng wrote: > > Neale Banks [[EMAIL PROTECTED]] wrote: > > > > > > Definitely Async, it's even logged by RADIUS as "NAS-Port-Type = Async". > > > FWIW, the NAS is configured with virtual profiles enabled and is part of > > > a stack. > > > > Oh, ok, it is enabled on vaccess interfaces by default. Since you are > > using virtual-profiles, everyone gets a vaccess interface, which means > > keepalives are enabled. You can turn it off with the "no keepalive" > > command on the vtemplate. Of course if you do so, you might mask a > > lower layer problem. But you might also be working around a buggy > > client. It's hard to say. > Assuming that (a) everything is virtualised and (b) keepalives are a Good > Thing for ISDN callers then the balance probably falls to leaving > keepalive enabled? Alternatively, is there a compromise possible by > relaxing the keepalive parameters? Yes, I think it's reasonable enough to relax the keepalive interval. Say, with an interval of 30s, then the call will drop after 3 minutes of nonresponsiveness from the peer. It's very unlikely that a modem link that hasn't responded for 3 minutes will ever recover. One downside of keepalives is that they may reset some idle timers. Hopefully (in current code) we've fixed all the places where IOS does this, but I believe that Windows will always reset its idle timer when it gets an LCP ECHOREQ. So you may be defeating your clients' idle timer settings (which could be an issue for them if they're paying per-minute charges.) > And, yes I also suspect it's a buggy client (possibly a dodgy modem, > possibly a marginal local-loop It's even possible that Windows has hung (perish the thought). Aaron ===================================8<=================================== Further discussion of this should probably be directed to a NAS-oriented forum (e.g. http://www.cisco.com/warp/public/471/cisco-nas.html ). HTH, Neale. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
