SNMP Polling from UCS Manager 1.4

I am having trouble with SNMP Polling from UCS Manager 1.4(1j).
I seem to only get SNMP data from Nexus such as those described in (http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/mib/reference/NX5000_MIBRef.html) I don't see any OIDs corresponding to those mentioned specifically for UCS listed in (ftp://ftp.cisco.com/pub/mibs/supportlists/ucs/ucs-manager-supportlist.html).
Documentation on the cisco web site said that UCS Manager 1.4(1) and above will have MIBS such as CISCO-UNIFIED-COMPUTING-EQUIPMENT-MIB available.
Is there a separate IP addresses I should poll for these or any specific things that need to be set up?
I am not sure how we can gain access to the UCS related MIB objects exactly. The description on SNMP enable for UCS Manager is very brief (http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/gui/config/guide/1.4/UCSM_GUI_Configuration_Guide_1_4_chapter6.html#task_2054446421216050764)
It only described the community string set up under UCS Manager ->Admin->Communication Management -> Communication Services, bu didn’t really say anything about which IP addresses from the Management Interfaces should be used to get them.
Has anyone successfully polled data from say the CISCO-UNIFIED-COMPUTING-EQUIPMENT-MIB and be able to help?
Thanks in advance.

Yes indeed.
I learnt about the CISCO-UNIFIED-COMPUTING-EQUIPMENT-MIB and the other Cisco UCS Manager MIB Support list by selecting UCS Manager under the Unified Computing drop down on this http page you quoted.
(http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/mib/reference/UCS_MIBRef.html)
Is there anything specific from those docs you are referring to that would make it such that we get the Nexus MIBs rather than ones under UCS Manager?
The two IP addresses for Fabric Interconnect A and B under Management Interface only give us info from MIBs listed under the Nexus documentation only. Nothing fir say 1.3.6.1.4.1.9.9.719.1.15.
No SNMP data form the virtual IP address.
Not sure where data under 1.3.6.1.4.1.9.9.719.1.15 would be accessible

Similar Messages

  • Prime Infrastructure 2.0 possible to grab SNMP poll from WAN?

    Our objective is to monitor all our network devices using Cisco Prime Infrastructure 2.0 which include LAN site and WAN site. LAN site we have various of equipments example cisco router 3800, ASA 5510, Catalyst switch 6500 and other access switches. WAN site we have ASA 5520. Currently our ASA is located at ISP which has its own public IP. Question is, it is possible to monitor our ASA 5520 which at WAN site? Attached is our topology sample.
    Note: We has no issues on monitoring LAN equipments.

    Hi Remysyaku
    Are you able to do snmp polling on ASA from any other software like net-snmp etc.
    I mean you need to check whther problem is snmp connectivity or PI is not able to manage ASA.
    Also there is a bug due to which ASA5515x will be shown as unsupported in PI 2.0 but ASA 5520 and further should show managed correctly.
    Thanks
    Mahavir

  • Snmp traps with Call Manager 4.13

    Anyone being able to get snmp traps from Call Manager 4.13 to work. I can walk the MIB and get snmp cold start traps but no Call Manager specific traps

    There is a possibility that the CCM service controls this trap and thus cannot send a trap until it is up. This is an issue seen in many devices not just CCM. CCM supports only certain traps.Refer the following URL for more information
    http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00803f52e1.html#wp1041935

  • Useful OIDs to poll from WISM 5.0.148.0

    Can advise if there are any good and important OIDs that we can snmp poll from WISM 5.0.148.0. Thks.

    check out this url:
    http://forums.cacti.net/viewtopic.php?t=12863&highlight=4400
    snippet:
    making some progress. Here is a link that is extremely helpful
    ftp://ftp.cisco.com/pub/mibs/oid/AIRESPACE-WIRELESS-MIB.oid
    and
    ftp://ftp.cisco.com/pub/mibs/oid/AIRESPACE-SWITCHING-MIB.oid
    I have been able to glean some useful info so far:
    bsnSensorTemperature" "1.3.6.1.4.1.14179.2.3.1.13"
    bsnTemperatureAlarmLowLimit" "1.3.6.1.4.1.14179.2.3.1.14"
    "bsnTemperatureAlarmHighLimit" "1.3.6.1.4.1.14179.2.3.1.15"
    "agentTotalMemory" "1.3.6.1.4.1.14179.1.1.5.2"
    "agentFreeMemory" "1.3.6.1.4.1.14179.1.1.5.3"
    You may need to dig thru the xml files in the url posted above to get more info.

  • UCS Manager Issue with 2.0(2q) and Java

    Hey All,
    I have done some reasearch and realize that we are far behind in our current UCS software but I am running into an issue.
    In Jan/Feb we are supposed to do a major upgrade of both our UCS and CUCM\UC infrastructure at my job. In prep for that I need to get some info from UCS manager.
    The problem is that when I try to connect to the UCS manager I get an error message, see image 1 below. In doing some reading I see the UCSM version we are running is not compatible with Java 7 so I also installed. Java 6 (, 2 different release) which you can see in image 2 below. In running either of those versions I get this issue.
    Sort of a problem since I need info off the UCS to plan for the upgrade but can't get to it to get that info.
    Anyone know of a specific Java version that will work with it?
    IMAGE 1
    IMAGE 2

    You need to totally uninstall Java 7 from your computer.
    Java 6  must be 32bit.

  • UCS Manager Update from 2.1(1a) / 2.1(1b) to full 2.1(3b) cause Policy Reference Error on iSCSI

    Hello,
    I actualy did a UCS firmware upgrade from a mixed 2.1(1a) and 2.1(1b) to a full 2.1(3a) version.
    Chassis are 2208XP, Fabrics are 6248UP and blades are all B200-M3.
    I use firmware policy to update the firmware on the blades.
    Here are the current version of the different componments:
    - CIMC, Adapterers and BIOS Server: 2.1(3b)
    - UCS Software: 2.1(3b)
    - IO Modules:  2.1(1b)
    - Fabric Kernel / System : 2.1(1b)
    After UCS Software update when I connect on UCS Manager I got several warning referencing the error "Policy reference autProfileName does not resolve to named policy" on different parts.
    I have follow some post to resolve some of them:
    - iSCSI nic is created without Authentication profile issues:
    https://tools.cisco.com/bugsearch/bug/CSCui43905
    - Default SOL policy issue:
    https://tools.cisco.com/bugsearch/bug/CSCtl88314
    This resolve a lot of error but I'm still having errors like this on all my iscsi NIC:
    Causing this:
    Right now the update of the IOMs and FIs are on standby until I resolve this.
    Can I have some help please.

    It looks like you are hitting:
    https://tools.cisco.com/bugsearch/bug/CSCui43905
    Symptom:
    Warning with the text "Policy reference  authProfileName  does not resolve to named policy" is seen when creating  an iSCSI nic on a service profile.
    Conditions:
    Issue happens only when iSCSI nic is created without an Authentication profile
    Workaround:
    Use Authentication profile
    Create a Default Authentication Profile
    Existing  warnings from the previous version would still exist even after the  upgrade and that can be isolated only using the above work around. If  new service profiles are created on the 2.2.1b version will not  experience this issue.
    Here is how to create an authentication profile:
    http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/gui/config/guide/2.1/b_UCSM_GUI_Configuration_Guide_2_1_chapter_011111.html#task_5DBBCD17FFA046A395B4493104838B1F

  • Clearing UCS Manager fault about unused adapter uplink from C-series

    I have a number of C240M3 servers in a UCS infrastructure.  They all have two VIC 1225 adapters and when they were initially connected, the technicians accidentally connected the second adapter on some of them to the FEXs.  For now at least, we only want the first adapters used (both ports - one to each FEX).  However, since adapter 2 was connected at one point, UCS Manager won't stop giving these faults:
    F0206 - Adapter 5/2 is unreachable
    F0209 - Adapter uplink interface 5/2/1 link state: unavailable
    It doesn't seem to have a way to clear the faults without reconnecting that second adapter.  Re-acknowledging the server didn't help and I'm not sure I want to try decommissioning them and then getting them to appear in UCS again.
    Does anyone know how to manually clear these faults?

    Hi Kenny,
    Correct; the second PCIe card is not connected to a FEX anymore.  I tried reack'ing the FEXs but that didn't help, unfortunately.  (If it helps, the fault appears in the individual servers' Faults tab - the FEXs don't show any faults.)

  • SNMP polling for 5108 Chassis

    I'm attempting to set up SNMP statistics polling for the 5108 Chassis with 4 half width blade servers. I can get SNMP data from the 6120 Fabric Extender just fine such as IFs and such, but I don't see any OIDs corrisponding to the chassis.
    Is there a separate host I should poll for the chassis, or perhaps a different community name?
    I'm specifically looking to monitor power draw from the four Chassis PSUs, as well as the two FE PSUs.
    root@sj-mon:~# snmpwalk -v 2c -c public ucs1 .1.3.6.1.4.1.9.9.117.1.1.1
    SNMPv2-SMI::enterprises.9.9.117.1.1.1.1.1.470 = INTEGER: 2
    SNMPv2-SMI::enterprises.9.9.117.1.1.1.1.1.471 = INTEGER: 2
    SNMPv2-SMI::enterprises.9.9.117.1.1.1.1.2.470 = STRING: "CentiAmps @ 12V"
    SNMPv2-SMI::enterprises.9.9.117.1.1.1.1.2.471 = STRING: "CentiAmps @ 12V"
    SNMPv2-SMI::enterprises.9.9.117.1.1.1.1.3.470 = INTEGER: 4538
    SNMPv2-SMI::enterprises.9.9.117.1.1.1.1.3.471 = INTEGER: 4538
    SNMPv2-SMI::enterprises.9.9.117.1.1.1.1.4.470 = INTEGER: 29
    SNMPv2-SMI::enterprises.9.9.117.1.1.1.1.4.471 = INTEGER: 29
    Here is all I've been able to pull for the FE PSUs, and the 4538 value doesn't seem to have any correlation to what's being shown in the UCS Manager under Statistics.
    Thanks!

    There are no stats for the chassis.
    You can only snmpget stats for the "NXOS" part of the Fabric Interconnect.
    You can get snmptraps for all of UCS (go a google for UCS-MIB, and there's a doc explaining this on cisco.com - do a google for site:cisco.com ucs documentation roadmap).
    At the end of the year I believe a full MIB will be available to do what you want.
    If you want stats, use the XMLAPI.
    Cheers
    Steve

  • Monitoring Cisco UCS Manager via HP System Information Manager 7.1 (SIM)

    I am working with a customer to configure HP System Information Manager 7.1 (SIM) to monitor their Cisco UCS Manager.
    The customer is looking to monitor the following:
    - CPU Utilization on manager, blades, servers, etc...
    - Memory utilization
    - Network utilization
    - System inventory
    Alerting is needed for the following:
    - Hardware failures: memory, power supply, drive, etc...
    - Predictive failures
    - Alert messages
    I have the list of all the MIBs provided by Cisco but an having the following issues while loading them into HP SIM.
    While loading MIB "CISCO-UNIFIED-COMPUTING-TC-MIB" I get the following error message:
    Line 128: Error defining object: expected a label, found reserved symbol {
    Line in MIB: SYNTAX Gauge32 {
    Guage32 is imported from SNMPv2-SMI MIB
    To get past this error I found a version of the MIB that removes all the textual conventions that where causing errors.  I have attached the fixed MIB file to this discussion. With the fixed version of the MIB installed in SIM everything compiles and installs except the following two MIBS. CISCO-UNIFIED-COMPUTING-NOTIFS-MIBCISCO-UNIFIED-COMPUTING-CONFORM-MIB Questions:
    1. Is there any way to get the CISCO-UNIFIED-COMPUTING-TC-MIB MIB to install correctly into HP SIM?
    2. Is my MIB load order setup correctly?
    3. Has anyone had success getting HP SIM to monitor and alert for Cisco UCS manager?
    MIB Load Order:
    SNMPv2-SMI
    SNMPv2-TC
    SNMP-FRAMEWORK-MIB
    RFC1213-MIB
    IF-MIB
    CISCO-SMI
    CISCO-ST-TC
    ENTITY-MIB
    INET-ADDRESS-MIB
    CISCO-UNIFIED-COMPUTING-MIB
    CISCO-UNIFIED-COMPUTING-TC-MIB
    CISCO-UNIFIED-COMPUTING-FAULT-MIB
    CISCO-UNIFIED-COMPUTING-NOTIFS-MIB
    CISCO-UNIFIED-COMPUTING-AAA-MIB
    CISCO-UNIFIED-COMPUTING-ADAPTOR-MIB
    CISCO-UNIFIED-COMPUTING-BIOS-MIB
    CISCO-UNIFIED-COMPUTING-BMC-MIB
    CISCO-UNIFIED-COMPUTING-CALLHOME-MIB
    CISCO-UNIFIED-COMPUTING-CAPABILITY-MIB
    CISCO-UNIFIED-COMPUTING-COMM-MIB
    CISCO-UNIFIED-COMPUTING-COMPUTE-MIB
    CISCO-UNIFIED-COMPUTING-CONFORM-MIB
    CISCO-UNIFIED-COMPUTING-DCX-MIB
    CISCO-UNIFIED-COMPUTING-DHCP-MIB
    CISCO-UNIFIED-COMPUTING-DIAG-MIB
    CISCO-UNIFIED-COMPUTING-DPSEC-MIB
    CISCO-UNIFIED-COMPUTING-EPQOS-MIB
    CISCO-UNIFIED-COMPUTING-EQUIPMENT-MIB
    CISCO-UNIFIED-COMPUTING-ETHER-MIB
    CISCO-UNIFIED-COMPUTING-EVENT-MIB
    CISCO-UNIFIED-COMPUTING-EXTMGMT-MIB
    CISCO-UNIFIED-COMPUTING-EXTVMM-MIB
    CISCO-UNIFIED-COMPUTING-FABRIC-MIB
    CISCO-UNIFIED-COMPUTING-FC-MIB
    CISCO-UNIFIED-COMPUTING-FCPOOL-MIB
    CISCO-UNIFIED-COMPUTING-FIRMWARE-MIB
    CISCO-UNIFIED-COMPUTING-FLOWCTRL-MIB
    CISCO-UNIFIED-COMPUTING-HOSTIMG-MIB
    CISCO-UNIFIED-COMPUTING-IMGPROV-MIB
    CISCO-UNIFIED-COMPUTING-IMGSEC-MIB
    CISCO-UNIFIED-COMPUTING-IPPOOL-MIB
    CISCO-UNIFIED-COMPUTING-IQNPOOL-MIB
    CISCO-UNIFIED-COMPUTING-ISCSI-MIB
    CISCO-UNIFIED-COMPUTING-LICENSE-MIB
    CISCO-UNIFIED-COMPUTING-LLDP-MIB
    CISCO-UNIFIED-COMPUTING-LSBOOT-MIB
    CISCO-UNIFIED-COMPUTING-LSMAINT-MIB
    CISCO-UNIFIED-COMPUTING-LS-MIB
    CISCO-UNIFIED-COMPUTING-MACPOOL-MIB
    CISCO-UNIFIED-COMPUTING-MAPPINGS-MIB
    CISCO-UNIFIED-COMPUTING-MEMORY-MIB
    CISCO-UNIFIED-COMPUTING-MGMT-MIB
    CISCO-UNIFIED-COMPUTING-NETWORK-MIB
    CISCO-UNIFIED-COMPUTING-NWCTRL-MIB
    CISCO-UNIFIED-COMPUTING-ORG-MIB
    CISCO-UNIFIED-COMPUTING-OS-MIB
    CISCO-UNIFIED-COMPUTING-PCI-MIB
    CISCO-UNIFIED-COMPUTING-PKI-MIB
    CISCO-UNIFIED-COMPUTING-PORT-MIB
    CISCO-UNIFIED-COMPUTING-POWER-MIB
    CISCO-UNIFIED-COMPUTING-PROCESSOR-MIB
    CISCO-UNIFIED-COMPUTING-PROC-MIB
    CISCO-UNIFIED-COMPUTING-QOSCLASS-MIB
    CISCO-UNIFIED-COMPUTING-SOL-MIB
    CISCO-UNIFIED-COMPUTING-STATS-MIB
    CISCO-UNIFIED-COMPUTING-STORAGE-MIB
    CISCO-UNIFIED-COMPUTING-SW-MIB
    CISCO-UNIFIED-COMPUTING-SYSDEBUG-MIB
    CISCO-UNIFIED-COMPUTING-SYSFILE-MIB
    CISCO-UNIFIED-COMPUTING-TOP-MIB
    CISCO-UNIFIED-COMPUTING-TRIG-MIB
    CISCO-UNIFIED-COMPUTING-UUIDPOOL-MIB
    CISCO-UNIFIED-COMPUTING-VM-MIB
    CISCO-UNIFIED-COMPUTING-VNIC-MIB
    References:
    ftp://ftp.cisco.com/pub/mibs/supportlists/ucs/ucs-manager-supportlist.html#_Toc303691433
    http://www.hp.com/wwsolutions/misc/hpsim-helpfiles/simsnmp.pdf

    Please post "debug ccsip messages".
    Based on your debug you are getting "Cause No. 38 - network out of order."
    You may want to bind SIP to an interface that the IP address is defined which Lync points to.
    Chris

  • Snmp polling across firewalls

    I have an issue with my firewalls polling my snmp stations.  The issue is that my smnp server is unable to poll a connected interface on the firewall on a different network. We are using two /24 networks across a managed connection for redundancy purposes. At either end of the managed connection there is an asa firewall, the firewalls are configured with /24 networks. There is a snmp server on one of the /24 network on either side of managed connection, the servers default gateway points to the firewall connected interface i.e snmp server 1 has an IP address of 10.10.30.13/24 and a gateway of 10.10.30.1 (firewall 1) and snmp server 2 on the other side of the managed connection has a ip address of 10.10.31.13/24 and a gateway of 10.10.31.1(firewall 2), the .1 addresses are the physical interfaces on the friewalls. There is a transit network configured between the firewalls to allow for the routing of traffic between the 10.10.30/24 and 10.10.31/24 networks. The transit  network has an interface with an IP address 10.10.222.1/31 on the firewall on the left side (firewall 1) of the managed connection and an IP address of 10.10.222.2/31 on the firewall on the right side (firewall 2) of the managed connection. Routes have been set up on the firewalls to the 10.10.30.0/24 and 10.10.31.0/24 via the transit network.
    The problem I am having is that the snmp server at 10.10.30.13/24 is not able to poll the firewall interface 10.10.31.1 (firewall 2) and the server at 10.10.31.13 is also not able to poll the firewall interface at 10.10.30.1 (firewall 1)
    The routing and snmp configuration is listed below:
    Firewall 1
    route
    10.10.31.0/24 via 10.10.222.1
    Snmp config
    Listerning port 161
    snmp host access list
    interface_name 10.10.30.13, community string, snmp version 2c, poll/trap, port 162
    A any any access rule is used on the transit interface on either side of the connection
    and a access list has been configured on 10.10.30.1 interface which allows snmp traffic from 10.10.31.13
    Firewall 2
    route
    10.10.30.0/24 via 10.10.222.2
    Snmp config
    Listerning port 161
    snmp host access list
    interface_name 10.10.31.13, community string, snmp version 2c, poll/trap, port 162
    A any any access rule is used on the transit interface on either side of the connection
    and a access list has been configured on 10.10.31.1 interface which allows snmp traffic from 10.10.30.13
    I have been looking at this problem for sometime without much success, can you kindly help

    Hello Roy,
    Do you mean it's not able to get data for that interface???
    Or do you mean you are trying to connect to that IP address?? Cause if that is the case it will never happen as you cannot contact a distant interface (If I am on inside I can ping , ssh, telnet inside but If I will never be able to contac the DMZ interface IP address or outside,etc)
    Rate all of the helpful posts!!!
    Regards,
    Jcarvaja
    Follow me on http://laguiadelnetworking.com

  • Prime SNMP-polls Component although Deleted

    Hello!
    After deleting ("Add / Import / Manage Devices") a non-Cisco component Cisco Prime (v.4.2.2) still SNMP-polls this component every day at 12:00 and 16:00. I removed the
    "Default Credential Sets Policy Configuration" entry for this component and an entry in the "Seed Device" text field with the IP-address of this component but still the component is polled.
    Strange is that the log-file of the component shows an "SNMP: Auth. failure" although the credential set for the component has the correct SNMP community string configured.
    Question now is how to remove the component from Cisco Prime so that the polling no longer occurs.
    Any help is very much appreciated!
    Thanks,
    Jakob

    From your job Browser check which jobs are scheduled for 12:00 and 16:00.
    Also, have a packet capture with the IP of the device which is removed too what kind of snmp request and which community string is being polled.
    Till than if you want to make an ACL on device and restrict the LMS server IP and associate it to snmp as well, if possible, can be an option.

  • Connecting to UCS6120 from Fabric Manager using TACACS

    Standalone Fabric Manager 5.0(4a)
    UCS 1.4(3s)
    I have to log into Fabric Manager using TACACS with SNMPv3 (company network security restriction).
    I launch Fabric Manger using my TACACS account which connects to all the switches in my two fabrics using the same credentials.
    I can connect to all MDS9513, MDS9222i, IBM Bladechassis FC switch modules and all NX5020 switches in the fabrics. Fabric Manager cannot connect to any of the eight UCS6120 switches in the fabrics, returning a status of Unknow User or Password(Server,Client).
    This, I understand, requires the creation of a specific SNMP user, which is fine. However as I am logged into Fabric Manager using a single TACACS account, I cannot supply alternate credentials to a subset of switches in the fabric.
    Is there a work around for this to enable management of the 6120s in FM? or am I missing something.
    Thanks
    Mike Taylor

    Fabric Manager uses the same credentials to access all systems,  these credentials will need to be valid on the UCS platform as well.  Create a local SNMP user on UCS and check.  This needs to be different from any non-snmp authentication accounts on UCS.
    Note that FM cannot manage UCS.  You will be able to view into UCS but not make changes. May not be an issue if UCSM is running end host mode.  To make any changes, you will need to use the UCSM GUI or CLI or other tool for administration.
    Thank You,
    Dan Laden
    PDI Helpdesk
    http://www.cisco.com/go/pdihelpdesk

  • SNMP traps from Solaris 10

    Hi,
    I'm trying very hard to set up a Sun Fire V245 to send SNMP traps when certain hardware or software related events occur. I've been looking at sma_snmp (net-snmp) and the Fault Management Daemon (SUNWfmd) but they seem to be very limited in their capabilities. I have manged to get some traps sent for filesystem fill-ups and high load averages but that is about it.
    Most of all I would like the system to send traps when there is a HW failure such as a faulty FRU or if there are disk failures.
    If anyone can point me to some documentation about this, I would be most grateful.
    /Mikael

    Mikael,
    I struggled through the same thing with a Netra 240 recently. The Sun docs are garbage when it comes to this. I opened a ticket with Sun and after 3 days and 6 hours on the phone I finally got hold of someone who knew how to spell SNMP. Yes, it was that bad!
    Here's the scoop. In Solaris 10 you run Net-SNMP, a.k.a. SMA, snmpd. The old snmpdx is obsoleted and you shouldn't configure it at all.
    Now to get the hardware related traps for the Sunfire and Netra series servers... (what you are really looking for).
    You have to load and configure an additional SNMP daemon for the hardware specific traps.
    (The first doc is rather old, the last one 819-7978-12 is pretty new and is somewhat more relevant.)
    Sun� SNMP Management Agent for Sun Fire� and Netra� Systems: Sun Doc number 817-2559-13
    Sun� SNMP Management Agent Addendum for the Netra� 240 Server: Sun Doc Number 817-6238-10
    Sun� SNMP Management Agent Administration Guide for Sun Blade� /Sun Fire�/Sun SPARC� Enterprise/Netra� Servers: Sun Doc Number 819-7978-12
    And finally the SMA/net-snmp/snmpd guide for the standard Solaris related traps:
    Solaris System Management Agent Administration Guide: Sun Doc Number 817�3000�11
    There are problems with all of the above documents. None of the Netra/Sunfire docs specifically talk about Solaris 10 so read them with caution. They also talk about configuring and running snmpdx and never reference SMA/net-snmp. This is odd because the instructions I got from Sun (finally) were not to run snmpdx, only to run sma/snmpd and additionally run the sunfire/netra snmpd agent.
    The SMA document (817-3000-11) has an undocumented bug, which Sun knows about and is working on but will not reveal to the public. In the section titled "Migration From the Sun Fire Management Agent" it references using a script called masfcnv to convert the sunfire/netra specific snmp config and daemon to work with and through SMA. Since they all use the same ports (161/162) there is some conflict and the masfcnv is script is meant to resolve this by making sma/snmpd a proxy agent to requests toward the sunfire/netra specific hardware daemon.
    The problem is the masfcnv script doesn't work properly. In fact, if you run the script you will destroy your other snmp configurations and may have to uninstall and reinstall the packages to clean everything up. This script hasn't ever worked and Sun is working on a fix but they neglect to mention this in the document which is IMO gross negligence and is a reflection of Sun's overall state of affairs (but that's another ranting thread).
    So what you must do is configure SMA/net-snmp (or whatever you want to call it), and also configure the sunfire/netra specific snmp (after downloading and installing that package).
    Since traps are sent to the remote trapsink using destination port 162, both net-snmp and the netra specific snmp daemons can co-exist here (port 162 is not an open listening port on the machine).
    Port 161 is used for receiving SNMP Get requests and can only be bound to one daemon at a time. So either it is used by net-snmp or the netra snmp daemon, but not both. Since my boxes have not been fully integrated still I can't figure out which daemon 161 is bound to. At any rate, in my application the customer is only interested in receiving traps so the outcome here isn't that important.
    I realize this isn't complete but I'm no expert here and haven't worked through all the test scenarios on a fully configured system. Hopefully though this will help clear some of the confusion propogated through Sun's stupid documents. Good luck!
    /Frank

  • SNMP traps from EMC SRM to SCOM 2012 R2

    Hi,
    I'm trying to configure SCOM 2012 R2 as an SNMP trap listner.  I've seen many articles on setting this up but all are based around SNMP traps from network devices which must first be discovered and identified in the network device list.
    However in my scenario I am trying to monitor/listen for traps send by a Linux box hosting EMC SRM - this management software can be configured to send SNMP traps out so it is these that I need to try and listen for/capture.
    So can anyone explain how I can configure SCOM 2012 R2 to do this.  I have tried to just used the IP of the Linux box and discover it as a network device but it fails - in Network Devices Pending Mgmt it says No response Ping, even though I can
    ping the box from the Server OK - so I am guessing you cant cheat scom in discovering the Linux box as a network device in ths way?
    Can anyone offer any advice for setting this up.  Just to add I've ensured the RunAs Community String (public) and SNMP version is correct on both side...
    Cheers...

    Once the Network Device (Linux server in this case) is discovered you will still need a rule that targets that class and accepts incoming SNMP Traps for that OID, or All OIDs if you prefer.  I found 2 links that may be of help, the first is just a basic
    overview of the SNMP listener in SCOM 2012 as it has changed from the OS Listener in 2007 to a dedicated one.
    http://systemcentertech.com/2012/05/17/scom-2012-built-in-snmp-trap-listener/
    The second link covers SNMP setup, but starting at Step 7 there is a great how-to on creating your own SNMP rule which will be needed to collect your traps.
    http://scom-2012.blogspot.com/2012/07/setting-up-snmp-monitoring-in-scom-2012.html
    www.Practice2Perfect.com

  • SNMP traps from HP NNMi - SCOM

    Hi,
    We wan't to forward snmp traps from hp nnmi to scom.
    I have found a description of a solution for this here: http://social.technet.microsoft.com/Forums/systemcenter/en-US/19c29988-dfe8-4918-b0d5-f3124bcfea95/operations-manager-and-hewlett-packard-nnmi?forum=operationsmanagergeneral
    I have added a server as snmp device. By using snmptrapgen I have also confirmed that the traps are received from scom.
    In NNM I have specified that all traps are to be forwarded to the server which is discovered as a network device. I have also activated the snmp services and set the correct settings. These traps have not been received in scom.
    Have I understood this correctly? If NNMi just forwards the traps, will not the traps have source IPs which is not registered as network devices in SCOM, and therefor be discarded? 
    I would very much like to hear from people how have done a simular type of integration :)
    Thanks in advance, Best Regards

    Yes, I think the Network Devices need to be discovered first in order to receive traps and generate alerts.
    Juke Chou
    TechNet Community Support

Maybe you are looking for