In Solaris, you can add a route whose traffic should go out a specific interface by adding -ifp [ifname] to the route command line. For instance, suppose a host has two interfaces (eri0 and hme0) on the same IP subnet (10.4.2.9/24 with gateway 10.4.2.254), and traffic for just a few hosts needs to go out the secondary hme0 interface. One reason this setup may be needed is for monitoring both some firewalls and the apps that those firewalls protect from a single network management station. On the firewalls you would add host-specific routes for the network management station’s secondary interface via the firewall management network, allowing that interface to talk directly to the firewalls. The primary interface of the network management station gets routed normally, though, and so is able to talk to hosts protected by the same firewalls.
The following command makes this happen:
# route add -host 172.29.4.3 10.4.2.254 -ifp hme0
add host 172.29.4.3: gateway 10.4.2.254
# route add -host 172.29.4.4 10.4.2.254 -ifp hme0
add host 172.29.4.4: gateway 10.4.2.254
# route add -host 172.29.7.31 10.4.2.254 -ifp hme0
add host 172.29.7.31: gateway 10.4.2.254
# route add -host 172.29.7.32 10.4.2.254 -ifp hme0
add host 172.29.7.31: gateway 10.4.2.254
Now all traffic for the four hosts above will go out hme0 instead of eri0.
This trick is actually buried in a tiny section of the route(1M) man page that is worded such that my tiny brain didn’t get it. I’m not even sure what ifp stands for. The obvious candidate, the -iface or -interface flag, can’t be right because it requires the use of proxy ARP.
Firewall, Geeky, SNMP, solaris
I’d like to use OpenNMS to discover and collect statistics from the SNMP agent of Check Point FW-1 firewalls running on Crossbeam APMs. The major challenge in doing so is the fact that cpsnmpd in its default configuration defines a MIB view that includes only 1.3.6.1.4.1.2620.1.1 or enterprises.checkpoint.products.fw. This fact means that the sysObjectID MIB object (1.3.6.1.2.1.1.2.0) is excluded from this view, so OpenNMS cannot determine what kind of device it is dealing with. I know of at least one person who is having the same issue trying to discover these agents using CA (Concord) eHealth.
I gathered the above information on the MIB view from looking at a FW-1 R55 installation on a Solaris system; in $CPDIR/lib/snmp I found a file called view.conf with the following contents:
#
# entries are in the following format:
# viewIndex viewSubtree viewStatus viewMask
# where viewstatus is either "included" or "excluded",
# and mask is either "null" or a hex number 1-16 bytes long.
10 .iso.org.dod.internet.private.enterprises.checkpoint.products.fw included Null
This file does not exist on the FW-1 APM installations that I have looked at (where the CPMs are running XOS 6.0.1 and 7.0.1), but the $CPDIR/lib/snmp directory does exist. I would propose creating the view.conf here with the following contents:
#
# entries are in the following format:
# viewIndex viewSubtree viewStatus viewMask
# where viewstatus is either "included" or "excluded",
# and mask is either "null" or a hex number 1-16 bytes long.
10 .iso.org.dod.internet.private.enterprises.checkpoint.products.fw included Null
10 .iso.org.dod.internet.mgmt.mib-2.system included Null
That should add the MIB-2 system group to the default MIB view, allowing most network management systems to discover these devices. A cprestart will almost certainly be needed to get the cpsnmpd to reload its view configuration, though sending a HUP signal to the running cpsnmpd process might do the trick.
Firewall, Geeky, OpenNMS, SNMP
