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

For many years, due to the specifics of our work, we constantly face the need to remove FDB tables (Forwarding DataBase) of managed switches with data on switching MAC addresses of subscribers and devices. During this time, several hundred different models of devices of many manufacturers passed us, and the number of versions of their firmware is difficult to count. Having gained experience, you can share it.

In this case, we will only touch on the topic of removing 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 shown for example are for informational purposes and were at hand at the time of writing.

So - SNMP-method of information retrieval

Pros:

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

Minuses:

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

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

Bit of theory

The switch FDB table contains entries about which MAC address is located on which interface of the switch. An important clarification - the interface is not a port. This MAY be a port, or maybe a VLAN number or other logical entity. And since we need to know exactly 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 the like
     

     snmpwalk -v2c -c public 192.168.0.1 .1.3.6.1.4.1.9.9.46.1.3.1.1.2
     

     
     
   
   At the same time, some models (FoxGate S6224-S4) can swear and give nothing:
   

   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. We connect to each VLAN and request the port-to-interface indexes for each VLAN. I remind you that the default connection via SNMP is made to VLAN default, and to connect to a specific VLAN, you need to specify it after 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 give a port-to-interface relationship for VLAN ID: 999
   
   The fact is that some ports can be given part of some VLANs, other parts can be given to other VLANs, etc. And only by polling all the VLANs can you add up the overall picture of 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
   

   
   Only 5 ports were given to it. In this case, the interface numbers are the same as the port numbers.
   
   
3. We request the 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 actual MAC address, interface number, and 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 the validation of the MAC address.
   
   And sometimes for the MAC address there may not be a second and third record (interface number and record type). SNMP is such SNMP ....
   
   
4. We request the 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 about the number of entries in each of the VLANs will be received. Unfortunately, it is sometimes not true.
   
   For example, 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 entries 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 you can see from the value, is number 25.
   
   However, Cisco may not produce 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 the fascinating lesson begins - connecting to each VLAN and eating from it the table specified in paragraph above.
   
   
5. Having received all the necessary data, we combine it and get the
   MAC first - Interface - Port
   And then:
   MAC - Port
   Finally.
   

Important points

• if there are a lot of VLANs on the switch (a hundred or two) , then you don’t even have to try to remove the FDB table from it. No sane timeouts are enough - bypassing them all. It will take a long time.
• individual solutions for different models. Here we are talking about local doping of the final data. Alcatel OmniStack LS 6224 and Allied Telesyn AT-8000S / 24 - although port numbers 49-52 are returned, but in reality the port switches have fewer and firmware from older models is used here. It is required to replace port 49 with 25, 50 with 26, etc.
• in some cases, the INTERFACE-PORT compliance table provides conflicting data. Huawei S2326TP-EI-AC, although it gives a correspondence table, but at the same time data with PORT numbers are displayed in FDB, not interfaces, and standard methods for converting interface numbers lead to incorrect data (double conversion)
• stackable switches and chassis will have special interface numbers
• some of the 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 the FDB table. In most cases, there is no need for the indicated dances with a tambourine and the usual valid D-Link with a single VLAN will immediately produce a beautiful list with MAC addresses, and the port numbers will match the interfaces, but who knows ...

If the article is in demand, I'll tell you next time Telnet removal features.