Polling SNMP over a Routing Instance is quite straightforward once you understand the syntax necessary to specify that you want to poll the routing-instance. But when I tried this the first time, I didn’t have a clue why it didn’t work!

For a bit of background, we had a request from another team who’s network we manage, asking if they could SNMP details so they could poll an edge pair of SRX240’s. We use a routing instance to keep the management traffic separate from production traffic, so configured a SMNPv2 community and asked them to test it, but and they said it wasn’t working… BALLS :S

I set this up in the lab for testing; I used a Juniper SRX220 with Routing-Instance that had a Ubuntu 14.04LTS host directly connected to poll SNMP

I had configured SNMPv2 and enabled it to allow the relevant routing-instance to have access under the community stanza and enabled routing instance access under the overall stanza as well, thinking that this would be enough:

[edit]
marquk01@v6-testing# show snmp 
community test {
    authorization read-only;
    routing-instance test {
        clients {
            192.168.1.0/24;
        }
    }
}
routing-instance-access;

However, when I did a snmpwalk….. I got nothing :/

marquk01@km-vm1:~$ snmpwalk -v2c -ctest 192.168.1.1
^C

Not Good :(

I messed about with the configuration and asked a few colleagues and a senior, but none of them could see the issue. So, as you do when you don’t have a clue…. Time to Google! From my searches managed to find Juniper KB page that explained the different variations of syntax when polling SNMPv1/v2c with Routing Instances

There are 3 variations:

  • community string - which works if the user polls directly from inet.0
  • routing-instance@community string - which polls information for specific routing instance
  • default@community string - which allows polling information about inet.0 only

In essence when I was tried to SNMP poll the SRX with the syntax snmpwalk -v2c -ctest 192.168.1.1, it wasn’t referencing the routing instance because snmpwalk was trying to poll the master instance, which routing-instance had no access to.

For the syntax, I should have been using was snmpwalk -v2c -ctest@test 192.168.1.1. By referencing the routing instance I was able to SNMP poll the SRX and all the interfaces that were within the routing-instance:

marquk01@km-vm1:~$ snmpwalk -v2c -ctest@test 192.168.1.1
\\iso.3.6.1.2.1.1.1.0 = STRING: "Juniper Networks, Inc. srx220h2 internet router, kernel JUNOS 12.1X47-D30.4 #0: 2015-11-13 14:16:02 UTC     builder@greteth.juniper.net:/volume/build/junos/12.1/service/12.1X47-D30.4/obj-octeon/junos/bsd/kernels/JSRXNLE/kernel Build date: 2015-11-13 15:4"

SNMPv3 Polling⌗

For SNMPv3 when configuring your user, under snmp v3 access group stanza, the context-prefix HAS to be the same name as the Routing-Instance

marquk01@v6-testing# show snmp 
v3 {
    usm {
        local-engine {
            user keeran {
                authentication-sha {
                    authentication-key "$9$WS8LdbYgojk.aJDkqmF3Ap01cyevWXNdleZUDjq.hSyKLx-VwoaUbwgJGU.m1RESrvXxdsYohSvLxNY2z3n/p0REylvW1IxN-VY2JGDk5Q/Ct01RUjqfzFAt8XxdYgDikf5FGU69CA0OLx7NdsUjHTFniHmTznCA8Xx7s2aJDmPQjiCt0ORE-VbsYo"; ## SECRET-DATA
                }
                privacy-des {
                    privacy-key "$9$qmz3/CtIhSpu1hcyW8-Vw2JGjHqPTzDj0B1IcSaZGimfQFntpB3nCuOBSy24oZUHPfz6/taZHmfT/9M8LxVw4oGDHq2gfTQF/9uO1hevxNdw24BIclMW-d.Pfz/C1RhleWOBX7N-wsmf5Tz6BIEKWLREyKMLN-.Pf569pu1yrvIRNdws4oQF36/t"; ## SECRET-DATA
                }
            }
        }
    }
    vacm {
        security-to-group {
            security-model usm {
                security-name keeran {
                    group view-all;
                }
            }
        }
        access {                        
            group view-all {
                **context-prefix test** {
                    security-model usm {
                        security-level privacy {
                            read-view view-all;
                            notify-view view-all;
                        }
                    }
                }
            }
        }
    }
}
view view-all {
    oid .1 include;
}
routing-instance-access;

Then when you run the snmpwalk you’ll need to add the flag -n to specify the context name, which will be the routing-instance. If you’ve used the same authentication and privacy types as me, your syntax should look something like this: snmpwalk -v 3 -u keeran -l authPriv -a SHA -A test1234 -x DES -X test1234 -n test 192.168.1.1

snmpwalk -v 3 -u keeran -l authPriv -a SHA -A test1234 -x DES -X test1234 -n test 192.168.1.1
iso.3.6.1.2.1.1.1.0 = STRING: "Juniper Networks, Inc. srx220h2 internet router, kernel JUNOS 12.1X47-D30.4 #0: 2015-11-13 14:16:02 UTC     builder@greteth.juniper.net:/volume/build/junos/12.1/service/12.1X47-D30.4/obj-octeon/junos/bsd/kernels/JSRXNLE/kernel Build date: 2015-11-13 15:4"

This was pretty frustrating as there was no clear reason why it wasn’t working, and something that should have taken a few moments took days! So I’m hoping this will help you so that you don’t end up in a bit of a rage like I was lol

References⌗

Share on LinkedIn
Share on Reddit