Dell N4032F: switch providing garbled IPv6 addresses via SNMP when querying IPV6-MIB::ipv6

Hello swalker

When I see garbled output I would look at baud rate. Are you connected via console cable? Try checking different Baud rate.

Are any other commands returning garbled information?

Are you using the latest ver. 6.5.4.20 MIB,  Release-6.5.4.20-MIBs.zip from the firmware update?

I notice that Ver.6.2.6.6 fixed - NSeries-6.2.1.6-show buffers command shows incorrectly spaced or garbled output via telnet/SSH, but you are beyond that version.

If you are able, you could try a Power drain: Shut down, remove power for one minute. Reconnect power and power up.

If all that checks out and nothing helps; could you provide more information?

Was this working before and now is not working correctly?

     Was anything done on the switch around the time it started?

Does anything change if you try from a different workstation?

Hello,

When I see garbled output I would look at baud rate. Are you connected via console cable? Try checking different Baud rate.

This is via SNMP.  It's IP-based, so no console cable.

---

Are any other commands returning garbled information?

 

No.

---

Are you using the latest ver. 6.5.4.20 MIB,  Release-6.5.4.20-MIBs.zip from the firmware update?

---

Yep, just downloaded them.  I get the same result from this MIB as with the IETF-standard MIB.

---

If you are able, you could try a Power drain: Shut down, remove power for one minute. Reconnect power and power up.

---

This isn't really possible without planning a maintenance window, but just to confirm, this happens on both of our two switches of this model, located in different buildings, both of which were restarted during a maintenance window less than a month ago.  I absolutely understand the normal logic of "turn it off and back on again" but in this case, it's not really possible or justifiable, especially when it affects both of our redundant units.

---

Was this working before and now is not working correctly?

     Was anything done on the switch around the time it started?

---

This is a new implementation, so it was not something we have tried to use in the past.

---

Does anything change if you try from a different workstation?

---

Nope, I have tried this on two different Linux workstations loaded with the net-snmp package, using both the default IETF MIB files and the Dell-provided MIB files.

---

If all that checks out and nothing helps; could you provide more information?

---

Unfortunately, I think I've provided all the relevant information.  The switches are working 100% fine otherwise, and SNMP queries using the equivalent command for IPv4 ARP table information work fine.  It honestly seems like either:

1. This is a bug, or
2. The IPv6 address information, currently represented by sixteen (ASCII? certainly not hexadecimal) characters that are mostly dots, is somehow encoded in some way and needs to be decoded using some process that Dell does not seem to have documented.

The only other command I can provide would be a specific example of the command that's getting this information on our monitoring machine.  Given that this command functions perfectly for every other SNMP query, I doubt it will be useful, but just in case:

snmpwalk -m ALL -M /usr/share/snmp/mibs/dell -v 2c -c "ourSNMPcommunity" hostnameOfSwitch IPV6-MIB::ipv6NetToMediaPhysAddress

Variations of this have been tried:

• with and without the -m argument that loads all MIB modules
• with and without the -M argument that loads the Dell-provided MIB files
• via SNMP v2, but also SNMPv3 (same results)

If Dell has any documentation (it's not in the switch's manual nor the Dell-provided MIB files) on how to decrypt this garbled information, or why it's there, it would be much appreciated!!

Thanks for your time.

Hello swalker,

I'll need more time researching into this. I'll update you when I have more information.

Hi Charles,

---

Could you provide the results of running the snmpwalk command using the "-On" modifier to fully render the OID.

snmpwalk -On -m ALL -M /usr/share/snmp/mibs/dell -v 2c -c "ourSNMPcommunity" hostnameOfSwitch IPV6-MIB::ipv6NetToMediaPhysAddress

---

Here is an example of the output  (there are hundreds of similar lines, one for each IPv6 address in the IPv6 neighbor table):

.1.3.6.1.2.1.55.1.12.1.2.947.254.128.0.0.0.0.0.0.8.215.166.89.144.164.99.239 = STRING: 78:7b:8a:ae:88:63

After checking in the IPv6 neighbour tables, that corresponds with the following link-local IPv6 address:

fe80::8d7:a659:90a4:63ef

So, it seems that that IPv6 address, which can be fully expanded to fe80:0000:0000:0000:08d7:a659:90a4:63ef, somehow corresponds to 254.128.0.0.0.0.0.0.8.215.166.89.144.164.99.239.

IPv6 addresses, 128 bits long, give addresses in hexadecimal, with each letter corresponding with four bits, for a total length of 32 hexadecimal characters.

For anyone who works with IPv4, the output from the command you provided, starting after the 947 (the interface identifier), seems like a string of 8-bit binary numbers (notice there are no numbers higher than 255), of which there are 16 - adding up to a total of 128 bits, like an IPv6 address.

I converted this string into groupings of eight bits of binary (the spaces represent where there are dots in the string that your command returned):

11111110 10000000 00000000 00000000 00000000 00000000 00000000 00000000 00001000 11010111 10100110 01011001 10010000 10100100 01100011 11101111

Then, I split it up, into groupings of four bits, with each one corresponding to a hexadecimal part of what hopefully ends up being an IPv6 address:

1111 1110 1000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 1101 0111 1010 0110 0101 1001 1001 0000 1010 0100 0110 0011 1110 1111

converting each group of four binary bits into hexadecimal gives:

f e 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 d 7 a 6 5 9 9 0 a 4 6 3 e f

Which, of course, looks a heck of a lot like an IPv6 address if you add colons every 4th character:

fe80:0000:0000:0000:08d7:a659:90a4:63ef

Shortened to: fe80::8d7:a659:90a4:63ef

So, that's the secret: When using the OID directly (for example, using the command provided by Charles), we get sixteen eight-bit decimal groupings that should each be individually converted into binary.  Then, after adding them all together, we cut that long binary number into 16 groups of four bits, and convert each group to hexadecimal to get the IPv6 address.

I have no clue why Dell would give IPv6 addresses in this way, instead of providing them in standard hexadecimal notation (as my Cisco switches do) or in binary directly, but at least this has given me the means to write a program that will do the conversion.  Thanks for your response, Charles!