While working with a third-party network device that uses the UCD-SNMP-MIB implementation, I'm observing the behavior that one each of "nsNotifyShutdown" and "coldStart" trap is generated, everytime snmpd receives "kill -HUP" to pick up config modifications. Does anyone know if this is the "correct / expected / normal" behavior? I mean I could see the rationale behind it (the assumption that snmpd is down due to device reboot), but OTOH it's sort of "crying wolf" when the physical device itself didn't actually reboot. I'd like to avoid creating this kind of "false" alarm, if possible.
Thanks for looking into the source code! Your posts made me question my assumption it was a "kill -HUP". It turns out snmpd was being restarted with the init script. Once I asked the vendor to issuing "kill -HUP" instead, only an nsNotifyRestart is generated.
This document gives several answers on frequently asked questions for PFRv3 channel state behavior.
Q1: What are all the channel operational states from a BR (border role) perspective and what are the rules/conditions to be in each st...
The need was to reach an host inside a LAN through a VPN connection managed by the LAN gateway (Cisco 1921).
The LAN gateway performs NAT and there was a dedicate nat rule for the host i wanted to reach through VPN.
I couldn't connect to the hos...
We have 3 identical switches configured by someone else and would like to claim some of the Gigabit ports(G1/G2/G3/G4) for use on servers. When we try to change the wiring and configuration, we run in to connectivity issues. Attached is a des...