You can configure Network Insight to discover network devices that are configured or deployed within VRF (Virtual Routing and Forwarding) virtual networks. Using Network Insight to discover virtual networks provides visibility into your entire virtual network infrastructure, which allows you to view and manage overlapping IP addresses, VRF-specific data, and discovered end hosts. Note that a virtual network can consist of one or more physical devices that are configured to route packets using separate and distinct routing processes. Multiple routing tables can coexist on the same physical device or virtual device context, and traffic is exchanged among those devices using multiple routing tables.
Depending on your network topology, there are a few ways you can use Network Insight for VRF network management. To use Network Insight effectively in the network, review the different deployment scenarios and configure Network Insight accordingly, as described in VRF Deployment Guidelines.
In addition, before you start a discovery for VRF virtual networks, ensure that you have reviewed the guidelines listed in Special Considerations for Managing VRF Virtual Networks.

Special Considerations for Managing VRF Virtual Networks

When you define discovery settings and perform management of VRF virtual networks, consider the following:

If you limit the context of the SNMP community string in an individual VRF to the context of only that VRF, Network Insight 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 may result in extra, un-correlated devices in the network. For information about how to configure SNMP credentials, see Configuring SNMP1/v2 Credentials for Polling and Configuring SNMPv3 Properties.
Network Insight 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 discovery interface, Network Insight cannot discover all the devices or manage them. To create the necessary connectivity, you must configure a Network Insight discovery interface to be part of the VRF.
Network Insight collects and parses 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 that is mapped on a discovery interface. For more information about how to map network views to discovery interfaces, see Mapping Discovery Interfaces to Network Views.
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: "@credential". (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 Network Insight to discover networks that employ route-leaking, discovery ranges for each network view should only be defined to include IP addresses that belong 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. For information about how to define discovery ranges, see Discovering Devices and Networks.

VRF Deployment Guidelines

The topology of your network helps determine how you deploy Network Insight for VRF network management. To use Network Insight effectively in the network, you must possess some knowledge about your network so you can decide how to configure Network Insight to reach all the virtual networks you want to discover and manage. This section describes some common VRF-related network types for which you can deploy Network Insight.
Using the following three network types, all examples in this section help you define the number of network views and discovery interfaces so you can reach all locations in your network.

VRF Network Type 1: A network with a management VRF and several isolated production VRFs that include VRF-aware devices in the network.
VRF Network Type 2: A network with a shared service deployment VRF (shared VRF) and several isolated production VRFs that include VRF-aware devices in the network. The production VRFs share routes with the shared VRF, a practice also called route-leaking.
VRF Network Type 3: A network with several VRF-ignorant devices that reside in different L3 spaces, with no management VRF.

VRF Network Type 1 has the following characteristics:

A management VRF that reaches all VRF instances throughout the network.
Isolated production VRFs (all VRFs can route to/from the management VRF but not to one another).
The management VRF has complete visibility to all VRF instances in the network.

VRF Network Type 2 has the following characteristics:

Uses a shared services deployment VRF to offer network services to the other production VRFs (shared VRF).
All VRFs are reachable from the shared VRF, but VRFs cannot reach each other through the shared VRF or between each other.
The production VRFs (Red, Yellow, Green) share routes with the shared services VRF (Blue).
The shared VRF has complete visibility to all VRF instances.

VRF Network Type 3 has the following characteristics:

Devices have management IPs only inside their respective networks.
The routers in the network are VRF-aware; the switches are VRF-ignorant.

Defining Network Views and Discovery Interfaces

In all three deployment types, you decide whether you want one or multiple network views based on how your network operates, as outlined in the three network types above. You can also consider the following guidelines:

When all infrastructure devices for the network are reachable through a management VRF or a shared services VRF, and you do not need extended discovery capabilities to discover and/or manage end hosts, you can use a single network view. You also use a single virtual discovery interface to connect to the same 802.1q ID as the management VRF network. You can then discover and analyze all VRF-aware devices on the management VRF.
If you want your devices end host and downstream device information separated for viewing and reporting, then you will want to use network views for each virtual network. Doing so is helpful for visual purposes, but it is not required.
If you want ping sweeps, port scanning, fingerprinting and other discovery services into end hosts within each of your VRF networks, you must define multiple network views, one for each of your VRF networks; and each of which requires an associated virtual discovery interface and discovery ranges.

Deploying Network Insight in VRF Network Type 1: All Devices on a Management Network

The following figure shows an example of integrating Network Insight with Network Type 1. In this network deployment type, a single virtual discovery interface can manage all VRF instances' identification of ARP entries, because Network Insight needs only one discovery interface into the Management VRF.

Network Insight
You configure the following for this example:

Network View: Create one network view for the management VRF.
Discovery Interface: Add the active discovery interface to the management VRF and tag it with the corresponding 802.1q VLAN value.
Discovery Ranges: Define IP discovery ranges for the management network.
All discovered VRFs must be associated with the network view configured for the management VRF.

Deploying Network Insight in VRF Network Type 1: All Devices on a Management Network (Part 2)

The following figure shows the same topology for Network Type 1, but using multiple discovery interfaces and multiple network views.
In this example, the switch must be configured with the trunk port 'facing' Network Insight to forward Network Insight's tagged 802.1q traffic to the appropriate destination networks (VLAN 5, VLAN 10, VLAN 20 and VLAN 30 in this example).
The encapsulated sub-interfaces are defined using the correct values on each port; the virtual discovery interfaces on Network Insight match these values.

Network Insight
You configure the following for this example:

Network Views: Create a network view for each network (Management, Red, Yellow, Green).
Discovery Interfaces: Create virtual discovery interfaces for each VRF network.
Discovery Ranges: Define IP discovery ranges for each VRF network.
The discovered VRF instances must be associated with the network views to which they belong. For more information, see Viewing Discovered VRFs and Mapping Network Views.

Deploying Network Insight in VRF Network Type 2: All VRFs Reachable from a Shared Services VRF

This example illustrates the use of a shared service VRF between the distribution routers in the network and how Network Insight integrates into such a topology.
All virtual networks are reachable through a shared VRF, to which Network Insight may connect using a single virtual discovery interface and reach all other VRFs from the one to which it is connected. Each Router in this topology also shares routes between the VRFs.

You configure the following for this example:

Network View: Use one network view for the shared VRF.
Discovery Interface: Create a virtual discovery interface on the network view. Use a single virtual discovery interface in Network Insight, and connect through the facing switch to the shared VRF using the tagged 802.1q value. There is a 1:1 ratio between network views and discovery interfaces.
Discovery Ranges: Define IP discovery ranges in the single network view for all VRFs.
All discovered VRFs must be associated with this network view.

If you want your device end hosts and downstream devices information separated, then use network views for each virtual network. This is helpful for viewing and reporting but it is not required. In this example, only a single network view is applied.

Deploying Network Insight in VRF Network Type 2: All VRFs Reachable from a Shared Services VRF (Part 2)

In this version of the VRF Network Type 2 deployment, you use multiple network views and multiple discovery interfaces in a 1:1 ratio, with the same requirements for trunking and switch VLAN sub interfaces.

You configure the following for this example:

Network Views: Create a network view for each network (e.g., Management, Red, Yellow, Green).
Discovery Interfaces: Create virtual discovery interfaces for each VRF network.
Discovery Ranges: Define IP discovery ranges in Network Insight for each VRF network.
The discovered VRF instances must be associated with the network views to which they belong. For more information, see Viewing Discovered VRFs and Mapping Network Views.

Deploying Network Insight in VRF Network Type 3: Devices Reside in Disconnected Networks

In the final example, trunking is in use between Network Insight and its facing gateway switch into the managed network. This topology requires the use of multiple network views as all VRF networks are completely separate and cannot be reached through any management virtual network.

You configure the following for this example:

Network Views: Create a network view for each network (e.g., Management, Red, Yellow, Green).
Discovery Interfaces: Create virtual discovery interfaces for each VRF network.
Discovery Ranges: Define IP discovery ranges for each VRF network.
The discovered VRF instances must be associated with the network views to which they belong. For more information, see Viewing Discovered VRFs and Mapping Network Views.

Each of the network views requires a single virtual discovery interface using 802.1q tagging as indicated in the figure. When defining the virtual discovery interfaces, use the 802.1q tag from the network devices. The primary differences are as follows:

All devices do not have a management IP address in the so-called management VRF.
The routers are VRF-aware while the switches are not.
No VRF shares routes between any of the VRFs.

Browser not supported