With this feature, routing instances are identified by either the context field in V3 requests or encoded in the community string in V1 or V2c requests.
When encoded in a community string, the routing instance name appears first and is separated from the actual community string by the @ character.
To avoid conflicts with valid community strings that contain the @ character, the community is parsed only if typical community string processing fails. For example, if a routing instance named RI is configured, an SNMP request with RI@public is processed within the context of the RI routing instance. Access control (views, source address restrictions, access privileges, and so on) is applied according to the actual community string (the set of data after the @ character—in this case public). However, if the community string RI@public is configured, the PDU is processed according to that community and the embedded routing instance name is ignored.
Logical routers perform a subset of the actions of a physical router and have their own unique routing tables, interfaces, policies, and routing instances. When a routing instance is defined within a logical router, the logical router name must be encoded along with the routing instance using a slash ( / ) to separate the two. For example, if the routing instance RI is configured within the logical router LR, that routing instance must be encoded within a community string as LR/RI@public. When a routing instance is configured outside a logical router (within the default logical router), no logical router name (or / character) is needed.
Also, when a logical router is created, a default routing instance (named default) is always created within the logical router. That name should be used when querying data for that routing instance (for example, LR/default@public). For V3 requests, the logical router/routing instance name should be identified directly in the context field.