At http://nav.setic.ufsc.br/report/swport, I can view my interfaces with VLANs assignments. The problem is: the information for a given netbox isn't updated. All of the jobs are running fine for that netbox (green lights in jobs list).
For example: I've a set of tagged VLANs in a trunk port on that switch that isn't reported by NAV.
I'll sent to Morten DEBUG logs from ipdevpolld inventory job.
Any return?
2014-07-22 10:36 GMT-03:00 Bruno Galindro da Costa <bruno.galindro@gmail.com
:
At http://nav.setic.ufsc.br/report/swport, I can view my interfaces with VLANs assignments. The problem is: the information for a given netbox isn't updated. All of the jobs are running fine for that netbox (green lights in jobs list).
For example: I've a set of tagged VLANs in a trunk port on that switch that isn't reported by NAV.
I'll sent to Morten DEBUG logs from ipdevpolld inventory job.
-- Att. Bruno Galindro da Costa
On Tue, 22 Jul 2014 10:36:31 -0300 Bruno Galindro da Costa bruno.galindro@gmail.com wrote:
At http://nav.setic.ufsc.br/report/swport, I can view my interfaces with VLANs assignments. The problem is: the information for a given netbox isn't updated. All of the jobs are running fine for that netbox (green lights in jobs list).
For example: I've a set of tagged VLANs in a trunk port on that switch that isn't reported by NAV.
I got the logs you sent me, but they look fine to me. Can you at least describe the actual discrepancies so I can compare what's reported in the web ui with what the debug logs say?
Here are the discrepancies:
# interface GigabitEthernet1/0/1 stp edged-port enable port link-type trunk undo port trunk permit vlan 1 port trunk permit vlan 2 to 4 1001 to 1004 1242 to 1243 1505 #
[image: Imagem inline 1]
As you can see, some VLANs isn't displayed in report...
2014-08-12 11:01 GMT-03:00 Morten Brekkevold morten.brekkevold@uninett.no:
On Tue, 22 Jul 2014 10:36:31 -0300 Bruno Galindro da Costa < bruno.galindro@gmail.com> wrote:
At http://nav.setic.ufsc.br/report/swport, I can view my interfaces with VLANs assignments. The problem is: the information for a given netbox
isn't
updated. All of the jobs are running fine for that netbox (green lights
in
jobs list).
For example: I've a set of tagged VLANs in a trunk port on that switch
that
isn't reported by NAV.
I got the logs you sent me, but they look fine to me. Can you at least describe the actual discrepancies so I can compare what's reported in the web ui with what the debug logs say?
-- Morten Brekkevold UNINETT
On Wed, 13 Aug 2014 11:47:57 -0300 Bruno Galindro da Costa bruno.galindro@gmail.com wrote:
Here are the discrepancies:
# interface GigabitEthernet1/0/1 stp edged-port enable port link-type trunk undo port trunk permit vlan 1 port trunk permit vlan 2 to 4 1001 to 1004 1242 to 1243 1505 #
Imagem inline 1
As you can see, some VLANs isn't displayed in report...
Just to summarize the image you attached: The report shows VLANs 2, 3, 1002, 1003, 1044 and 1243 as allowed on GigabitEthernet1/0/1.
The VLAN data is collected from the Q-BRIDGE-MIB (RFC 4363). Information about egress and tagging in that MIB is organized around VLANs. I.e. there is a table of VLANs, and for each, a list of egress ports and untagged ports for that VLAN (i.e. the assumption is that for a given VLAN, a port listed in egress but not listed in untagged is a port that will transmit tagged packets on that VLAN, and is therefore categorized as a trunk port by NAV).
According the logs you sent, NAV could only find these VLANs in the MIB:
1 2 250 252 1001 1002 1003 1004 1044 1106 1242 1243 1254 1505 2000 4000
From the egress/untagged data retrieved for these ports, the logs show
only 1002, 1003, 1044 and 1243 as tagged on GigabitEthernet1/0/1. The device reports no information about the remaining VLANs that match your "port trunk permit vlan 2 to 4 1001 to 1004 1242 to 1243 1505" config line.
(In contrast, in Cisco proprietary MIBs, the organization of the relationship between VLAN and Ports is reversed, where each trunk port lists every allowed VLAN explicitly, regardless of whether the VLAN is learned or configured into the switch).
What puzzles me is why your report shows VLANs 2 and 3 as allowed on the trunk; the logs do not show that at all.
As an aside, your switch appears to have a dodgy implementation of the BRIDGE-MIB/Q-BRIDGE-MIB, as it seems to be reporting ifindexes in places where baseport numbers are expected (notice all the "saw reference to non-existant baseport" messages in the log).
As long as this is all your switch is willing to divulge, this is all NAV will know about it's VLAN config. Perhaps there are proprietary 3Com MIBs that would give more accurate information, but I don't have any 3Com equipment to test on.
As long as this is all your switch is willing to divulge, this is all NAV will know about it's VLAN config. Perhaps there are proprietary 3Com MIBs that would give more accurate information, but I don't have any 3Com equipment to test on.
But we could use our equipment... I thing we will need to make a plugin exclusively for it... How can I help you with this?
2014-08-14 5:45 GMT-03:00 Morten Brekkevold morten.brekkevold@uninett.no:
On Wed, 13 Aug 2014 11:47:57 -0300 Bruno Galindro da Costa < bruno.galindro@gmail.com> wrote:
Here are the discrepancies:
# interface GigabitEthernet1/0/1 stp edged-port enable port link-type trunk undo port trunk permit vlan 1 port trunk permit vlan 2 to 4 1001 to 1004 1242 to 1243 1505 #
Imagem inline 1
As you can see, some VLANs isn't displayed in report...
Just to summarize the image you attached: The report shows VLANs 2, 3, 1002, 1003, 1044 and 1243 as allowed on GigabitEthernet1/0/1.
The VLAN data is collected from the Q-BRIDGE-MIB (RFC 4363). Information about egress and tagging in that MIB is organized around VLANs. I.e. there is a table of VLANs, and for each, a list of egress ports and untagged ports for that VLAN (i.e. the assumption is that for a given VLAN, a port listed in egress but not listed in untagged is a port that will transmit tagged packets on that VLAN, and is therefore categorized as a trunk port by NAV).
According the logs you sent, NAV could only find these VLANs in the MIB:
1 2 250 252 1001 1002 1003 1004 1044 1106 1242 1243 1254 1505 2000 4000
From the egress/untagged data retrieved for these ports, the logs show only 1002, 1003, 1044 and 1243 as tagged on GigabitEthernet1/0/1. The device reports no information about the remaining VLANs that match your "port trunk permit vlan 2 to 4 1001 to 1004 1242 to 1243 1505" config line.
(In contrast, in Cisco proprietary MIBs, the organization of the relationship between VLAN and Ports is reversed, where each trunk port lists every allowed VLAN explicitly, regardless of whether the VLAN is learned or configured into the switch).
What puzzles me is why your report shows VLANs 2 and 3 as allowed on the trunk; the logs do not show that at all.
As an aside, your switch appears to have a dodgy implementation of the BRIDGE-MIB/Q-BRIDGE-MIB, as it seems to be reporting ifindexes in places where baseport numbers are expected (notice all the "saw reference to non-existant baseport" messages in the log).
As long as this is all your switch is willing to divulge, this is all NAV will know about it's VLAN config. Perhaps there are proprietary 3Com MIBs that would give more accurate information, but I don't have any 3Com equipment to test on.
-- Morten Brekkevold UNINETT
-- Att. Bruno Galindro da Costa
On Thu, 14 Aug 2014 07:41:42 -0300 Bruno Galindro da Costa bruno.galindro@gmail.com wrote:
As long as this is all your switch is willing to divulge, this is all NAV will know about it's VLAN config. Perhaps there are proprietary 3Com MIBs that would give more accurate information, but I don't have any 3Com equipment to test on.
But we could use our equipment... I thing we will need to make a plugin exclusively for it... How can I help you with this?
If you could dig up some documentation on which private MIBs are supported by your 3Com 5500 switch, that might be helpful.
I tried googling around for 3Com MIBs, but didn't find anything promising. For all I know, it could support a bunch of private mibs from H3C, Huawei or HP, with all the ventures and acquisitions 3Com has been through during recent years.
If you are comfortable with it, you could do an snmpwalk over the entire MIB view of the device and send me the output in an e-mail. At least that could provide some pointers for maybe digging up some MIBs.
-
Bruno Galindro da Costa -
Morten Brekkevold