IntraVUE™ Tech Note

Configuring IntraVUE for Cisco VLANs

Overview

This document presents the simpler solution to configuring IntraVUE when a network consists of Cisco switches having VLANs and where the switches are in a different VLAN than the end devices. It may not work in all cases but it is the best starting point.

Many IT groups will install Cisco infrastructure (layer 2 switches, routers, layer 3 switches) in multiple VLANS. IT has a good reason for this but that will be outside the scope of this document. In order for IntraVUE to automatically map (build wiring diagrams) any network, it must talk to the infrastructure via SNMP.

Cisco switches do not comply with RFC 1493, the Bridge MIB, for devices in a VLAN. The RFC requires a switch to report all MACs known to the switch, but Cisco only responds based on the community string used in the query. Cisco is unique in this area in that the SNMP Community string must contain the VLAN ID. A community of ‘public’ is the equivalent of ‘public@1’, VLAN 1 being the default VLAN, sometimes called the management VLAN. If devices are in VLAN 400 and ‘public’ is the SNMP community, a query using ‘public’ will only return information about devices in VLAN 1 and a query using ‘public@400’ will only return information about devices in VLAN 400.

VLANs may be implemented in many ways. Some examples are:

All switches and devices to be monitored in one VLAN
All switches in one VLAN and all devices in a different VLAN
Multiple VLANs each VLAN having switches and devices.
Multiple VLANs some with switches and some with devices.

Case 1

Case 1 above is handled following these steps:

In the Admin Tool add the network but only have the single IP address of the top parent in the scan range. Close the Admin Tool.
Open the browser and change the System Configuration default SNMP community so it contains the base community and append the ‘@’ symbol and the VLAN number.
Open the Admin Tool to enter the IP address ranges of the rest of the devices and switches.
After all switches have been discovered, edit or create the file community.conf in IntraVUE’s root folder (c:\program files\IntraVUE). Add a single line $1=”public” and save the file.

Case 2

Case 2 is more complicated and it will help you to understand the steps by establishing an example network environment.

10.8.1.12 IntraVUE host computer

255.255.255.0 – subnet mask
10.8.1.1 – default gateway

10.8.181.X subnet of switches in VLAN 181

10.8.251.X subnet of control devices in VLAN 251

10.8.1.X subnet of office devices (VLAN 1)

10.8.1.1 the default gateway, has additional interfaces of:

10.8.181.1
10.8.251.1

Communities:

     public – default community of end devices
     xyz – base community of switches and routers
     xyz@181 - Cisco community index for VLAN 181
     xyz@251 - Cisco community index for VLAN 251

When IntraVUE makes SNMP requests for the port of a MAC address of a device, Cisco switches will only respond with information of devices in the VLAN determined by the community string. Cisco calls this community string indexing.

Querying a switch, 10.8.181.5, using ‘xyz’ or xyz@1 will give information about any devices in VLAN 1. In this case, there are no devices connected to 10.8.181.X switches that are in the office network or VLAN 1.

Querying the same switch with xyz@181 will give information about all the devices in VLAN 181, in this case the other switches, but no information about any other devices. Using xyz@251, the switches will provide port information for the end devices but not for the switches.

Currently, IntraVUE can query switches using one community string, the one set in the device’s configuration dialog. Typically this is set to ‘$0’, meaning use the system default. We must control the order and the communities by which IntraVUE learns the devices in the network.

The key principle is to never let IntraVUE make an snmp query to the switch using the VLAN 1 (default) community, e.g. xyz, and to not let IntraVUE use the device community before learning and using the switch community.

An overview of the process we will follow is:

Create an IntraVUE network with only the top parent
Change the system default community to use the VLAN of the switches
Edit the IntraVUE network and add only the switches
Wait until the hierarchy of switches is correct
Edit each discovered switch’s configuration to explicitly use the community of the device VLAN
Edit the system default community to use the VLAN of the devices and edit the community.conf file
Edit the IntraVUE network and add the devices

Following are the detailed steps using the data from the example above.

1. Create an IntraVUE network with only the top parent

Open the Admin Tool and enter just the top parent. If the top parent is a router, the SNMP community MUST be correct.

Top parent 10.8.1.12

Range 10.8.1.12 – 10.8.1.12

Close the admin tool.

1a. Discover router(s) if all devices are not local.

Only follow this step if there is a router involved.

If some of the switches or devices must be accessed through a router there is a middle step. The router must be discovered with its read only community. Routers do no have VLANs but if a router is involved we must be able to get the MAC addresses from it.

Open the browser, login as Admin, change the system default community in the System Config dialog to that of the router, ‘xyz’ in this example, it could be ‘public’ or anything else.

Open the Admin tool and edit the network to add the IP address of the router.

