RME Natted IP table question

rtuttle · ‎02-24-2009

I see a section for the above in RME and warning to ensure the ip address is correct. My question is basically does RME handle natted ip addresses for use in traps, snmp etal?

I have been wading through tons of data on snmp morphing via nat and would appreciate any input on how best to either proxy and or nat without destroying the packets.

thanks

Joe Clarke · ‎02-24-2009

SNMP and NAT does not work. The problem is there is no NAT ALG which can translate IP addresses embedded in SNMP PDUs. For example, the cdpCacheAddress object is an IP address type. The device will send back the address known to it, but the NAT gateway will not translate that address. The result is that applications like Discovery will attempt to contact the unNAT'd address, and fail.

For objects which do not have embedded IP addresses, no problems will be seen. For example, RME will successfully collect inventory for NAT'd devices. However, the IP addresses reported on the interfaces will be untranslated.

The one catch is with config management and image management. These applications require the device to TFTP or RCP data to the RME server. The device must be given the correct (i.e. NAT'd) IP of the RME server. This is done my specifying the RME ID for the devices behind NAT boundaries. This is specified under RME > Devices > Device Management > RME Devices > Edit Device Attributes. The RME ID should be the IP address of the RME server which is reachable to these NAT devices.

rtuttle · ‎06-08-2009

Hi Joe,

Well we visit again this issue of nat and snmp. For a few years I have been rolling out public address space for our multitude of customers on shared services. This to keep their mgmt traffic identifiable. Now comes a newbie who is talking people into undoing this and putting in nat on the firewalls (fwsm) for these customers. I am already having image and config mgmt issues. As well it looks like some discovery is not happening either.

Base question do you or anyone else out there have any other resources, white papers etal that can bolster my case against going to nat for CW? Anything would help.

Thanks

Joe Clarke · ‎06-08-2009

NAT and SNMP don't really mix. The reason being is that it is next to impossible to provide an ALG for SNMP since SNMP packets may contain embedded IP addresses at just about any location. Take discovery for example. LMS walks the ipAddrTable, cdpCacheTable, routing table, etc. All of the addresses that come back in the reply PDUs are UNTRANSLATED. Therefore, LMS tries to discover a non-NAT'd next hop address, and fails.

The only tool in LMS which can work with NAT is RME. It will allow you to specify the NAT'd IP address of the RME server so devices can connect back to it. However, none of the IP addresses seen in RME's reports will be translated. They will be reported as they are seen on the device.

NAT and SNMP isn't a problem which is unique to LMS. It is an industry-wide issue which really doesn't have a good solution. The best workaround is to create VPN tunnels over which you can pass management traffic untranslated.