Could someone please tell me the community string indexing for switches other than Cisco?
Edit:
This is how to poll Q-BRIDGE-MIB for mac-addresses from the only non-Cisco I have, a DLink DGS-3200. I'm not using [community@vlan] for non-Cisco switches. You're correct that this indexing only applies to Ciscos. I expect any non-Cisco switch, which supports Q-BRIDGE-MIB to work the same way.
Polling sysDescr to document the switch under test
[mpenning@tsunami ~]$ # Demo from a DLink DGS-3200 switch
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public -OXsq 172.16.1.2 sysdescr
sysDescr.0 "DGS-3200-10 Gigabit Ethernet Switch"
[mpenning@tsunami ~]$
Walking dot1qVlanStaticName: List Vlans and their text names
[mpenning@tsunami ~]$
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public 172.16.1.2 .1.3.6.1.2.1.17.7.1.4.3.1.1
BRIDGE-MIB::dot1dBridge.7.1.4.3.1.1.1 = STRING: "default"
[mpenning@tsunami ~]$
[mpenning@tsunami ~]$
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public 172.16.1.2 .1.3.6.1.2.1.17.7.1.2.1.1.2
BRIDGE-MIB::dot1dBridge.7.1.2.1.1.2.1 = Counter32: 17
[mpenning@tsunami ~]$
[mpenning@tsunami ~]$
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public 172.16.1.2 .1.3.6.1.2.1.17.7.1.4.2.1.4
BRIDGE-MIB::dot1dBridge.7.1.4.2.1.4.2562.1 = Hex-STRING: FF C0 00 00
[mpenning@tsunami ~]$
The mac-addresses show up as a string of six decimal digits in the indexes to dot1qTpFdbPort. Note that I have a downstream switch connected to this switch on port 1/5...
[mpenning@tsunami ~]$
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public 172.16.1.2 .1.3.6.1.2.1.17.7.1.2.2.1.2
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.13.101.22.202.65 = INTEGER: 5
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.13.189.7.134.128 = INTEGER: 5
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.13.189.7.134.129 = INTEGER: 5
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.29.161.205.83.70 = INTEGER: 9
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.48.27.188.167.215 = INTEGER: 2
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.192.183.110.158.29 = INTEGER: 3
... more entries here
[mpenning@tsunami ~]$
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public -OXsq 172.16.1.26 .1.3.6.1.2.1.17.1.4.1.2
dot1dBasePortIfIndex[1] 1
dot1dBasePortIfIndex[2] 2
dot1dBasePortIfIndex[3] 3
dot1dBasePortIfIndex[4] 4
dot1dBasePortIfIndex[5] 5
dot1dBasePortIfIndex[6] 6
dot1dBasePortIfIndex[7] 7
dot1dBasePortIfIndex[8] 8
dot1dBasePortIfIndex[9] 9
dot1dBasePortIfIndex[10] 10
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public -OXsq 172.16.1.26 ifName
ifName[1] 1/1
ifName[2] 1/2
ifName[3] 1/3
ifName[4] 1/4
ifName[5] 1/5
ifName[6] 1/6
ifName[7] 1/7
ifName[8] 1/8
ifName[9] 1/9
ifName[10] 1/10
ifName[5121] System
[mpenning@tsunami ~]$
ORIGINAL:
There is a mistake in your OID, you're using 1.3.6.2.3.1.17.4.3.1.1; however, dot1dTpFdbAddress is 1.3.6.1.2.1.17.4.3.1.1.
The difference is changing some octets, below...
OID Incorrect: 1.3.6.2.3.1.17.4.3.1.1 <--- Not this
OID Corrected: 1.3.6.1.2.1.17.4.3.1.1 <--- Use this
^ ^
| |
You probably don't have MAC flapping on the 4948. MAC flapping is where traffic from a MAC address is originated on more than one port in a short period of time. It seems to be happening on the 3650, but not happening on the 4948. This is specific to the switch, and the error will not be sent to other network devices.
That it is happening on one switch, but not the other, is a clue to help you troubleshoot where the problem may lie. This is probably caused by a layer-2 loop. You should investigate how the switches are connected, both directly and indirectly. There may be an STP misconfiguration on how the ports showing the MAC address are connected. This may be caused by someone plugging in a hub or dumb switch into multiple ports. Unfortunately, you may need physically check things out. Using portfast with BPDU guard on access ports may prevent this situation.
Best Answer
You don't mention brand of the switch, any management software, or any configuration (in particular how that interface was previously configured), so I can only answer generically.
Most default switch MAC address tables have a relatively low timeout to age out entries. Just because you are only seeing 19 devices from the same VLAN on a port currently doesn't mean that there aren't other devices that will need to utilize a different VLAN on the trunk.
You say you "guessed that there was a switch connected to that interface." Guessing is a bad way to decide on making changes in a network. This indicates you do not understand the network in enough detail to be making the change and you should spend more time investigating before doing so.
Connecting two switches utilizing access ports? Wrong, no. It is considered a best practice to connect two switches with trunk/tagged ports. However, there are circumstances where using access ports is perfectly fine, if not necessary.
There may also be other considerations. For instance, there may be default configuration (or other configuration on the port) that could apply differently to access ports or trunk/tagged ports. For example, if your switches use VTP (or a similar mechanism), VTP only runs over trunk/tagged ports. Another example would be spanning-tree portfast (or similar), which can be applied by default to access ports along with features such as BPDU guard.
Wrong to make a change based on a guess? Yes, absolutely. Unless you have some pressing reason forcing your hand, you shouldn't make decisions in networking based on guesses. You are likely to create issues.
No. There should be no noticeable difference in performance between an access port and trunk port. However, look a couple paragraphs up as there may be configuration that is applied differently to access ports and trunk/tagged ports. This configuration may have some impact on the port operation.
Yes and you really should have done so before making the change. When other parties are involved, it is almost always best to reach out to them before making any changes.
Reverse the situation, what if the other person were to make such a change without informing you? Go a bit further and say this disrupted operation on your network in some fashion. Wouldn't you prefer that you had been informed before hand so you wouldn't have to spend time and effort troubleshooting an issue created by someone else?