FDB switch tables. Adventures in the zoo. Part 1 - SNMP

For many years, in view of the specifics of the work, we are constantly confronted with the need to retrieve FDB tables (Forwarding DataBase) of managed switches with data about switching the MAC addresses of subscribers and devices. During this time, several hundred different models of devices from many manufacturers passed by us, and the number of versions of their firmware is difficult to count. Having accumulated experience - you can share it.



In this case, we will only touch upon the topic of retrieving the required data via the SNMP protocol.



I note in advance that we are not lobbying and are not trying to belittle any vendor or model. The models given for the example are indicated for informational purposes and were at hand at the time of writing the article.

So - SNMP-information retrieval method

Pros:

• SNMP connectivity - there are libraries and standard functions for many programming languages. There is no need to warm your head with a Telnet connection and authorization (a separate topic) ;
• some models of budget switches do not have the ability to Telnet connections;
• in most cases, standard OIDs are used to obtain the required information.

Minuses:

• speed of obtaining information. Slow enough on volumes (removing 2000 MAC addresses via snmpwalk will take, at best, about 40 seconds, while Telnet will issue them instantly) ;
• SNMP loads the switch processor more heavily - in some cases, at 100% when large volumes are removed on low-end models;
• for each VLAN (and there may be hundreds of them) , a separate connection is often required (more on this below);
• sometimes the features of the implementation of the functional differ from different vendors and models.

A separate moment - connection via different SNMP protocols - v.1 or v.2. The second version is faster, but some (obsolete) models do not support it, or they can give only part of the data.

')

Some theory

The FDB table of the switchboard contains records about which MAC address on which switch interface is located. An important clarification is that the interface is not a port. This CAN be a port, and maybe a VLAN number or other logical entity. And since we just need to know the port number, then, in fact, the whole further procedure is started.

The procedure for obtaining information

1. Get the VLAN list
   
   
   • for most switches:
     
     

     snmpwalk -v2c -c public 192.168.0.1 .1.3.6.1.2.1.17.7.1.4.3.1.1 

     
     
     
   • for Cisco and similar
     
     

      snmpwalk -v2c -c public 192.168.0.1 .1.3.6.1.4.1.9.9.46.1.3.1.1.2 

     
     
     
   
   
   However, some models (FoxGate S6224-S4) may swear and do not give anything:
   
   

    iso.3.6.1.4.1.9.9.46.1.3.1.1.2 = No Such Object available on this agent at this OID iso.3.6.1.2.1.17.7.1.4.3.1.1 = No Such Instance currently exists at this OID 

   
   
   
2. Connect to each VLAN and request port-interface indexes for each VLAN. I remind you that the default connection via SNMP is performed to the VLAN default, and to connect to a specific VLAN you need to specify it after the community via @, for example:
   
   
   
   

    snmpwalk -v2c -c public@999 192.168.0.1 .1.3.6.1.2.1.17.1.4.1.2 

   
   
   will produce a port-to-interface ratio for VLAN ID: 999
   
   
   
   The fact is that some VLANs may be given a part of the ports, to other VLANs - another part, etc. And only by polling all the VLANs can you add up the overall picture on the device. Cisco WS-C3550-48 example — first VLAN entries:
   
   
   
   

    iso.3.6.1.2.1.17.1.4.1.2.1 = INTEGER: 1 iso.3.6.1.2.1.17.1.4.1.2.6 = INTEGER: 6 iso.3.6.1.2.1.17.1.4.1.2.8 = INTEGER: 8 iso.3.6.1.2.1.17.1.4.1.2.9 = INTEGER: 9 iso.3.6.1.2.1.17.1.4.1.2.10 = INTEGER: 10 

   
   
   It is given only 5 ports. In this case, the interface numbers are the same as the port numbers.
   
   
   
   
