I have a couple of PIX firewalls running 6.3(5) and LMS 3.1 has discovered them, however it flags them as unreachable. LMS is on the inside and the appropriate config is in each PIX. I have done SNMP walks from the server to each PIX and they respond, however I think LMS is trying to poll the inside and outside interfaces, obviously only the inside one will respond.
Is this normal behaviour and is there any way to get LMS not to poll the outside interface?
Thanks for the quick reply. This is all in a test lab so there is no priority, hence my late reply... I have just had a fan fail in the host server this machine is running in so I had to play around with that for the last hour or so as well......
Anyway I have just checked and what you asked:
PIX Inside - 192.168.250.10/30
PIX Outside - 10.1.1.254/24
Both interfaces are also participating is OSPF so the routes are all in the routing table.
I have verified the LMS server has Telnet & SNMP access to the inside interface of the PIX via the CLI & some freeware SNMP tools to do a SNMP walk. The preferred management IP is set to 'Resolve by Name' and the Preferred DCR Display Name is set to 'FQDN'. The inside IP address is resolvable in DNS.
If I open Common Services, Unreachable Devices the IP address of the inside interface of the PIX is listed with nothing in the System Name & SysObjectID columns, 'System' in the Found by Modules column and 'Unreachable' in the Status column. If I look in DFM, Alerts & Activities there is a Reachability alert for the PIX (Event_Description Unresponsive) that shows the outside interface and its IP address.
Remove the PIX from DCR, and add the inside interface IP as a seed device for Discovery. Make sure the community string in Discovery's SNMP settings page is correct for the PIX, and run Discovery again. Is the PIX properly picked up?
OK, sorry for the delay the fan in the server decided to fail again. Anyway its sorted now.
I did what you suggested, removed the PIX from DCR and then added the inside interface as a seed device and ran discovery again and the PIX isn't actually discovered and appears as unreachable :o(
I am trying to understand if this is the expected behaviour, I can sort of get that it can't reach the outside interface but I thought LMS would be intelligent enough to know its a Firewall and not bother trying to reach this interface?
Any other suggestions?
If you did as I said, and the PIX was a seed device, what could be happening is that the inside address resolves to a hostname, but that hostname resolves back tot he outside IP address. If that is the case, then Discovery will attempt to manage the PIX using the outside interface.
If DNS resolution is symmetric, then I will need to see a sniffer trace of the Discovery processing filtering on traffic to the PIX's inside interface.
Only the inside interface is in DNS, the outside interface does not resolve to anything. I have just repeated the procedure but I put WireShark on and spanned the switchport the PIX is connected to. One obvious thing is PIX 6.3(5) only supports SNMP v1 so there are no replies to the SNMP v2 gets. I have just verified this from the CLI with SNMPWALK and it only replies when the version is set to 1.
In the trace I also noticed the LMS server periodically (every 90-seconds?) tries to ping the outside interface of the PIX.
Yes, Discovery only uses v2c and v3. I had thought a bug was filed about its lack of v1 support, but I cannot find it. Certainly, if the PIX is running older code, that would explain why it's unreachable.
The ICMP messages are coming from DFM. You can unmanage the IP address on the outside interface in DFM > Device Management > Device Details. Once you do that, the pings will stop.
If I add the device manually or import it I can see on the trace the LMS server attempting to discover the device. It tries a few times using SNMP v2c and then tries v1 which obviously works (it also telnets to the device) It correctly discovers it as a PIX 501.
If I could get PIX 7.x for a 501 I would be happy, unfortunately Cisco never kept their word on releasing 7.x code for the 501 or 506 so this isn't going to happen.
This last part sounds more like RME than Discovery. RME will attempt to build the inventory and fetch the config from newly added devices. RME will use SNMPv1 to get the inventory.
Great, I assume you verified the behaviour yourself before creating a new BugID. Is it likely this will get fixed, since PIX OS 6.3 is EOL? Or will is just remain as a known bug.