Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

No index entries found.

Related Documentation

    Configuring the SNMP Traps and Events to Record (Advanced)

    The Event Browser comes preconfigured with a number of events which in most cases should be sufficient. If needed, however, a graphical interface is provided to create, modify, and delete the traps that will be processed by the SNMP Trap server. The alternative is to modify the event server configuration files themselves. The latter option should be used only if you have a thorough understanding of the Event Browser and Event Serve, otherwise, unexpected errors may occur when modifying the configuration files.


    Overview


    Following is a list of the major configuration files and their functions. These files are found under /u/wandl/db/config/.

    • snmptrap.store: This file can be used to filter which events will get processed by the SNMP Trap server. Processed traps will be output to the /u/wandl/data/trap/snmptrap.yymmdd file where yy is the year, mm is the month, and dd is the day.
    • eventtypes.store: This file can be used to filter which events will get processed by the event server and displayed by the Event Browser. All event types are defined in this file. For each event type, several fields can be configured that correspond to specific fields in the Event Browser table, that is, id maps to Type, defaultElementType maps to ElementType, and defaultSeverity maps to Severity.
    • eventserver.xml: Internal references and settings for the event server are stored here. These settings are either configured automatically or during installation, and generally should not be modified unless absolutely required. It is possible to modify the email server settings and the maximum number of days to store events. Modifying other settings incorrectly may break the event server.
    • subscriptions.store: Event subscriptions and subscribers are defined here. These are used by the event server to parse events and push them to the appropriate JMS queues and topics, which is used by the event browser to display incoming events. These should not be modified unless instructed to do so by Juniper support.

    Graphical Interface


    1. To modify the trap configuration files, select Tools > MIB Browser and select MIB > Enable SNMP Config Editing. To filter for just the trap-related MIB objectts, select MIB > Filter for Traps.
    2. Next, browse for the particular trap of interest, which can be searched using the MIB > Find... function. Note that when SNMP Config Editing is enabled, the trap icon will include a green circle if it is processed by IP/MPLSView. Otherwise, if there is no current association, the trap icon will include a red circle.

      Figure 196: Modifying SNMP Trap Configuration

      Modifying SNMP Trap Configuration
    3. To enable processing of a new trap, select a trap from the MIB Browser whose icon contains a red circle in it. Right-click over it and select Create SNMP Trap Configuration
    4. To modify or delete an existing trap, select a trap from the MIB Browser whose icon contains a green circle in it. Right-click over it and select Modify SNMP Trap Configuration or Remove SNMP Trap Configuration.
    5. When creating or modifying a trap, the following window will be displayed. In the Trap Configuration tab, the trap name, OID, associated element type (Node, Interface, Tunnel, VPN, or VLAN), and Severity can be indicated, along with a comment and whether or not to enable processing of the trap by the SNMP trap server.

      Figure 197: Editing SNMP Trap Configuration

      Editing SNMP Trap Configuration
    6. Select the Trap Attributes tab.

      Figure 198: Edit Trap Attributes

      Edit Trap Attributes

      The Trap Attributes tab contains a list of the various MIB Attribute OIDs associated with this trap and the corresponding MIB Attribute Name. The OIDs used as the key to identify the trap with its associated network element are indicated in the Element Key Priority column with nonzero values starting with 1.

      The Event Attribute column is used to map the value from the trap to the appropriate column of the Event Browser. In the case of the linkDown trap, the keyword “name” in the Event Attribute column refers to the interface name, since the element type configured on the Trap Confiugration tab is the Interface.

      Click Reset Trap OIDs to automatically fix incorrect OIDs entered previously


    Advanced Configuration Tab


    1. Select the Advanced Configuration tab.

      Figure 199: Advanced Configuration

      Advanced Configuration
    2. The Advanced Configuration tab can be used if the OID subidentifier needs to be used as the key to associate the trap with the appropriate network element.
    3. To do this, select the “Use OID index as element key” checkbox. Next, use the “OID index key template” field to map from the subidentifier to the associated element. For example, if the element type defined on the Trap Configuration tab is Tunnel, and the OID index key template is “Tunnel[key]”, this would map the trap to the appropriate tunnel prefixed with the word “Tunnel” and ending with the subidentifier.
    4. Trap exclude condition: The Advanced Configuration tab can also be used to filter out traps meeting particular critiera. For example, you could type in “translatedIP == “1.2.3.4” to exclude traps from 1.2.3.4. To specify more than one IP, you can use “||” to indicate a logical-or, for example, “sourceIP == “10.10.0.1” || sourceIP == “10.20.0.1”.
    5. Event exclude condition: Processed traps will be displayed in the Event Browser unless they are excluded using the Event exclude condition. For example, you could type in sourceIP == 10.20.0.1 to exclude the display of events from 10.20.0.1.
    6. Finally, the table at the bottom of the Advanced Configuration tab is used to map attributes of the element with attributes in the Event Browser. For example, if the element’s “comment” field is mapped to the Event Browser’s comment, then this comment will be displayed in the Event Browser.

    Example Trap Config Editor Settings for BGP Traps


    After loading the MIB module:

    /u/wandl/thirdparty/MIBs/STANDARD/draft-ietf-idr-bgp4-mib-07.mi2, you can modify the trap settings for bgpBackwardTransition and bgpEstablished as follows:

    Figure 200: Advanced Tab

    Advanced Tab

    Note that setting it as element type: Protocol will allow it to be displayed under the Protocol category in the IP/MPLSView Web Interface, New Event Summary Report.

    Figure 201: Trap Attributes Tab

    Trap Attributes Tab

    Make the changes above to enable the shortcut to the BGP neighbor window from the Event Browser right-click menu.


    Adding New SNMP Traps


    Note: The traps feature requires a license. Please contact your Juniper representative for more information.

    IP/MPLSView can collect any trap. However, unless the IP/MPLSView trap daemon is configured to collect a particular trap, it will be ignored. The IP/MPLSView system contains a default list of SNMP traps that are processed. To add additional ones, you need to configure the following the snmptrap.store and eventtypes.store configuration files located in /u/wandl/db/config:

    The snmptrap.store file defines all events that the event server should be aware of, including SNMP traps. When creating a new SNMP trap type, to minimize the chance of typo errors, copy and paste an existing SNMP trap event type and then modify the duplicate event type to create the new event type. Below is an example of a SNMP trap event type defined in the eventtypes.store file.

    <SNMPTrapConfig elementType="Tunnel" id="1.3.6.1.3.95.3.0.2"
    implClass="com.wandl.event.snmp.SNMPTrapConfig" name="mplsTunnelDown">
    com.wandl.event.snmp.SNMPTrapConfig$MIBDefinition
    com.wandl.event.snmp.SNMPTrapConfig$MIBDefinition
    com.wandl.event.snmp.SNMPTrapConfig$MIBDefinition
    mibOID="1.3.6.1.2.1.1.3.0"/>
    <MIBDefinition implClass="com.wandl.event.snmp.SNMPTrapConfig$MIBDefinition" keyPriority="1"
    mibName="mplsTunnelIndex" mibOID="1.3.6.1.3.95.2.2.1.1"/>
    <MIBDefinition implClass="com.wandl.event.snmp.SNMPTrapConfig$MIBDefinition"
    mibName="mplsTunnelInstance" mibOID="1.3.6.1.3.95.2.2.1.2"/>
    <MIBDefinition implClass="com.wandl.event.snmp.SNMPTrapConfig$MIBDefinition"
    mibName="mplsTunnelIngressLSRId" mibOID="1.3.6.1.3.95.2.2.1.3"/>
    <MIBDefinition implClass="com.wandl.event.snmp.SNMPTrapConfig$MIBDefinition"
    mibName="mplsTunnelEgressLSRId" mibOID="1.3.6.1.3.95.2.2.1.4"/>
    <MIBDefinition implClass="com.wandl.event.snmp.SNMPTrapConfig$MIBDefinition"
    mibName="mplsTunnelAdminStatus" mibOID="1.3.6.1.3.95.2.2.1.34"/>
    <MIBDefinition implClass="com.wandl.event.snmp.SNMPTrapConfig$MIBDefinition"
    mibName="mplsTunnelOperStatus" mibOID="1.3.6.1.3.95.2.2.1.35"/>
    <KeyTemplate implClass="com.wandl.util.TextTemplate">
    <Template>Tunnel[key]</Template>
    <Pattern>\[([A-z0-9]+)\]</Pattern>
    </KeyTemplate>
    </SNMPTrapConfig>

    To collect SNMP trap events, the SNMP trap listener must be started on the server if it is not already running. Use the following commands to start and stop the SNMP trap listener:

    /u/wandl/bin/.snmptrap start
    /u/wandl/bin/.snmptrap stop

    Adding New Events


    To add a new event via the configuration file, modify the eventtypes.store file. When creating a new event type, to minimize the chance of typo errors, copy and paste an existing event type and then modify the duplicate event type to create the new event type. Below is an example of an event type defined in the eventtypes.store file.

    <EventType defaultElementType="Tunnel" defaultSeverity="MAJOR" id="mplsTunnelDown"
    implClass="com.wandl.event.data.BasicEventType" name="mplsTunnelDown" superType="TunnelEvent"/>

    To create a new event based on the above XML snippet, replace id and name with the new event name, replace defaultSeverity with the severity of the new event, and replace defaultElementType with the type of element being monitored by the new event. The implClass should remain the same, and the superType field is optional and can be removed if not used.

    Once a new event type is added to eventtypes.store, the event server will automatically detect the newly added event type. In case the new event types are not automatically detected, the event server can be stopped and restarted with the following commands:

    /u/wandl/bin/.eventserver stop
    /u/wandl/bin/.eventserver start /u/wandl/db/config/eventserver

    Modified: 2015-12-29