Welcome to Infoblox NetMRI Community Sign in | Join | Help
in Search

Applied Infrastructure

Calling All Devices - What's on the network?

It is configuration checking time.  Do you know where all your devices are?  How do you know that there's not a rogue device lurking in your network?   How do you know that the configuration collection mechanism has discovered all the devices in your network?

I just finished working on a security assessment and on a network baseline.  One of the big questions that  came up at the start is "how do we know that we haven't missed a key device?  It is relatively easy to perform a manual inventory verification in a small network or a security assessment of a small piece of a larger network. But as the network size increases, these manual processes don't scale up.

What discovery mechanisms make sense?  Obviously, CDP and LLDP are easy candiates as long as they are enabled on the network.  Routing protocol neighbors from routing protocols or from the next-hop in routing tables provide data about Layer 3 neighbors.   A list of routing neighbors and next hops that are not accessible from the NMS should be investigated.

Another mechanism for finding Layer 3 subnets is to use Netflow.  Filter out all the source and destination subnets that are known and investigate any remaining addresses and subnets.  Of course, some addresses may be due to spoofed addresses from compromised machines, a good thing to discover during a security assessment so that they can be fixed.

Transparent bridging makes discovery of Layer 2 neighbors more interesting.  One approach is to look at the OUI field of the MAC addresses found in the switch forwarding tables.  I am not sure that this is a very reliable method because many vendors like HP and Dell now build both networking and end system devices.  I like to look for switch ports that are receiving BPDUs, which can be done on Cisco with show spanning-tree int gi 0/1 detail (see example output below).  Another Layer 2 indicator is finding switch ports that have multiple MAC addresses associated with them, filtering out Cisco phones with attached computers as necessary. Multiple MAC addresses implies a downstream hub or switch.  A MAC address check for OUI on the set of addresses may result in a clue about which device may be a switch.  Hubs will be transparent so you may need to visit the site to find out what's going on there.

The other factor in doing a Layer 2 discovery is finding switch ports that are up/up but have no associated MAC address in the forwarding table, making it difficult to determine what is connected to the port.  Such ports may typically be span ports used by IDS/IPS systems.  Physical inspection is typically required to determine what is connected to these ports.

  -Terry

Sample output showing BPDUs sent and received on an interface.  See the last line of the output.

1#show spanning-tree int gi 0/1 detail
Port 1 (GigabitEthernet0/1) of VLAN0010 is designated forwarding
  Port path cost 4, Port priority 128, Port Identifier 128.1.
  Designated root has priority 32778, address 0011.5c6b.f580
  Designated bridge has priority 32778, address 0011.5c6b.f580
  Designated port id is 128.1, designated path cost 0
  Timers: message age 0, forward delay 0, hold 0
  Number of transitions to forwarding state: 1
  The port is in the portfast mode
  Link type is point-to-point by default
  BPDU: sent 203410, received 0 

Comments

 

IT Management Blog Carnival - 1st edition - IT Skeptic, Martin Thompson, Harris Andres,... | PMIT.PL Blog said:

Pingback from  IT Management Blog Carnival - 1st edition - IT Skeptic, Martin Thompson, Harris Andres,...  | PMIT.PL Blog

October 7, 2009 4:10 PM

About tslattery

Terry Slattery, CCIE #1026, is a senior network engineer with decades of experience in the internetworking industry. Prior to joining Chesapeake NetCraftsmen as a full time consultant, Terry was the founder and CTO of Netcordia, and inventor of NetMRI, a suite of network management products. Terry started Netcordia as a consulting company in 2000 and transitioned to a network management product company in 2003. During the consulting days, he used his network design and implementation skills to lead a team in the design and implementation of a high availability network at a brokerage clearing house. Terry is the former President and founder of Chesapeake Computer Consultants, Inc., a networking and computer systems training and consulting company. He co-invented and patented the vLab(tm) internet-based remote lab system. He is co-author of the McGraw Hill text Advanced IP Routing in Cisco Networks. Terry led the team that developed the current Cisco IOS user interface under contract to Cisco Systems. Terry is experienced in the design and installation of large TCP/IP based networks and is a successful network protocol instructor. He is the second Cisco Certified Internetworking Expert (CCIE) #1026 and the first outside of Cisco. He enjoys membership on the Vanderbilt University Engineering School’s Industrial Advisory Board and the IEEE.

This Blog

Syndication