Hi. For a couple of week ago we could change Vlan in portadmin and save with our HP 5130 switches. But now with Nav 4.4.2 it only show error when saving. It says: Error setting vlan: SNMP Error: inconsistentValue (The set value is illegal or unsupported in some way). What can be the problem?
There is error when we try to check connectivity for snmp for one of the switches via SeedDB also. That's because there's something wrong with Chassis detected. It got two Chassis detected and one is down. I have tried to delete the switch and added it again, but the N/A chassis is appearing after a while again!
5130-EI (serial: XXXXXXX, software: 7.1.045 Release 3109P05) <---- Down N/A (serial: N/A, software: 7.1.045) <--- Don't know where this comes from
Regards Mattias
On Fri, 4 Mar 2016 09:49:43 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
For a couple of week ago we could change Vlan in portadmin and save with our HP 5130 switches. But now with Nav 4.4.2 it only show error when saving. It says: Error setting vlan: SNMP Error: inconsistentValue (The set value is illegal or unsupported in some way).
What can be the problem?
There have been some recent bugfixes to the Portadmin tool, specifically regarding HP switches. I'll have John-Magne look into it.
There is error when we try to check connectivity for snmp for one of the switches via SeedDB also. That's because there's something wrong with Chassis detected. It got two Chassis detected and one is down. I have tried to delete the switch and added it again, but the N/A chassis is appearing after a while again!
5130-EI (serial: XXXXXXX, software: 7.1.045 Release 3109P05) <---- Down N/A (serial: N/A, software: 7.1.045) <--- Don't know where this comes from
If you run the `naventity` command against the switch, what does that produce?
On 07. mars 2016 10:14, Morten Brekkevold wrote:
On Fri, 4 Mar 2016 09:49:43 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
For a couple of week ago we could change Vlan in portadmin and save with our HP 5130 switches. But now with Nav 4.4.2 it only show error when saving. It says: Error setting vlan: SNMP Error: inconsistentValue (The set value is illegal or unsupported in some way).
What can be the problem?
There have been some recent bugfixes to the Portadmin tool, specifically regarding HP switches. I'll have John-Magne look into it.
Hm, the bugfixes related to PortAdmin has been related to saving the interface-data to the database and access-control for users when that has been turned on. Nothing related to switching vlans has been changed.
You are however experiencing a problem, so lets try to debug it. The error message is for once describing quite well what is wrong, so we need to see what NAV tries to set. To do this you need to run some form of packet sniffer, for instance use tcpdump to capture and then use Wireshark to inspect the traffic. If you sniff when trying to set the vlan, it should give you the SNMP-command issued.
Regards
What I'm getting with tcpdump is the following: GetRequest(33) 17.7.1.4.5.1.1.1 GetResponse(35) 17.7.1.4.5.1.1.1=<VLANTAG NOW> SetRequest(35) 17.7.1.4.5.1.1.1=<NEWVLANTAG> GetResponse(35) inconsistentValue@1 17.7.1.4.5.1.1.1=<NEWVLANTAG>
The RAW response with OID View looks like this: 1.3.6.1.2.1.17.7.1.4.5.1.1.1 GAUGE <VLANTAG> ( That is OID, TYPE, VALUE)
/Mattias
----- Ursprungligt meddelande ----- Från: "John Magne Bredal" john.m.bredal@uninett.no Till: "Morten Brekkevold" morten.brekkevold@uninett.no, "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "nav-users" nav-users@uninett.no Skickat: måndag, 7 mar 2016 14:35:09 Ämne: Re: Portadmin - Problem with changing Vlan
On 07. mars 2016 10:14, Morten Brekkevold wrote:
On Fri, 4 Mar 2016 09:49:43 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
For a couple of week ago we could change Vlan in portadmin and save with our HP 5130 switches. But now with Nav 4.4.2 it only show error when saving. It says: Error setting vlan: SNMP Error: inconsistentValue (The set value is illegal or unsupported in some way).
What can be the problem?
There have been some recent bugfixes to the Portadmin tool, specifically regarding HP switches. I'll have John-Magne look into it.
Hm, the bugfixes related to PortAdmin has been related to saving the interface-data to the database and access-control for users when that has been turned on. Nothing related to switching vlans has been changed.
You are however experiencing a problem, so lets try to debug it. The error message is for once describing quite well what is wrong, so we need to see what NAV tries to set. To do this you need to run some form of packet sniffer, for instance use tcpdump to capture and then use Wireshark to inspect the traffic. If you sniff when trying to set the vlan, it should give you the SNMP-command issued.
Regards
Hi Mattias!
On 08. mars 2016 12:24, Mattias Söderholm wrote:
What I'm getting with tcpdump is the following: GetRequest(33) 17.7.1.4.5.1.1.1 GetResponse(35) 17.7.1.4.5.1.1.1=<VLANTAG NOW> SetRequest(35) 17.7.1.4.5.1.1.1=<NEWVLANTAG> GetResponse(35) inconsistentValue@1 17.7.1.4.5.1.1.1=<NEWVLANTAG>
The RAW response with OID View looks like this: 1.3.6.1.2.1.17.7.1.4.5.1.1.1 GAUGE <VLANTAG> ( That is OID, TYPE, VALUE)
Hm, the communication looks normal. I can only see two possible errors:
1: The NEWVLANTAG does not exist on the device. This should not happen as PortAdmin fetches all available vlans before presenting them as choices in the web interface. Could you please verify that the vlan is defined on the device?
2: We've recently discovered that the oid dot1qPortAcceptableFrameTypes exists, as this lead to problems here in Uninett. This was set to admitOnlyVlanTagged and lead to problems setting vlans for PortAdmin. A get on this oid on the interface should reveal if this is set to something else than admitAll.
http://oid-info.com/get/1.3.6.1.2.1.17.7.1.4.5.1.2
/Mattias
----- Ursprungligt meddelande ----- Från: "John Magne Bredal" john.m.bredal@uninett.no Till: "Morten Brekkevold" morten.brekkevold@uninett.no, "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "nav-users" nav-users@uninett.no Skickat: måndag, 7 mar 2016 14:35:09 Ämne: Re: Portadmin - Problem with changing Vlan
On 07. mars 2016 10:14, Morten Brekkevold wrote:
On Fri, 4 Mar 2016 09:49:43 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
For a couple of week ago we could change Vlan in portadmin and save with our HP 5130 switches. But now with Nav 4.4.2 it only show error when saving. It says: Error setting vlan: SNMP Error: inconsistentValue (The set value is illegal or unsupported in some way).
What can be the problem?
There have been some recent bugfixes to the Portadmin tool, specifically regarding HP switches. I'll have John-Magne look into it.
Hm, the bugfixes related to PortAdmin has been related to saving the interface-data to the database and access-control for users when that has been turned on. Nothing related to switching vlans has been changed.
You are however experiencing a problem, so lets try to debug it. The error message is for once describing quite well what is wrong, so we need to see what NAV tries to set. To do this you need to run some form of packet sniffer, for instance use tcpdump to capture and then use Wireshark to inspect the traffic. If you sniff when trying to set the vlan, it should give you the SNMP-command issued.
Regards
Hi. 1: The VLAN tag exists on the switch. So that should not be a problem. (Have checked dot1qVlanCurrentEntry and it's there)
2: All ports are set to admitAll(1)
/Mattias
----- Ursprungligt meddelande ----- Från: "John Magne Bredal" john.m.bredal@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "Morten Brekkevold" morten.brekkevold@uninett.no, "nav-users" nav-users@uninett.no Skickat: måndag, 14 mar 2016 11:00:30 Ämne: Re: Portadmin - Problem with changing Vlan
Hi Mattias!
On 08. mars 2016 12:24, Mattias Söderholm wrote:
What I'm getting with tcpdump is the following: GetRequest(33) 17.7.1.4.5.1.1.1 GetResponse(35) 17.7.1.4.5.1.1.1=<VLANTAG NOW> SetRequest(35) 17.7.1.4.5.1.1.1=<NEWVLANTAG> GetResponse(35) inconsistentValue@1 17.7.1.4.5.1.1.1=<NEWVLANTAG>
The RAW response with OID View looks like this: 1.3.6.1.2.1.17.7.1.4.5.1.1.1 GAUGE <VLANTAG> ( That is OID, TYPE, VALUE)
Hm, the communication looks normal. I can only see two possible errors:
1: The NEWVLANTAG does not exist on the device. This should not happen as PortAdmin fetches all available vlans before presenting them as choices in the web interface. Could you please verify that the vlan is defined on the device?
2: We've recently discovered that the oid dot1qPortAcceptableFrameTypes exists, as this lead to problems here in Uninett. This was set to admitOnlyVlanTagged and lead to problems setting vlans for PortAdmin. A get on this oid on the interface should reveal if this is set to something else than admitAll.
http://oid-info.com/get/1.3.6.1.2.1.17.7.1.4.5.1.2
/Mattias
----- Ursprungligt meddelande ----- Från: "John Magne Bredal" john.m.bredal@uninett.no Till: "Morten Brekkevold" morten.brekkevold@uninett.no, "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "nav-users" nav-users@uninett.no Skickat: måndag, 7 mar 2016 14:35:09 Ämne: Re: Portadmin - Problem with changing Vlan
On 07. mars 2016 10:14, Morten Brekkevold wrote:
On Fri, 4 Mar 2016 09:49:43 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
For a couple of week ago we could change Vlan in portadmin and save with our HP 5130 switches. But now with Nav 4.4.2 it only show error when saving. It says: Error setting vlan: SNMP Error: inconsistentValue (The set value is illegal or unsupported in some way).
What can be the problem?
There have been some recent bugfixes to the Portadmin tool, specifically regarding HP switches. I'll have John-Magne look into it.
Hm, the bugfixes related to PortAdmin has been related to saving the interface-data to the database and access-control for users when that has been turned on. Nothing related to switching vlans has been changed.
You are however experiencing a problem, so lets try to debug it. The error message is for once describing quite well what is wrong, so we need to see what NAV tries to set. To do this you need to run some form of packet sniffer, for instance use tcpdump to capture and then use Wireshark to inspect the traffic. If you sniff when trying to set the vlan, it should give you the SNMP-command issued.
Regards
On 16. mars 2016 07:59, Mattias Söderholm wrote:
Hi. 1: The VLAN tag exists on the switch. So that should not be a problem. (Have checked dot1qVlanCurrentEntry and it's there)
2: All ports are set to admitAll(1)
/Mattias
Hm. Does this happen on other ports? Other switches?
The obvious thing I've forgotten is to just set the vlan with SNMP manually.
Try to execute these commands. If the Q-BRIDGE-MIB::<oid> does not work, substitute with: Q-BRIDGE-MIB::dot1qVlanStaticRowStatus = 1.3.6.1.2.1.17.7.1.4.3.1.5 Q-BRIDGE-MIB::dot1qPvid = 1.3.6.1.2.1.17.7.1.4.5.1.1 IF-MIB::ifAlias = 1.3.6.1.2.1.31.1.1.1.18
Verify active vlans: snmpwalk -v2c -c <community> <device> Q-BRIDGE-MIB::dot1qVlanStaticRowStatus
The resulting indexes should indicate the vlan tag.
List of interface descriptions: snmpwalk -v2c -c <community> <device> IF-MIB::ifAlias
Use the description to find the correct index to use in the next query.
Setting vlan manually: snmpset -v2c -c <write_community> <device> Q-BRIDGE-MIB::dot1qPvid.<index> u <vlan_tag>
If setting the vlan manually does not work, then there must be some configuration/software bug blocking it from working properly.
----- Ursprungligt meddelande ----- Från: "John Magne Bredal" john.m.bredal@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "Morten Brekkevold" morten.brekkevold@uninett.no, "nav-users" nav-users@uninett.no Skickat: måndag, 14 mar 2016 11:00:30 Ämne: Re: Portadmin - Problem with changing Vlan
Hi Mattias!
On 08. mars 2016 12:24, Mattias Söderholm wrote:
What I'm getting with tcpdump is the following: GetRequest(33) 17.7.1.4.5.1.1.1 GetResponse(35) 17.7.1.4.5.1.1.1=<VLANTAG NOW> SetRequest(35) 17.7.1.4.5.1.1.1=<NEWVLANTAG> GetResponse(35) inconsistentValue@1 17.7.1.4.5.1.1.1=<NEWVLANTAG>
The RAW response with OID View looks like this: 1.3.6.1.2.1.17.7.1.4.5.1.1.1 GAUGE <VLANTAG> ( That is OID, TYPE, VALUE)
Hm, the communication looks normal. I can only see two possible errors:
1: The NEWVLANTAG does not exist on the device. This should not happen as PortAdmin fetches all available vlans before presenting them as choices in the web interface. Could you please verify that the vlan is defined on the device?
2: We've recently discovered that the oid dot1qPortAcceptableFrameTypes exists, as this lead to problems here in Uninett. This was set to admitOnlyVlanTagged and lead to problems setting vlans for PortAdmin. A get on this oid on the interface should reveal if this is set to something else than admitAll.
http://oid-info.com/get/1.3.6.1.2.1.17.7.1.4.5.1.2
/Mattias
----- Ursprungligt meddelande ----- Från: "John Magne Bredal" john.m.bredal@uninett.no Till: "Morten Brekkevold" morten.brekkevold@uninett.no, "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "nav-users" nav-users@uninett.no Skickat: måndag, 7 mar 2016 14:35:09 Ämne: Re: Portadmin - Problem with changing Vlan
On 07. mars 2016 10:14, Morten Brekkevold wrote:
On Fri, 4 Mar 2016 09:49:43 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
For a couple of week ago we could change Vlan in portadmin and save with our HP 5130 switches. But now with Nav 4.4.2 it only show error when saving. It says: Error setting vlan: SNMP Error: inconsistentValue (The set value is illegal or unsupported in some way).
What can be the problem?
There have been some recent bugfixes to the Portadmin tool, specifically regarding HP switches. I'll have John-Magne look into it.
Hm, the bugfixes related to PortAdmin has been related to saving the interface-data to the database and access-control for users when that has been turned on. Nothing related to switching vlans has been changed.
You are however experiencing a problem, so lets try to debug it. The error message is for once describing quite well what is wrong, so we need to see what NAV tries to set. To do this you need to run some form of packet sniffer, for instance use tcpdump to capture and then use Wireshark to inspect the traffic. If you sniff when trying to set the vlan, it should give you the SNMP-command issued.
Regards
Well, there is something wrong with the switch or need to be set in some other way. I only get: Error in packet. Reason: inconsistentValue (The set value is illegal or unsupported in some way)
Have tried different commands, but none work. I shall try to figure out how to set them when I have some time...
/Mattias
----- Ursprungligt meddelande ----- Från: "John Magne Bredal" john.m.bredal@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "Morten Brekkevold" morten.brekkevold@uninett.no, "nav-users" nav-users@uninett.no Skickat: torsdag, 17 mar 2016 10:59:30 Ämne: Re: Portadmin - Problem with changing Vlan
On 16. mars 2016 07:59, Mattias Söderholm wrote:
Hi. 1: The VLAN tag exists on the switch. So that should not be a problem. (Have checked dot1qVlanCurrentEntry and it's there)
2: All ports are set to admitAll(1)
/Mattias
Hm. Does this happen on other ports? Other switches?
The obvious thing I've forgotten is to just set the vlan with SNMP manually.
Try to execute these commands. If the Q-BRIDGE-MIB::<oid> does not work, substitute with: Q-BRIDGE-MIB::dot1qVlanStaticRowStatus = 1.3.6.1.2.1.17.7.1.4.3.1.5 Q-BRIDGE-MIB::dot1qPvid = 1.3.6.1.2.1.17.7.1.4.5.1.1 IF-MIB::ifAlias = 1.3.6.1.2.1.31.1.1.1.18
Verify active vlans: snmpwalk -v2c -c <community> <device> Q-BRIDGE-MIB::dot1qVlanStaticRowStatus
The resulting indexes should indicate the vlan tag.
List of interface descriptions: snmpwalk -v2c -c <community> <device> IF-MIB::ifAlias
Use the description to find the correct index to use in the next query.
Setting vlan manually: snmpset -v2c -c <write_community> <device> Q-BRIDGE-MIB::dot1qPvid.<index> u <vlan_tag>
If setting the vlan manually does not work, then there must be some configuration/software bug blocking it from working properly.
----- Ursprungligt meddelande ----- Från: "John Magne Bredal" john.m.bredal@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "Morten Brekkevold" morten.brekkevold@uninett.no, "nav-users" nav-users@uninett.no Skickat: måndag, 14 mar 2016 11:00:30 Ämne: Re: Portadmin - Problem with changing Vlan
Hi Mattias!
On 08. mars 2016 12:24, Mattias Söderholm wrote:
What I'm getting with tcpdump is the following: GetRequest(33) 17.7.1.4.5.1.1.1 GetResponse(35) 17.7.1.4.5.1.1.1=<VLANTAG NOW> SetRequest(35) 17.7.1.4.5.1.1.1=<NEWVLANTAG> GetResponse(35) inconsistentValue@1 17.7.1.4.5.1.1.1=<NEWVLANTAG>
The RAW response with OID View looks like this: 1.3.6.1.2.1.17.7.1.4.5.1.1.1 GAUGE <VLANTAG> ( That is OID, TYPE, VALUE)
Hm, the communication looks normal. I can only see two possible errors:
1: The NEWVLANTAG does not exist on the device. This should not happen as PortAdmin fetches all available vlans before presenting them as choices in the web interface. Could you please verify that the vlan is defined on the device?
2: We've recently discovered that the oid dot1qPortAcceptableFrameTypes exists, as this lead to problems here in Uninett. This was set to admitOnlyVlanTagged and lead to problems setting vlans for PortAdmin. A get on this oid on the interface should reveal if this is set to something else than admitAll.
http://oid-info.com/get/1.3.6.1.2.1.17.7.1.4.5.1.2
/Mattias
----- Ursprungligt meddelande ----- Från: "John Magne Bredal" john.m.bredal@uninett.no Till: "Morten Brekkevold" morten.brekkevold@uninett.no, "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "nav-users" nav-users@uninett.no Skickat: måndag, 7 mar 2016 14:35:09 Ämne: Re: Portadmin - Problem with changing Vlan
On 07. mars 2016 10:14, Morten Brekkevold wrote:
On Fri, 4 Mar 2016 09:49:43 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
For a couple of week ago we could change Vlan in portadmin and save with our HP 5130 switches. But now with Nav 4.4.2 it only show error when saving. It says: Error setting vlan: SNMP Error: inconsistentValue (The set value is illegal or unsupported in some way).
What can be the problem?
There have been some recent bugfixes to the Portadmin tool, specifically regarding HP switches. I'll have John-Magne look into it.
Hm, the bugfixes related to PortAdmin has been related to saving the interface-data to the database and access-control for users when that has been turned on. Nothing related to switching vlans has been changed.
You are however experiencing a problem, so lets try to debug it. The error message is for once describing quite well what is wrong, so we need to see what NAV tries to set. To do this you need to run some form of packet sniffer, for instance use tcpdump to capture and then use Wireshark to inspect the traffic. If you sniff when trying to set the vlan, it should give you the SNMP-command issued.
Regards
When I run `naventity´ I don't see anything wrong (I also checked with an other switch, but the look the same). The switch have been in a stack before but being removed. I have tried to remove everything that have something to do with stacking from it. But it have a little to much power supplys!
[stack] +--5130-EI [chassis] (SERIALNUMBER) +--Level 1 Container #1 [container] | +--Board [module] (SERIALNUMBER) | +--Level 2 Virtual Container #0 [container] | +-- [module] | +--GigabitEthernet1/0/1 [port] | +--GigabitEthernet1/0/2 [port] | +--GigabitEthernet1/0/3 [port] | +--GigabitEthernet1/0/4 [port] | +--GigabitEthernet1/0/5 [port] | +--GigabitEthernet1/0/6 [port] | +--GigabitEthernet1/0/7 [port] | +--GigabitEthernet1/0/8 [port] | +--GigabitEthernet1/0/9 [port] | +--GigabitEthernet.... | +--Ten-GigabitEthernet1/0/49 [port] (▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒) | +--Ten-GigabitEthernet1/0/50 [port] | +--Ten-GigabitEthernet1/0/51 [port] | +--Ten-GigabitEthernet1/0/52 [port] +--Level 1 Container #2 [container] | +--PSU 1 [powerSupply] +--Level 1 Container #3 [container] | +--PSU 2 [powerSupply] +--Level 1 Container #4 [container] | +--PSU 3 [powerSupply] +--Level 1 Container #5 [container] | +--FAN 1 [fan] +--Level 1 Container #6 [container] | +--FAN 2 [fan] +--Level 1 Container #7 [container] +--Level 1 Container #8 [container] +--Level 1 Container #9 [container] +--Level 1 Container #10 [container] | +--SENSOR 1 [sensor] +--Level 1 Container #11 [container] | +--SENSOR 2 [sensor] +--Level 1 Container #12 [container] | +--SENSOR 3 [sensor] +--Level 1 Container #13 [container] | +--SENSOR 4 [sensor] +--Level 1 Container #14 [container] +--Level 1 Container #15 [container] +--Level 1 Container #16 [container] +--Level 1 Container #17 [container] +--Level 1 Container #18 [container]
[stack]
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "nav-users" nav-users@uninett.no Skickat: måndag, 7 mar 2016 11:14:46 Ämne: Re: Portadmin - Problem with changing Vlan
On Fri, 4 Mar 2016 09:49:43 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
For a couple of week ago we could change Vlan in portadmin and save with our HP 5130 switches. But now with Nav 4.4.2 it only show error when saving. It says: Error setting vlan: SNMP Error: inconsistentValue (The set value is illegal or unsupported in some way).
What can be the problem?
There have been some recent bugfixes to the Portadmin tool, specifically regarding HP switches. I'll have John-Magne look into it.
There is error when we try to check connectivity for snmp for one of the switches via SeedDB also. That's because there's something wrong with Chassis detected. It got two Chassis detected and one is down. I have tried to delete the switch and added it again, but the N/A chassis is appearing after a while again!
5130-EI (serial: XXXXXXX, software: 7.1.045 Release 3109P05) <---- Down N/A (serial: N/A, software: 7.1.045) <--- Don't know where this comes from
If you run the `naventity` command against the switch, what does that produce?
On Tue, 8 Mar 2016 12:46:37 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
When I run `naventity´ I don't see anything wrong (I also checked with an other switch, but the look the same). The switch have been in a stack before but being removed. I have tried to remove everything that have something to do with stacking from it.
I'd direct you to the /report/chassis_models report, but I just realized this report doesn't tell you which MIB the information came from, which could contain some clues as to what is going on here.
Could you add "source" to the list of columns in the "SELECT" clause of the "chassis_models" report in `/etc/nav/report/report.conf` and check the output of this web report for the switch in question?
But it have a little to much power supplys!
You don't care for PSU redundancy? ;)
It says SNMPv2-MIB as Source for the switch.
Maby it's good with many virtual PSUs! (** is looking what "internet" says about that...) :P
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "nav-users" nav-users@uninett.no Skickat: fredag, 11 mar 2016 15:25:43 Ämne: Re: Portadmin - Problem with changing Vlan
On Tue, 8 Mar 2016 12:46:37 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
When I run `naventity´ I don't see anything wrong (I also checked with an other switch, but the look the same). The switch have been in a stack before but being removed. I have tried to remove everything that have something to do with stacking from it.
I'd direct you to the /report/chassis_models report, but I just realized this report doesn't tell you which MIB the information came from, which could contain some clues as to what is going on here.
Could you add "source" to the list of columns in the "SELECT" clause of the "chassis_models" report in `/etc/nav/report/report.conf` and check the output of this web report for the switch in question?
But it have a little to much power supplys!
You don't care for PSU redundancy? ;)
On Fri, 11 Mar 2016 15:40:12 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
It says SNMPv2-MIB as Source for the switch.
But is there only a single chassis row for this switch? I though you said NAV reported two chassis?
Sorry, yes it's two rows. The correct chassi comes from ENTITY-MIB (this one is marked as DOWN i NAV) and the wrong empty chassi comes from SNMPv2-MIB (this one is ok in NAV).
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "nav-users" nav-users@uninett.no Skickat: måndag, 14 mar 2016 9:12:57 Ämne: Re: Portadmin - Problem with changing Vlan
On Fri, 11 Mar 2016 15:40:12 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
It says SNMPv2-MIB as Source for the switch.
But is there only a single chassis row for this switch? I though you said NAV reported two chassis?
On Mon, 14 Mar 2016 10:19:34 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Sorry, yes it's two rows. The correct chassi comes from ENTITY-MIB (this one is marked as DOWN i NAV) and the wrong empty chassi comes from SNMPv2-MIB (this one is ok in NAV).
That explains it. The ipdevpoll `system` plugin attempts to parse device software versions from the sysDescr OID (for cases where there is no ENTITY-MIB support in the device).
To store the software version, it needs to have a chassis entity to attach it to, unless one already exists. If the plugin cannot see that NAV already knows a chassis for this device, it will create one marked with "SNMPv2-MIB" as its source (since this is the MIB that defines the sysDescr object).
For some reason, the plugin doesn't see that a chassis did come from ENTITY-MIB, and creates an extra chassis instance. We haven't properly tested how NAV behaves when multiple MIBs are used to source entity information; it seems it's time to take a closer look at just that.
On Thu, 17 Mar 2016 13:39:04 +0100 Morten Brekkevold morten.brekkevold@uninett.no wrote:
On Mon, 14 Mar 2016 10:19:34 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Sorry, yes it's two rows. The correct chassi comes from ENTITY-MIB (this one is marked as DOWN i NAV) and the wrong empty chassi comes from SNMPv2-MIB (this one is ok in NAV).
[...]
For some reason, the plugin doesn't see that a chassis did come from ENTITY-MIB, and creates an extra chassis instance. We haven't properly tested how NAV behaves when multiple MIBs are used to source entity information; it seems it's time to take a closer look at just that.
I did some digging and added more debug statements to the code. While we still need to take a better approach at supporting multiple sources for entity information, it seems to me that your problem must come from the fact that there is some issue collecting information from the ENTITY-MIB on this switch of yours.
This is why the chassis previously seen in the ENTITY-MIB is marked as down (the `entity` plugin can no longer see it), and why the `system` plugin creates a "new" chassis. It seems the code will delete the SNMPv2-MIB sourced chassis once the `entity` plugin finds its chassis info again.
Does `ipdevpoll.log` contain any messages about your switch, other than the regular "I ran some job"-messages?
I found these errors: 2016-03-18 12:29:52,482 [ERROR jobs.jobhandler] [statuscheck <SWITCHIP>] Caught exception during save. Last manager = EntityManager(<class 'nav.ipdevpoll.shadows.entity.NetboxEntity'>, 'ContainerRepository'(...)). Last model = <class 'nav.ipdevpoll.shadows.entity.NetboxEntity'> KeyError: <NetboxEntity: Chassis (Unnamed entity) at <SWITCHIP>> 2016-03-18 12:29:52,487 [ERROR jobs.jobhandler] [statuscheck <SWITCHIP>] Save stage failed with unhandled error exceptions.KeyError: <NetboxEntity: Chassis (Unnamed entity) at <SWITCHIP>> 2016-03-18 12:29:52,488 [ERROR jobs.jobhandler] [statuscheck <SWITCHIP>] Job 'statuscheck' for <SWITCHIP> aborted: Job aborted due to save failure (cause=KeyError(<NetboxEntity: Chassis (Unnamed entity) at <SWITCHIP>>,))
/Mattias
----- Ursprungligt meddelande ----- Från: "Morten Brekkevold" morten.brekkevold@uninett.no Till: "Mattias Söderholm" mattias.soderholm@malax.fi Kopia: "nav-users" nav-users@uninett.no Skickat: fredag, 18 mar 2016 12:17:15 Ämne: Re: Portadmin - Problem with changing Vlan
On Thu, 17 Mar 2016 13:39:04 +0100 Morten Brekkevold morten.brekkevold@uninett.no wrote:
On Mon, 14 Mar 2016 10:19:34 +0200 Mattias Söderholm mattias.soderholm@malax.fi wrote:
Sorry, yes it's two rows. The correct chassi comes from ENTITY-MIB (this one is marked as DOWN i NAV) and the wrong empty chassi comes from SNMPv2-MIB (this one is ok in NAV).
[...]
For some reason, the plugin doesn't see that a chassis did come from ENTITY-MIB, and creates an extra chassis instance. We haven't properly tested how NAV behaves when multiple MIBs are used to source entity information; it seems it's time to take a closer look at just that.
I did some digging and added more debug statements to the code. While we still need to take a better approach at supporting multiple sources for entity information, it seems to me that your problem must come from the fact that there is some issue collecting information from the ENTITY-MIB on this switch of yours.
This is why the chassis previously seen in the ENTITY-MIB is marked as down (the `entity` plugin can no longer see it), and why the `system` plugin creates a "new" chassis. It seems the code will delete the SNMPv2-MIB sourced chassis once the `entity` plugin finds its chassis info again.
Does `ipdevpoll.log` contain any messages about your switch, other than the regular "I ran some job"-messages?
-
John Magne Bredal -
Mattias Söderholm -
Morten Brekkevold