10.8.1.12 – 10.8.1.12
10.8.1.1 – 10.8.1.1

Close Admin Tool.

Open browser and wait until router is discovered. It should have a green outline and when you hover over the router you should see a list of additional interfaces. In the list should be 10.8.181.1 and 10.8.251.1, the local IPs for the switches and control devices.

Go to the router configuration dialog and explicitly set the community to ‘xyz’.

2. Change the system default community to use the VLAN of the switches

Open the browser. Login as admin, change the community in the System Config dialog to xyz@181.

3. Edit the IntraVUE network and add only the switches

Open Admin Tool. Edit the network. Add the switch scan range.

     10.8.1.12 – 10.8.1.12
     10.8.1.1 – 10.8.1.1
     10.8.181.0 – 10.8.181.255

Close the admin tool.

4. Wait until the hierarchy of switches is correct

Open the browser, login as admin, edit the configuration dialog of the router 10.8.1.1 and change the community to xyz.

Wait until the switches are moved from unresolved to under the 10.8.1.1 and the switch hierarchy is correct.

5. Edit each discovered switch’s configuration to explicitly use the community of the device VLAN

Go to the configuration dialog of each switch and explicitly set the community to xyz@251. The switches will now report the positions of the devices.

After this point the switches will not respond to any requests for the port positions of other switches, since they will only answer for devices in VLAN 251.

6. Edit the system default community to use the VLAN of the devices and edit the community.conf file

Go to the System Configuration dialog and change the default community to ‘public@251’ so the switches will use the community of the devices if they ever have to re-establish SNMP communication.

Now the explicit community for the switches and the system default community are both that of the device VLAN.

Create or edit the file c:\program files\IntraVUE\community.conf. The file should contain 1 line for each end device community in use. Typically this will be ‘public’ and there will only be one line in the file as follows:

$1=”public”

End devices will fail to respond to SNMP using the default ‘public@251’ but will succeed when ‘public’ is tried.

7. Edit the IntraVUE network and add the devices

Open the Admin tool and add the IP address range of the end devices.

     10.8.1.12 – 10.8.1.12
     10.8.1.1 – 10.8.1.1
     10.8.181.0 – 10.8.181.255
     10.8.251.0 – 10.8.251.255

Close the Admin tool.

