MAC, IP, VLAN and switch interface mapping
MAC Location using Bridge Forwarding Tables
Every switch interface (physical or virtual) is effectively a "bridge", and contains its own MAC forwarding table information. The forwarding table tells the switch which MACs are downstream on each interface. When the switch receives a packet, it looks up the forwarding table to see which interface it should forward the packet out, otherwise it floods the packet out all interfaces on that VLAN.
Switches operate independently of each other and do not exchange forwarding table information (unlike routers which do exchange routing table information). All a switch does is observe the source MAC of each packet and adds an entry in its forwarding table. Every switch will contain a forwarding entry for every MAC on the subnet.
The tricky bit in a switch port mapper algorithm is: how do you determine which switch interface a MAC is actually connected to ?
In the following diagram, you will see that the MAC for PC(a) will be seen on all switch interfaces which point back in the direction of PC(a). As far as Switch1 is concerned, PC(a) is directly connected to one of its interfaces.
Since the router strips MAC addresses off, the MAC for PC(a) will never be seen on another subnet. The router is effectively isolating the layer 2 networks.
The AKIPS switch port mapper algorithm determines which switch interfaces are most likely trunks (ie. connected to other switches) and which interfaces are most likely edge interfaces. This is actually quite complex because you can not just count the number of MACs in the forwarding table for each interface, tagging those with a single MAC as edge interfaces and those with multiple MACs as trunk interface because a switch interface may have multiple devices attached to it (eg. IP phone and PC).
Data Collection Challenges:Collecting forwarding table data is not as simple as doing an SNMP walk of the bridge forwarding table, which only works for the default VLAN. For all other VLANs, you need to walk the forwarding tables using SNMPv2 community name addressing or SNMPv3 contexts. If you have 100 VLANs in a switch, then you need to do 100 separate SNMP walks of the switch to gather the forwarding table data.
Walking large bridge forwarding tables can have a severe impact to the switch CPU. This is because the forwarding tables will be held in some type of tree data structure for fast insertion and lookup, or in hardware. SNMP requires the data to be returned in binary order, therefore for each SNMP Get/GetBulk request, the switch has to extract/sort the forwarding table into binary order, do a search for the requested position, then construct and return an SNMP response. This is why walking large forwarding tables can spike the CPU of many switches.
IPv4 ARP and IPv6 Neighbour Tables
Mapping IPv4 and IPv6 addresses to MACs is also important information for network managers. This is usually done by collecting IPv4 ARP or IPv6 neighbour tables from devices (e.g. routers, switch management modules, hosts) attached to each subnet.
The IP to MAC address mappings are typically found in the following tables:
A few things to note:
A MAC can have many IP addresses (e.g. a router or host interface), but an IP can only have one MAC.
An ARP table should ONLY contain entries for IPs on its directly connected networks. For example, a router interface configured with an address of 10.0.0.0/24 should only have ARP entries from 10.0.0.1 to 10.0.0.254 (10.0.0.0 being the network and 10.0.0.255 being the broadcast address).
One of the major design flaws the IP-MIB.ipNetToPhysicalTable is that the most important MIB objects are defined as 'not-accessible', therefore devices do not return them in an SNMP walk. This is only a slight annoyance for AKIPS though.
Some devices incorrectly pollute their ARP tables with IP addresses from remote subnets. This is typically caused by lazy programmers who blindly add ARP entries without checking if they are local or remote network addresses. ARP tables should ONLY contain entries for attached networks. AKIPS discards all bogus ARP entries, otherwise invalid reporting will occur.
In the diagram below, Router1 can only contain ARP entries for:
Router1 should NEVER contain ARP entries for the other subnets.
In some network architectures, there are no devices from which ARP tables can be retrieved. Many firewalls do not fully implement the IP-MIB, so in the example above, no IP to MAC mappings can be done for the 10.0.3.0 subnet.
Switch Management modules have an IP stack, but their ARP tables will only contain entries for local devices which are communicating directly with it (e.g. a network management platform). Switches do not add ARP entries for packets it is just switching.
VLAN Mapping
Mapping VLANs to interfaces is also useful for network managers. AKIPS allows you to group and report on interface statistics by VLAN.
VLAN membership information is available in the standard Q-BRIDGE-MIB.dot1qVlanStaticTable. The Q-BRIDGE-MIB.dot1qVlanStaticEgressPorts object is a bit string that maps Bridge Port Indexes to a VLAN. It is important to note that a Bridge Port Index is NOT the same as IF-MIB.ifIndex, therefore a second mapping has to be performed to map Bridge Port Indexes to IF-MIB interface indexes.
Data Collection Challenges:Some vendors do not support the Q-BRIDGE-MIB, but instead offer an alternative (e.g. CISCO-VLAN-MEMBERSHIP-MIB).
The dot1qVlanStaticEgressPorts MIB object is defined as a bit string, where each bit represents a single Bridge Port Index mapping. Some vendors incorrectly return a CSV text string containing all the Bridge Port Indexes for each VLAN. AKIPS detects and handles this.
The dot1qVlanStaticEgressPorts MIB object only needs to be as long as the highest Bridge Port Index. For example, if the highest Bridge Port Index is 64, then the switch only needs to return 8 bytes. Some vendors always return data for 4096 possible indexes (i.e. 512 bytes). This can make the data retrieval process unnecessarily inefficient.
