Hey Andrea,
> Seeing these regularly almost every 50mins on SRX345 > > In the logs I see repeated VPN IKE negotiation failed events repeating > hundred of times within few minutes for a VPN that needs to have its config > completed. > > Could the many VPN events cause an RPD slip or they are unrelated? > > What else should be checked to troubleshoot cause? Unfortunately logs have > rotated so cannot go back to see if the last VPN config (partly completed) is > the cause of this or not? Like Jared says, open JTAC, this is a bug in the code, these should never happen. But they can be sometimes benign. RPD like IOS and Windows 3 is cooperatively multitasking, unlike pre-emptive multitasking your desktop and phone are. This means every RPD task must yield its control, so another RPD task may run. This means the developer must be very knowledgeable when something might take a long time, that they'll allow it to yield, and when it's guaranteed to take a short time, so they don't have to think about yielding. But done right, cooperatively multitasking system is the most efficient one. A common mistake is, something they wrote, in their mind could never possibly take long time, but then customer config comes along, which causes pathological long runtime for that task, and then that task runs too long blocking other tasks from running. If you are able to identify what in your config is atypical and might cause long run times, perhaps you can break that config up, streamline it or otherwise and reduce the time that task needs to run. The outcome of blocking RPD task is today bit less bad than it was in older junos, because there is separate process handling keepalives (PPMd) and there are now few RPD threads, so not everything is blocked. -- ++ytti _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
