You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While developing new functionality related to SNMP collection in NAV, a developer's workstation isn't necessarily attached to a network that provides the developer with the necessary access to communicate with the require set of switches/routers etc. For internal equipment, this is usually solved by connection a VPN, but sometimes, the devices one needs to talk to are located at a customer site where there is no VPN access.
In our case, we often have SSH access to a Linux server at the customer premises - a server that is allowed to communicate with the customer's switches and routers. We have an internal recipe for how to establish a working SNMP tunnel to the customer's equipment using a combination of SSH and socat, but it would be advantageous to publish this recipe as part of NAV's hacking documentation.
The text was updated successfully, but these errors were encountered:
While developing new functionality related to SNMP collection in NAV, a developer's workstation isn't necessarily attached to a network that provides the developer with the necessary access to communicate with the require set of switches/routers etc. For internal equipment, this is usually solved by connection a VPN, but sometimes, the devices one needs to talk to are located at a customer site where there is no VPN access.
In our case, we often have SSH access to a Linux server at the customer premises - a server that is allowed to communicate with the customer's switches and routers. We have an internal recipe for how to establish a working SNMP tunnel to the customer's equipment using a combination of SSH and socat, but it would be advantageous to publish this recipe as part of NAV's hacking documentation.
The text was updated successfully, but these errors were encountered: