SRX

Expand all | Collapse all

SNMP polling broken after implementing dual-WAN and routing instances

Jump to Best Answer
  • 1.  SNMP polling broken after implementing dual-WAN and routing instances

    Posted 07-16-2020 09:15

    I have implemented a dual-WAN with failover on my SRX, and am using routing instance to separate the default router for each WAN link.

    The goal is to failover from WAN 1 to WAN 2 when IP monitoring fails, and push the WAN 2 default route to default routing instance.

     

    Since I have implemented this routing instances however, I am no longer able to poll the SRX via SNMP from an offsite server.

     

    Attached are my config, and trace file.

    Attachment(s)

    txt
    SRX300.config.txt   18K 1 version
    txt
    debug.log.txt   3K 1 version


  • 2.  RE: SNMP polling broken after implementing dual-WAN and routing instances

    Posted 07-16-2020 09:48

    Hi arenault,

     

    Please check if you can enable trace options for SNMP. Please be mindful that these traces should not be kept running for long on the device.

     

    Example for SNMP:

    edit snmp traceoptions

    set file trace_snmp

    set flag all

     

    Try your SNMP walk again from a linux machine and then take a look at the log with show log trace_snmp

     

    If you don’t see anything showing up in the trace options there’s one of two things wrong.

    • Security settings are restricting SNMP polls from coming into the interface you’re coming in on. Verify which interface you’re polling and check that host-inbound-traffic is permitted. See the Configure SNMP section at the top of this blog post to understand that command.
    • The SNMP poll may not even be arriving at the SRX. It’s possible the SNMP poll is being blocked somewhere or doesn’t know how to make it to the SRX. Verify routing is working correctly and that port 161 isn’t blocked.

    Below is an example of successful SNMP polling:

    Aug 25 20:49:29 snmpd[5f07] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Aug 25 20:49:29 snmpd[5f07] >>> Get-Request
    Aug 25 20:49:29 snmpd[5f07] >>> Source: 10.1.60.200
    Aug 25 20:49:29 snmpd[5f07] >>> Destination: 192.168.55.55
    Aug 25 20:49:29 snmpd[5f07] >>> Version: SNMPv2
    Aug 25 20:49:29 snmpd[5f07] >>> Request_id: 0x5f07
    Aug 25 20:49:29 snmpd[5f07] >>> Community: myCommunityString
    Aug 25 20:49:29 snmpd[5f07] >>> Error: status=0 / vb_index=0
    Aug 25 20:49:29 snmpd[5f07] >>> OID : ifOperStatus.578
    Aug 25 20:49:29 snmpd[5f07] >>> OID : ifName.578
    Aug 25 20:49:29 snmpd[5f07] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Aug 25 20:49:29 jnx_ifEntry_stat_actual_lookup: sync request for ae0.50
    Aug 25 20:49:29 jnx_ifEntry_stat_actual_lookup: sync request for ae0.50
    Aug 25 20:49:29 snmpd[5f07] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    Aug 25 20:49:29 snmpd[5f07] <<< Get-Response
    Aug 25 20:49:29 snmpd[5f07] <<< Source: 10.1.60.200
    Aug 25 20:49:29 snmpd[5f07] <<< Destination: 192.168.55.55
    Aug 25 20:49:29 snmpd[5f07] <<< Version: SNMPv2
    Aug 25 20:49:29 snmpd[5f07] <<< Request_id: 0x5f07
    Aug 25 20:49:29 snmpd[5f07] <<< Community: myCommunityString
    Aug 25 20:49:29 snmpd[5f07] <<< Error: status=0 / vb_index=0
    Aug 25 20:49:29 snmpd[5f07] <<<
    Aug 25 20:49:29 snmpd[5f07] <<< OID : ifOperStatus.578
    Aug 25 20:49:29 snmpd[5f07] <<< type : Number
    Aug 25 20:49:29 snmpd[5f07] <<< value: 1
    Aug 25 20:49:29 snmpd[5f07] <<<
    Aug 25 20:49:29 snmpd[5f07] <<< OID : ifName.578
    Aug 25 20:49:29 snmpd[5f07] <<< type : OctetString
    Aug 25 20:49:29 snmpd[5f07] <<< value: "ae0.50"
    Aug 25 20:49:29 snmpd[5f07] <<< HEX : 61 65 30 2e 35 30
    Aug 25 20:49:29 snmpd[5f07] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

     

    When there are >>> symbols it means that was an incoming SNMP request. When there are <<< it means that’s a SNMP response.

     

    Also, please check the KB, it may help you with your resolution:

    https://kb.juniper.net/InfoCenter/index?page=content&id=KB27191

     

    Hope this helps :cathappy:

     

    Please mark "Accepted Solution" in case this solves your query. Kudos are always appreciated!



  • 3.  RE: SNMP polling broken after implementing dual-WAN and routing instances

    Posted 07-16-2020 12:49

    Hi Arenault,

     

    I checked the configuration file attached and there is not SNMP hierarchy configured at all. I think that's the reason you were unable to poll the SRX.

     

    Please check the following KB article and configure SRX as SNMPv2 agent - https://kb.juniper.net/InfoCenter/index?page=content&id=KB16545&actp=METADATA

     

    Let me know if you are still unable to poll.



  • 4.  RE: SNMP polling broken after implementing dual-WAN and routing instances

    Posted 07-16-2020 13:13

    No, no, there is an SNMP hierarchy, I just edited it out (...) for privacy.

    Remember that I was able to successfully use SNMP to keep track of interface traffic and host metrics before.

     

    It seems that JunOS doesn't allow direct polling through an interface in a custom routing instance:

    https://kb.juniper.net/InfoCenter/index?page=content&id=KB30459&cat=SRX_240&actp=LIST

     

    So at this point, I'm trying to work around that limitation, and DNAT from ingress untrust -> trust -> loopback.

    The traffic does go around the device, but ultimately when the SNMP traffic lands on loopback, the SRX doesn't accept the traffic.

     

    Jul 16 15:49:03 15:49:03.019255:CID-1:RT:Loopback first path alloc pending session, natp=0x7fd9bf0, id=15522

    Jul 16 15:49:03 15:49:03.019255:CID-1:RT:  flow_first_in_dst_nat: in <lo0.0>, out <lo0.0> dst_adr 127.0.0.1, sp 59127, dp 161

    Jul 16 15:49:03 15:49:03.019255:CID-1:RT:  chose interface lo0.0 as incoming nat if.

    Jul 16 15:49:03 15:49:03.019255:CID-1:RT:  packet dropped: for self but not interested

    Jul 16 15:49:03 15:49:03.019255:CID-1:RT:  packet dropped, packet dropped: for self but not interested.

    Jul 16 15:49:03 15:49:03.019255:CID-1:RT:flow_first_install_session: Loopback session processing aborted

     

    The 'self' zone in which the loopback interface is located does have SNMP allowed:

     

    # show security zones security-zone self                                                              

    interfaces {

        lo0.0 {

            host-inbound-traffic {

                system-services {

                    snmp;

                }

            }

        }

    }



  • 5.  RE: SNMP polling broken after implementing dual-WAN and routing instances

    Posted 07-16-2020 13:54
    Hi Arenault,

    Thanks for the clarification.

    I checked the KB article and it is not applicable for you because you had lo0 interface in custom routing-instance and not in default routing-instance as per your configuration. So, ideally I guess destination NAT is not required.

    Can you try to replace 127.0.0.1 in lo0 to anyother class of IP address? I just want to check the behaviour.

    If will check more information regarding this and will get back to you.


  • 6.  RE: SNMP polling broken after implementing dual-WAN and routing instances
    Best Answer

    Posted 07-16-2020 21:50

    Hi Arenault,

     

    If both the external interface and loopback interface are in the same routing-instance, then SNMP polling should work. For this scenario, destination NAT is not required.

     

    If you are doing polling via routing-instance, then you need to specify the routing-instance name in the SNMP configuration and also, the "routing-instance-access" statement. While you polling from the SNMP server, you should specify the routing-instance name over there as well. For more information, please check the following KB article - https://kb.juniper.net/InfoCenter/index?page=content&id=KB13080&actp=METADATA



  • 7.  RE: SNMP polling broken after implementing dual-WAN and routing instances

    Posted 07-21-2020 09:19

    Thanks for the help with this Noobmaster, I worked the issue out with JTAC.

     

    There were a blend of configuration issues: 

    My original configuration made use of an alternate SNMP port (UDP 1610) which was DNAT'ed to the loopback interface.

    We removed that, and polled the external interface on UDP 161 directly.

    There was a untrust-to-untrust security policy to add in order to allow that traffic to reach the SRX.

    And finally, because the external interface is in a custom routing instance, the SNMPwalk needed to be done by the client with specifying the routing instance name in the community string in the form of Routing-Instance@COMMUNITY_STRING.

     

    Thanks so much of the help and support, and if anyone runs into similar issue, reply to this post for configuration details.