Open the browser. You should see the end devices initially in unresolved. They then should move out of unresolved to the appropriate switches. On the lines connecting devices to switches and switches to switches you should see the switch port numbers.



	IntraVUE™ Tech Note Configuring IntraVUE for Cisco VLANs Overview This document presents the simpler solution to configuring IntraVUE when a network consists of Cisco switches having VLANs and where the switches are in a different VLAN than the end devices. It may not work in all cases but it is the best starting point. Many IT groups will install Cisco infrastructure (layer 2 switches, routers, layer 3 switches) in multiple VLANS. IT has a good reason for this but that will be outside the scope of this document. In order for IntraVUE to automatically map (build wiring diagrams) any network, it must talk to the infrastructure via SNMP. Cisco switches do not comply with RFC 1493, the Bridge MIB, for devices in a VLAN. The RFC requires a switch to report all MACs known to the switch, but Cisco only responds based on the community string used in the query. Cisco is unique in this area in that the SNMP Community string must contain the VLAN ID. A community of ‘public’ is the equivalent of ‘public@1’, VLAN 1 being the default VLAN, sometimes called the management VLAN. If devices are in VLAN 400 and ‘public’ is the SNMP community, a query using ‘public’ will only return information about devices in VLAN 1 and a query using ‘public@400’ will only return information about devices in VLAN 400. VLANs may be implemented in many ways. Some examples are: All switches and devices to be monitored in one VLAN All switches in one VLAN and all devices in a different VLAN Multiple VLANs each VLAN having switches and devices. Multiple VLANs some with switches and some with devices. Case 1 Case 1 above is handled following these steps: In the Admin Tool add the network but only have the single IP address of the top parent in the scan range. Close the Admin Tool. Open the browser and change the System Configuration default SNMP community so it contains the base community and append the ‘@’ symbol and the VLAN number. Open the Admin Tool to enter the IP address ranges of the rest of the devices and switches. After all switches have been discovered, edit or create the file community.conf in IntraVUE’s root folder (c:\program files\IntraVUE). Add a single line $1=”public” and save the file. Case 2 Case 2 is more complicated and it will help you to understand the steps by establishing an example network environment. Example: 10.8.1.12 IntraVUE host computer 255.255.255.0 – subnet mask 10.8.1.1 – default gateway 10.8.181.X subnet of switches in VLAN 181 10.8.251.X subnet of control devices in VLAN 251 10.8.1.X subnet of office devices (VLAN 1) 10.8.1.1 the default gateway, has additional interfaces of: 10.8.181.1 10.8.251.1 Communities: public – default community of end devices xyz – base community of switches and routers xyz@181 - Cisco community index for VLAN 181 xyz@251 - Cisco community index for VLAN 251 When IntraVUE makes SNMP requests for the port of a MAC address of a device, Cisco switches will only respond with information of devices in the VLAN determined by the community string. Cisco calls this community string indexing. Querying a switch, 10.8.181.5, using ‘xyz’ or xyz@1 will give information about any devices in VLAN 1. In this case, there are no devices connected to 10.8.181.X switches that are in the office network or VLAN 1. Querying the same switch with xyz@181 will give information about all the devices in VLAN 181, in this case the other switches, but no information about any other devices. Using xyz@251, the switches will provide port information for the end devices but not for the switches. Currently, IntraVUE can query switches using one community string, the one set in the device’s configuration dialog. Typically this is set to ‘$0’, meaning use the system default. We must control the order and the communities by which IntraVUE learns the devices in the network. The key principle is to never let IntraVUE make an snmp query to the switch using the VLAN 1 (default) community, e.g. xyz, and to not let IntraVUE use the device community before learning and using the switch community. An overview of the process we will follow is: Create an IntraVUE network with only the top parent Change the system default community to use the VLAN of the switches Edit the IntraVUE network and add only the switches Wait until the hierarchy of switches is correct Edit each discovered switch’s configuration to explicitly use the community of the device VLAN Edit the system default community to use the VLAN of the devices and edit the community.conf file Edit the IntraVUE network and add the devices Following are the detailed steps using the data from the example above. 1. Create an IntraVUE network with only the top parent Open the Admin Tool and enter just the top parent. If the top parent is a router, the SNMP community MUST be correct. Top parent 10.8.1.12 Range 10.8.1.12 – 10.8.1.12 Close the admin tool. 1a. Discover router(s) if all devices are not local. Only follow this step if there is a router involved. If some of the switches or devices must be accessed through a router there is a middle step. The router must be discovered with its read only community. Routers do no have VLANs but if a router is involved we must be able to get the MAC addresses from it. Open the browser, login as Admin, change the system default community in the System Config dialog to that of the router, ‘xyz’ in this example, it could be ‘public’ or anything else. Open the Admin tool and edit the network to add the IP address of the router. 10.8.1.12 – 10.8.1.12 10.8.1.1 – 10.8.1.1 Close Admin Tool. Open browser and wait until router is discovered. It should have a green outline and when you hover over the router you should see a list of additional interfaces. In the list should be 10.8.181.1 and 10.8.251.1, the local IPs for the switches and control devices. Go to the router configuration dialog and explicitly set the community to ‘xyz’. 2. Change the system default community to use the VLAN of the switches Open the browser. Login as admin, change the community in the System Config dialog to xyz@181. 3. Edit the IntraVUE network and add only the switches Open Admin Tool. Edit the network. Add the switch scan range. 10.8.1.12 – 10.8.1.12 10.8.1.1 – 10.8.1.1 10.8.181.0 – 10.8.181.255 Close the admin tool. 4. Wait until the hierarchy of switches is correct Open the browser, login as admin, edit the configuration dialog of the router 10.8.1.1 and change the community to xyz. Wait until the switches are moved from unresolved to under the 10.8.1.1 and the switch hierarchy is correct. 5. Edit each discovered switch’s configuration to explicitly use the community of the device VLAN Go to the configuration dialog of each switch and explicitly set the community to xyz@251. The switches will now report the positions of the devices. After this point the switches will not respond to any requests for the port positions of other switches, since they will only answer for devices in VLAN 251. 6. Edit the system default community to use the VLAN of the devices and edit the community.conf file Go to the System Configuration dialog and change the default community to ‘public@251’ so the switches will use the community of the devices if they ever have to re-establish SNMP communication. Now the explicit community for the switches and the system default community are both that of the device VLAN. Create or edit the file c:\program files\IntraVUE\community.conf. The file should contain 1 line for each end device community in use. Typically this will be ‘public’ and there will only be one line in the file as follows: $1=”public” End devices will fail to respond to SNMP using the default ‘public@251’ but will succeed when ‘public’ is tried. 7. Edit the IntraVUE network and add the devices Open the Admin tool and add the IP address range of the end devices. 10.8.1.12 – 10.8.1.12 10.8.1.1 – 10.8.1.1 10.8.181.0 – 10.8.181.255 10.8.251.0 – 10.8.251.255 Close the Admin tool. Open the browser. You should see the end devices initially in unresolved. They then should move out of unresolved to the appropriate switches. On the lines connecting devices to switches and switches to switches you should see the switch port numbers.
©2004 — All rights reserved.