Special Considerations for Managing VRF Virtual Networks

When you define discovery settings and perform management of virtual routing and forwarding networks, the following considerations exist that you should be aware of:

• If you limit the context of the SNMP community string in an individual VRF to the context of only that VRF, NetMRI will not be able to determine that the device it has discovered inside that VRF is the same device it has found inside other virtual networks. This will result in extra, un-correlated devices in the network.
• NetMRI will become aware of some devices inside of virtual networks from the route and ARP tables of routers that it manages. Without network connectivity into those virtual networks through a virtual scan interface, NetMRI cannot discover all the devices or manage them. To create the necessary connectivity, you need to configure a NetMRI scan interface to be part of the VRF.
• NetMRI will collect and parse the ARP and routing information from within a VRF context, but this data will not be used for further discovery unless the VRF virtual network is associated with a network view mapped on a scan interface.
• Global VRFs are labeled as default(IOS) for IOS, default for Nexus, and master for JunOS.
• For discovery and periodic polling on Juniper devices through an interface that is not in the Juniper default VRF (master), the query must use a special "default@credential" format. This setting assumes that users do not have management interfaces in a VRF. Your defined SNMP credentials for VRF-aware Juniper devices must use syntax similar to "@vrfsnmp." Enter these values for SNMP credentials under Settings icon > Setup > Credentials > SNMP v1/v2c tab. Note that when querying VRF-aware Juniper devices via an interface that is in the default VRF, a plain community string can be used without the "@" character.
• When configuring NetMRI to discover networks where route-leaking is employed (the practice of sharing routes between two or more networks, such as VRFs), discovery ranges for each network view should only be defined to include IPs known as belonging to that network view. In other words, any given Device IP should only fall within the discovery ranges of one network view. If discovery ranges are defined such that a Device can be discovered by two different network views, the device may also be discovered via an unexpected network view.