SRX Services Gateway
Highlighted
SRX Services Gateway

SNMP polling broken after implementing dual-WAN and routing instances

a month ago

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.

Attachments

6 REPLIES 6
Highlighted
SRX Services Gateway

Re: SNMP polling broken after implementing dual-WAN and routing instances

[ Edited ]
a month ago

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!

Highlighted
SRX Services Gateway

Re: SNMP polling broken after implementing dual-WAN and routing instances

a month ago

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.



Thanks,
π00bm@$t€®.
Please, Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!
Highlighted
SRX Services Gateway

Re: SNMP polling broken after implementing dual-WAN and routing instances

a month ago

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;

            }

        }

    }

}

Highlighted
SRX Services Gateway

Re: SNMP polling broken after implementing dual-WAN and routing instances

a month ago
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.


Thanks,
π00bm@$t€®.
Please, Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!
Highlighted
SRX Services Gateway
Solution
Accepted by topic author arenault
3 weeks ago

Re: SNMP polling broken after implementing dual-WAN and routing instances

a month ago

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



Thanks,
π00bm@$t€®.
Please, Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!
Highlighted
SRX Services Gateway

Re: SNMP polling broken after implementing dual-WAN and routing instances

3 weeks ago

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.

Feedback