This article describes how you can control the scope of polled data by specifying the name of logical-system and/or routing-instance in the community string. It is applicable for SNMP v1 or SNMP v2c.
Note: Logical-systems are supported only on High-End SRX Series. The rest is applicable both for High-End SRX and for Branch SRX Series.
When monitoring an SRX device with several routing-instances and/or logical-systems configured, one may want to retrieve the data related to a specific routing-instance and/or logical-system. Some examples could be:
- Retrieving a routing table of a particular virtual-router
- Retrieving status of interfaces that belong to a particulal virtual-router
- Retrieving security policies of a particular logical-system
In other cases, one may want to poll the entire device at once. For example, to retrieve status of all interfaces, regardless of which routing-instance they belong to.
You can control the scope by using different syntaxes of the community string. This article explains how.
Note: a poller is not necessarily allowed to poll the specified scope. Following rules apply:
- Only if the SNMP request enters the SRX device from the default routing-instance of the root logical-system, the poller can access any scope, according to what is specified in the community string.
- Otherwise, the poller can access only scopes inside his logical-system (it can still choose the routing-instance it is interested in).
The following syntax is defined for the community string:
lsys_name/vr_name@community
Here lsys_name stands for the name of the logical-system and vr_name stands for the name of the routing-instance.
Notes:
- if lsys_name is omitted, the root logical-system is assumed (e.g. vr1@public means routing-instance “vr1” in root logical-system);
- if lsys_name is not omitted, the vr_name is mandatory (e.g. lsys1/@public syntax is not allowed);
- a default routing-instance has a name “default” (e.g. lsys1/default@public or default@public).
The most staight forward syntax includes only the community itself (e.g. public), both lsys_name and vr_name are omitted. As we will see further, in most cases (but not always!) it is similar to the form default@public (which means default routing-instance in root logical-system).
As an example, following screenshot shows how we can specify the community “test123” and set the scope to the routing-instance “test” of the root logical-system:
Finally, we will demonstrate the results of polling 4 different objects with different scopes.
The configuration used in this example is as follows;
- One user-defined routing-instance (RI) under the root logical-system, called “wan-vr”
- One user-defined logical-system (LSYS), called “lab-lsys”.
- One user-defined RI under the LSYS “lab-lsys”, called “qa-vr”.
We will poll the following objects:
- sysLocation – system-wide object that represents the device location
- ifTable – returns the list of interfaces
- ipCidrRouteTable – returns the routing table
- jnxJsPolicyTable – returns the security policies
Assume that we configured community string is “public” and set system location to “Main Office”.
The following table summarizes the results (Note: the poller itself is attached to the default routing-instance of the root logical-system):
Notes:
- System-wide objects, like sysLocation, return the same value regardless of the community string syntax used;
- Routing-related objects, like ifTable and ipCidrRouteTable, return values that are relevant to the specified routing-instance;
- Security-related objects, like jnxJsPolicyTable, return values that are relevant to the specified logical-system.
Note: based on common deployment scenario, the ifTable object returns the full list of interfaces when polled with the simple community syntax (“public”). This addresses the common need to monitor all existing interfaces using one community string (by adding the SRX device to the monitoring solution only once).