RCYPND when pulling an ethernet cable

[cyberspace]

Is it just me, or is this just really pointless?

I was doing some work on our main switches on Thursday and they rebooted to update config. Next thing I know, none of our System I's were accessible and looking at the console showed RCYPND for the eth interfaces, which I expected.

Unfortunatley my usual fix didn't help and I ended up restarting the machine.

My query is...what's the point of this? Surely if a cable becomes disconnected for whatever reason, it should just realise when it's back in?

Is there any way to increase delay before RCYPND, or otherwise some kind of workaround to avoid it? Just seems so inconvenient.

What's the logic behind doing this anyway?

Thanks!

'When all else fails.......read the manual'

 

[Kozusnik]

I think the best way to avoid it is to vary off the lines before that type of work. I'm surprised that varying them off and back on wouldn't fix your problem. Normally that should do it. Let me look into some of the system values and see if there's something there (or the line descriptions themselves).

Mark

 

[cyberspace]

Mark,

Thanks for that.

Typical procedure that I would perform is:

- End interfaces for a particular connection (and any Domino servers that are active on this connection)
- vary off line descriptors

The issue is that if i want to do any work during office hours, there is a risk that if a cable disconnects or something loses power, it has the potential to snowball into a big problem!

In the past, I have been able to end the RCYPND state line descriptors and then vary on again, but this time it said could not be varied off because it was in use, despite its status.

I appreciate any input you can give.

'When all else fails.......read the manual'