3. Request FDB table by VLAN default:
   
   

    snmpwalk -v2c -c public 192.168.0.1 .1.3.6.1.2.1.17.4.3.1 

   
   
   

    iso.3.6.1.2.1.17.4.3.1.1.0.12.66.164.241.225 = Hex-STRING: 00 0C 42 A4 F1 E1 iso.3.6.1.2.1.17.4.3.1.2.0.12.66.164.241.225 = INTEGER: 25 iso.3.6.1.2.1.17.4.3.1.3.0.12.66.164.241.225 = INTEGER: 3 

   
   
   The returned data consists of three logical parts - the MAC address itself, the interface number and the record type, namely:
   
   
   
   

    1 - other - ,        2 - invalid -  ,     3 - learned - ,   4 - self –  MAC-  5 - mgmt - ,   

   
   
   Records differ in the eleventh (in this example) digit (1, 2, 3) and characterize which parameter is contained in the value.
   
   
   
   However, the devil is in the details - sometimes the data is returned corrupted
   
   
   
   

    iso.3.6.1.2.1.17.4.3.1.1.40.16.123.134.116.160 = Hex-STRING: 28 10 7B 86 74 A0 iso.3.6.1.2.1.17.4.3.1.1.44.171.37.96.118.116 = STRING: ",<%`vt" iso.3.6.1.2.1.17.4.3.1.1.48.133.169.66.201.219 = STRING: "0:cB" iso.3.6.1.2.1.17.4.3.1.1.64.97.134.11.180.236 = STRING: "@a┼_" iso.3.6.1.2.1.17.4.3.1.1.64.97.134.24.59.113 = Hex-STRING: 40 61 86 18 3B 71 

   
   
   Therefore, it does not interfere with checking for validity of the MAC address.
   
   
   
   And sometimes for the MAC-address may not find the second and third entry (interface number and record type). SNMP is SNMP ...
   
   
   
   
4. We are requesting a FDB table for other VLANs (the default VLAN will also be there, but more on that later)
   
   

    snmpwalk -v2c -c public 192.168.0.1 .1.3.6.1.2.1.17.7.1.2 

   
   
   

    iso.3.6.1.2.1.17.7.1.2.1.1.2.1 = Counter32: 8 iso.3.6.1.2.1.17.7.1.2.1.1.2.888 = Counter32: 1 iso.3.6.1.2.1.17.7.1.2.2.1.2.888.0.12.66.164.241.225 = INTEGER: 25 iso.3.6.1.2.1.17.7.1.2.2.1.2.1.0.21.153.136.45.223 = INTEGER: 2 iso.3.6.1.2.1.17.7.1.2.2.1.2.1.0.33.133.202.27.110 = INTEGER: 1 

   
   
   At the beginning - information will be received on the number of entries in each of the VLANs. Unfortunately, it is sometimes not true.
   
   
   
   For example in FoxGate S6224-S4 showed:
   
   
   
   

    iso.3.6.1.2.1.17.7.1.2.1.1.2.1 = Counter32: 21 iso.3.6.1.2.1.17.7.1.2.1.1.2.888 = Counter32: 114 

   
   
   But in reality (further in the list) the records were:
   
   
   • VLAN 1: 22
   • VLAN 82: 1
   • VLAN 130: 4
   • Vlan 888: 115
   • Vlan 2085: 4
   
   
   And the records themselves go, which have a special structure:
   
   

    iso.3.6.1.2.1.17.7.1.2.2.1.2.888.0.12.66.164.241.225 = INTEGER: 25 

   
   
   From the end:
   
   
   • 6 blocks (0.12.66.164.241.225) - MAC address in decimal form
   • 1 block (888) - VLAN number
   
   
   Well, the interface, as can be seen from the value, is number 25.
   
   
   
   However, Cisco may not provide a table for all OIDs.
   
   
   
   

    iso.3.6.1.2.1.17.7.1.2 = No Such Object available on this agent at this OID 

   
   
   And then a fascinating lesson begins - connecting to each VLAN and removing from it the tables indicated by the item above.
   
   
   
   
5. Having received all the necessary data - combine and get first
   
   MAC - Interface - Port
   
   And then:
   
   MAC - Port
   
   Finally.
   
   

Important points

• if there are a lot of VLANs on the switch (one hundred-other) , then you can not even try to remove the FDB table by it. No sane timeout is enough - to bypass them all. It will take a long time.
• individual solutions for different models. Here we are talking about local dopilivaniya final data. Alcatel OmniStack LS 6224 and Allied Telesyn AT-8000S / 24 - though the port numbers are 49-52, but in reality, the port switches have less and the firmware from the older models is used here. It is required to replace port 49 with 25, 50 with 26, etc.
• In some cases, the interface table of the INTERFACE-PORT provides conflicting data. Although Huawei S2326TP-EI-AC provides a correspondence table, FDB displays data with PORT numbers, not interfaces, and standard interface number conversion leads to incorrect data (double conversion)
• stackable switches and chassis will have special interface numbers
• Some budget models of switches will not give out information about the FDB-table for all VLANs at all. Not provided by the manufacturer. Example: D-Link DES-21XX

Total

Despite all the above “features”, the SNMP protocol remains the most popular and convenient method for obtaining an FDB table. In most cases, there is no need for these dances with a tambourine and the usual fit D-Link, which has a single VLAN, will immediately issue a beautiful list with MAC addresses, and the port numbers will match the interfaces, but who knows ...



If the article will be in demand - next time I will tell the features of removal via Telnet.