The point I am trying to make is that the symatics of "User request" is
misleading from the perspective of where the 'event' happened to cause the
session to terminate. When our end users call us up saying that "We were
surfing the net and all of a sudden our connection dropped and we had to
dial back in", and we look at their history logs, there are almost always a
lot of CCCs. i.e. they correspond highly to users who are having problems.
(except for the Windows clients with broken idle time outs, but those
result in PPP -Term requests)
The reset M# trick I feel illustrates the _possibility_ that when the PM3
reports the disconnection reason being CCC, the problem could be with the
PM3 in that it was triggured by an event ON the PM3. In the case of the
reset M#, an event generated _at the PM3_, causes the session to drop.
Even though its artificial, the end result is in the dropped connection.
The same thing in theory could be happening during a retrain/reneg, or
perhaps too many CPU cycles stolen by OSPF adj. recalcs.. who knows.
I would say in the end, if we see 8% of all termination reasons being CCC,
x% is the fault of the PM3 and y% is the client's modem. What x and y are,
are impossible to tell. It could be 1:7 or 7:1.
---Mike
Mike Tancsa (mdtancsa@sentex.net)
Sentex Communications Corp,
Waterloo, Ontario, Canada
"Given enough time, 100 monkeys on 100 routers
could setup a national IP network." (KDW2)
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>