I do not believe that there is enough information in the file that you posted to really answer your question. Obviously there are three iterations of the authorization for IPCP in trying to negotiate the assignment of the IP address. The operation of IPCP interacts with PPP on the connection. To understand what is really happening and to be able to really answer your question well we would need to combine the results of the aaa debug with the results of debug ppp negotiation so that we can see the negotiation between your 5300 and the user device.
It would also help to know how you have aaa configured on the 5300.
I would say that it is not unusual for the router to need to iterate at least three times through the negotiation with the user device.
"Ping results" are taken when connected by dial-up into the AS5300. Ping was initiated from the connected PC to the gateway of AS5300. It drops intermittently. (Please see the file).
Also, can you please explain what could be the cause of the following messages (repeated often) on the debug output file? (Its not an output of debug, but messages repeatedly appearing on the console)
Sep 13 20:15:57.700: %DSX1-6-CLOCK_CHANGE: Freerun clock is now selected as clock source
Sep 13 20:16:01.975: %DSX1-6-CLOCK_CHANGE: Controller 0 clock is now selected as clock source
Sep 13 20:16:27.047: %DSX1-6-CLOCK_CHANGE: Freerun clock is now selected as clock source
Sep 13 20:16:27.683: %DSX1-6-CLOCK_CHANGE: Controller 1 clock is now selected as clock source
Sep 13 20:16:37.962: %DSX1-6-CLOCK_CHANGE: Freerun clock is now selected as clock source
Also please guide me to enhance the configuration for better performance for the dial-in users.
I have looked at the additional information that you sent. I think that the biggest issue is the question about the clock messages. I have not been able to find the DSX1-6-CLOCK_CHANGE message documented. If you have access to the Output Interpreter on the Cisco site you might be able to find more about this particular message. (it will want the output of show version and the message output.) I have seen similar messages before. Basically the freerun clock is an internal clock on the 5300 (it uses an oscillator in the router hardware) and is a fallback if the router loses its external clock. The 5300 is configured to use the external clock from controller E1 0 as primary and external clock from controller E1 1 as secondary. The messages that you are seeing indicate that it is losing clocking from controller 0 and uses freerun, then it tries controller 1 for a bit and loses it, it uses freerun again and then tries controller 0 for a bit and reverts to freerun.
I found messages documented that are similar to the message that you are seeing. Most of them indicate that the appropriate action was to open a case with the TAC. I believe that you have very unstable clock. It would be important to get this resolved.
I believe that the problem that you are seeing with ping may very well be caused by the clocking problem. If you get the clocking problem resolved I suspect that the ping problem will go away.
I looked at the debug output and it looks pretty normal to me. There are some things configured in aaa on the 5300 that do not seem to make much sense but I do not think that they hurt anything. You have configured:
aaa authentication login telnet local
aaa authentication login no_tacacs local
With this you have specified two authentication methods (telnet and no_tacacs) but they are not referenced anywhere in the config that you sent. Either you ommitted some parts of the config or these aaa configurations are extraneous.
You also use these same method names in authorization:
aaa authorization exec telnet if-authenticated local
aaa authorization exec no_tacacs local
If they are not being used I would suggest that they be removed.
It is clear that the authentication calls to tacacs are related to this line in the config:
aaa authentication ppp default group tacacs+
It is clear that the authorization calls to tacacs are related to this line in the config:
aaa authorization network default group tacacs+ local
With this the router needs to check with tacacs to start LCP, to start NCP/IPCP, and as part of negotiating the IP address to be used by the caller.
Those commands are used to specify treatment of clocking on the E1 connections. When you remove the commands the error messages may no longer appear on the log but I suspect that the errors are still happening. The fact that the ping has periodic drops probably confirms this. I believe that the source of the error may be in the router hardware or may be in the E1 lines and their clocking. If you can not open a case with TAC to check the router hardware then the alternative is to work with the provider of the E1 lines. Ask them to test the lines and verify correct operation. Also ask them to verify their expectations about how clocking will be handled on the lines.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...