Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

Steel Belted Radius Carrier AAA and troubleshooting general SNMP issues

0

0

Article ID: KB16053 KB Last Updated: 04 Mar 2017Version: 2.0
Summary:
The SNMP solution may seem simple but it can be tricky to troubleshoot because it is prone to so many silent and subtle failures. Here are some steps to go through when things are not quite working.
Solution:

When ready to test the flow of SNMP data be sure that the SBR product (radius) is started and that jnprsnmpd is loaded. Running a ps -el | grep snmp should suffice. This will also tell you if another SNMP Agent Host is running which may conflict with the SNMP ports that the SBR Agent Host uses. If you see another SNMP Agent Host running on the system and are unsure of which ports it uses, it is strongly recommended to stop the other daemon or it may conflict with SBR Agent Host.

NOTE: If you have not started the Steel Belted Radius SNMP process go to /etc/init.d and run init.jnprsnmpd start.

  1. Open the MIB browser (or execute the appropriate command line syntax) from within your SNMP Manager.  Be sure that the SNMP Manger can ping the IP address of the system where SBR is installed.  If you do not have a MIB browser installed that you can test with, Juniper ships with a simple SNMP walker tool that you can test with right on the server that is running Steel Belted Radius.

    This useful snmpcommand utility is called snmpwalk and can be found in the /snmp/bin directory. The snmpwalk command essentially performs a whole series of getnexts automatically, and stops when it returns results that are no longer inside the range of the OID that you originally specified. 

    • Running the command ./snmpwalk -v1 -c community localhost .1.3.6.1.4.1.1411 dumps all the funk MIB parts.
    • Running the command ./snmpwalk -v1 -c community localhost .1.3.6.1.2.1.67 dumps all the radius MIB parts.

  2. From the MIB Tree (root), open up the directory structure until the individual MIB variables from rauths.mib are available for your selection. It will look like this:
    iso\org\dod\internet\mgmt\mib2\radiusMIB\radiusAuthentication\radiusAuthServMIB\radiusAuthServMIBObjects\radiusAuthServ

    Underneath this directory are all the MIB variables as listed in rauths.mib. Select radiusAuthServIdent and send the get_request. This may be done by right-clicking on the variable and selecting ‘get’ or by some other means according to the manager software.

    The response value displayed in the SNMP Manger MIB browser GUI will indicate the name of the SBR product as well as the current running version of the software. For example:

    radiusAuthServIdent.0 (octet string) Steel-Belted Radius Service Provider Edition v04.00.234

    A successful response shows that data is flowing from the SNMP Manager, across the network to the SBR system where it’s received by the SBR Agent Host, then passed to the Sub Agent, and then returned back to the Agent Host, which sends it across the network and back to the SNMP Manager station.

    It’s important to note that SBR does not allow any SNMP set operations to be performed. From a security standpoint Juniper does not agree that a production AAA server should support a remote reset via SNMP.

Steps for Troubleshooting any failures when using SNMP gets and or TRAPS

  1. It is easy to believe that SNMP is functional because a walk returns results when in fact you are querying the default platform agent and not SBR (i.e. you forgot to shut down the default platform agent).  If no traps are generated and/or why SBR specific MIBs return no results check if the default platform agent was shutdown.

  2. People frequently make what they believe to be cosmetic changes to the jnprsnmpd.conf file (adding whitespace for pretty indentation, reordering sections and/or parameters) when in fact this file is highly sensitive to whitespace and line ordering. Check any changes made. If nothing works or seems to work partially see number 1.

  3. Confirm addressing.  The jnprsnmpd.conf com2sec parameter is a frequent source of trouble because it is unforgiving of addresses that don’t end in the right number of zero bits in relation to the network mask when CIDR notation is used. For example, 192.168.0.1/24 is illegal because /24 says the last 32-24=8 bits of the address must be 0 so anything other than 192.168.0.0/24 silently fails. 

  4. Check the jnprsnmpd.conf trapsink and trap2sink parameters. These are a frequent source of trouble because at least one will silently fail if both are specified. That is, you can specify multiple trapsink OR multiple trap2sink but you MUST NOT MIX the two.

  5. Changing the jnprsnmpd.conf a3s_admin_parameters (formerly sbr_admin_parameters) host and/or port must be done carefully so that it agrees with radius.ini and typically a few xml files (depending on release/patch level): sbr_administration.xml, sbr_ccm.xml, system/config/sbr_admin_session_config_provider.xml, not to mention the user’s SNMP querying tools’ configuration.  Again, any configuration mistakes generally result in silent or seemingly partial failure (see number 1).

  6. If the SNMP Manager cannot ping the Solaris system where SBR is installed, check the network.

  7. If the RADIUS Authentication Server MIB (rauths.mib) or the RADIUS Accounting Server MIB (raccs.mib) variables are not visible with the SNMP Manager’s MIB browser, check your SNMP Manager documentation for the appropriate steps for loading/importing new MIB files as well as for browsing MIB files. Keep in mind that each MIB file may need to be compiled within the SNMP Manager software.

  8. If you would like to use another method to verify that the get_request is being received and responded to by the SBR system, the Solaris/Linux snoop command may be useful. From the system where SBR is installed, run the following command:
    snoop udp port 161 <machine_name>
    The resulting output for a successful snoop of the request and response would look like this:
    SNMP_Manager -> SBR_System UDP D=161 S=3096 LEN=52
    SBR_System -> SNMP Manager UDP D=3096 S=161 LEN=54

    Note that the snoop command supports various switches for more detailed output of the PDUs.

  9. Check the /opt/JNPRsbr/radius/access.ini file to make sure the SnmpAgent subagent has been assigned the correct permissions.  The access.ini file should specify "_system.localhost = SnmpAgent" somewhere in the "[Users]" section.  This is required to enable the SNMP subagent to access the "TCPControlPort".

    The admin.ini file should specify the following to grant read access for all of these objects to the SNMP subagent.
    [SnmpAgent]
    RAS-Clients=r
    Users=r
    Profiles=r
    Proxy=r
    Tunnels=r
    IP-Pools=r
    IPX-Pools=r
    Access=r
    Configuration=r
    Statistics=r
    CurrentUsers=r
    Report=r
    ImportExport=r
    License=r

  10. Last, troubleshoot the setup while the SNMPagent is in debug.

    Start the SNMP agent via /opt/JNPRsbr/radius/snmp/bin/startsnmp.sh.  Leave this console window running.  In another console stop and start the SBR process.  You should see trap information for oid 100 and 101.  If you do not see this information something is wrong.  Go back to the steps above and check everything again.  If you do see 100 and 101 you have gotten to the point where SBR and it’s subagent are talking to the SNMPAGENT on the local machine.  Next try to test your MIB browser to see if you can walk the SBR oid’s or see if your TRAP host is getting the TRAP oids from SBR when you restarted it.  The debug console should display some useful information while running your tests.

    Below are a few common messages that could be seen in the running console window.

    The message "SnmpGet: oid not in cache or expired" indicates that it has been a while since the last successful GET for this OID.  Reading between the lines, the GET has never succeeded for this customer, most likely.

    The message "Transport(): szHost = localhost, nPort = 1812" indicates that the subagent is trying to contact the SBR server on the localhost at TCP port 1812.  This is the typical case.

    The message "radSnmpTransport::GetData, response is empty" indicates that the SBR server is not replying to the subagent's request for data (to satisfy the outstanding GET for this OID).

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search