Send Netdot-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://osl.uoregon.edu/mailman/listinfo/netdot-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Netdot-devel digest..."
Today's Topics:
1. [Netdot - Bug #1827] (Resolved) Strange display of vlan with
database id = 1 ([email protected])
2. [Netdot - Bug #1832] (New) Topo display VLANs when ends
mismatch ([email protected])
3. [Netdot - Bug #1832] (Closed) Topo display VLANs when ends
mismatch ([email protected])
4. [Netdot - Bug #1832] Topo display VLANs when ends mismatch
([email protected])
----------------------------------------------------------------------
Message: 1
Date: Wed, 9 Jul 2014 05:05:14 -0700
From: [email protected]
Subject: [Netdot-devel] [Netdot - Bug #1827] (Resolved) Strange
display of vlan with database id = 1
To: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Issue #1827 has been updated by Carlos Vicente.
Category set to UserInterface
Status changed from New to Resolved
Assignee set to Brian Candler
Target version set to 1.0.7
Resolution set to fixed
Pull request merged.
Thank you Brian!
----------------------------------------
Bug #1827: Strange display of vlan with database id = 1
https://osl.uoregon.edu/redmine/issues/1827#change-3232
Author: Brian Candler
Status: Resolved
Priority: Normal
Assignee: Brian Candler
Category: UserInterface
Target version: 1.0.7
Resolution: fixed
When you are in the device info page and show topology, check "include vlans",
and you look at the section labelled "List of vlans and their colors", then the
VLAN with database id=1 appears an extra time with label "1".
The vlan with database id 1 has no special significance as far as I can see.
(In my case it corresponds to vlan tag 6; vlan tag 1 has database id 2)
This is especially apparent if you select the view of a single VLAN, because
the color key shows two entries. For example, if I ask to see only vlan 5, I
get two links labelled "1" (which is vlan 6) and "VLAN0005".
I found the following code in build_device_topology_graph_html and I am at a
loss as to what it is trying to achieve:
<pre>
my $vlans = { 1=>{color=>'#000000', vlan=>Vlan->search(id=>1)->first} };
$argv{vlans} = $vlans;
</pre>
Maybe the intention was to search for vid=>1 not id=>1? If you change this then
the output is a bit more sensible, because at least the VLAN labelled "1" is
the default VLAN.
But simply putting "my $vlans = {}" appears to do the right thing, so I'm not
sure what problem it was trying to solve.
Idea: perhaps it was just trying to make sure that "_randomcolor" always
assigns black to the default vlan? If so, I think it would be better to pass
the vid as an argument to _randomcolor. This would also allow the color to be
chosen deterministically (e.g. use a hash of the vlan ID to assign a color)
which would be very helpful when switching between different views.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://osl.uoregon.edu/redmine/my/account
------------------------------
Message: 2
Date: Wed, 9 Jul 2014 05:51:07 -0700
From: [email protected]
Subject: [Netdot-devel] [Netdot - Bug #1832] (New) Topo display VLANs
when ends mismatch
To: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Issue #1832 has been reported by Brian Candler.
----------------------------------------
Bug #1832: Topo display VLANs when ends mismatch
https://osl.uoregon.edu/redmine/issues/1832
Author: Brian Candler
Status: New
Priority: Low
Assignee:
Category:
Target version:
Resolution:
In the topo display with VLANs enabled, the set of VLANs linking two devices is
arbitrary if it doesn't match at both ends.
Example:
* coresw1 port 1/0/40 with 8 VLANs enabled <---> edgesw with 5 VLANs enabled
* coresw2 port 1/0/40 with 8 VLANs enabled <---> edgesw with 5 VLANs enabled
If I view top with VLANs, I see 8 lines from coresw1 to edgesw, but 5 lines
from coresw2 to edgesw.
I propose the following behavior:
* If the VLAN exists at both ends, show a solid line
* If the VLAN exists at one end only, show a dotted line
Of course, the "VLAN mismatch" report also highlights this issue.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://osl.uoregon.edu/redmine/my/account
------------------------------
Message: 3
Date: Wed, 9 Jul 2014 06:11:53 -0700
From: [email protected]
Subject: [Netdot-devel] [Netdot - Bug #1832] (Closed) Topo display
VLANs when ends mismatch
To: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Issue #1832 has been updated by Brian Candler.
Status changed from New to Closed
Resolution set to wontfix
Looking at the code, dashed is supposed to be used for STP blocked (although I
don't see that in the network here; that's another issue)
Whilst making dotted lines if the ends don't match is easy:
<pre>
--- a/lib/Netdot/UI.pm
+++ b/lib/Netdot/UI.pm
@@ -1899,6 +1899,7 @@ sub build_device_topology_graph {
( ($neighbor_vlan &&
$neighbor_vlan->vlan->vid != $specific_vlan) || !defined($neighbor_vlan) ) );
my $style = 'solid';
+ $style = 'dotted' if ($neighbor_vlan &&
$neighbor_vlan->vlan->vid != $vlan->vlan->vid) || !defined($neighbor_vlan);
my $vname = $vlan->vlan->name || $vlan->vlan->vid;
if (!exists $vlans->{$vname}) {
$vlans->{$vname} = {
color=>&_vlancolor($vlan->vlan->vid), vlan=>$vlan->vlan->id };
</pre>
the problem is that at some ends of the link the VLAN information is missing,
e.g.
* Cisco ASA doesn't list the VLANs as being present
* Dell 5524 with default trunk configuration (all VLANs enabled) doesn't list
the VLANs on the port
and the consequences are (a) there are more dotted lines than there should be,
and (b) some edges are completely missing (because they are only traversed in
one direction)
Therefore I don't recommend this approach.
However it might be possible to fix the missing VLANs.
* when there is an edge from A to B:
* take the union of the VLANs on interface A and the VLANs on interface B
----------------------------------------
Bug #1832: Topo display VLANs when ends mismatch
https://osl.uoregon.edu/redmine/issues/1832#change-3233
Author: Brian Candler
Status: Closed
Priority: Low
Assignee:
Category:
Target version:
Resolution: wontfix
In the topo display with VLANs enabled, the set of VLANs linking two devices is
arbitrary if it doesn't match at both ends.
Example:
* coresw1 port 1/0/40 with 8 VLANs enabled <---> edgesw with 5 VLANs enabled
* coresw2 port 1/0/40 with 8 VLANs enabled <---> edgesw with 5 VLANs enabled
If I view top with VLANs, I see 8 lines from coresw1 to edgesw, but 5 lines
from coresw2 to edgesw.
I propose the following behavior:
* If the VLAN exists at both ends, show a solid line
* If the VLAN exists at one end only, show a dotted line
Of course, the "VLAN mismatch" report also highlights this issue.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://osl.uoregon.edu/redmine/my/account
------------------------------
Message: 4
Date: Wed, 9 Jul 2014 07:11:00 -0700
From: [email protected]
Subject: [Netdot-devel] [Netdot - Bug #1832] Topo display VLANs when
ends mismatch
To: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Issue #1832 has been updated by Brian Candler.
Additional info: the reason I don't see STP blocked links because the STP info
in the database is all NULLs.
<pre>
mysql> select distinct stp_des_bridge,stp_des_port,stp_instance,stp_state from
interfacevlan;
+----------------+--------------+--------------+-----------+
| stp_des_bridge | stp_des_port | stp_instance | stp_state |
+----------------+--------------+--------------+-----------+
| NULL | NULL | NULL | NULL |
+----------------+--------------+--------------+-----------+
1 row in set (0.00 sec)
</pre>
* For Netgear I can see the problem: Netgear don't support the STP part of the
BRIDGE-MIB. Instead, this information is available in vendor-proprietary
FASTPATH-SWITCHING-MIB. So this would be an extension to SNMP-Info to be able
to use it.
* However the Dell *does* have this information, and it seem that SNMP::Info
returns correct values for i_stp_bridge and i_stp_state (however i_stp_port is
empty). Furthermore, the stpinstance table does include an entry for each Dell
switch.
However, dot1qVlanCurrentEgressPorts is empty - these are trunk ports with all
VLANs enabled by default. So {i_vlan_membership} is empty, and nothing is added
by Netdot to the interfacevlans table.
This again is something for SNMP::Info to fix.
----------------------------------------
Bug #1832: Topo display VLANs when ends mismatch
https://osl.uoregon.edu/redmine/issues/1832#change-3234
Author: Brian Candler
Status: Closed
Priority: Low
Assignee:
Category:
Target version:
Resolution: wontfix
In the topo display with VLANs enabled, the set of VLANs linking two devices is
arbitrary if it doesn't match at both ends.
Example:
* coresw1 port 1/0/40 with 8 VLANs enabled <---> edgesw with 5 VLANs enabled
* coresw2 port 1/0/40 with 8 VLANs enabled <---> edgesw with 5 VLANs enabled
If I view top with VLANs, I see 8 lines from coresw1 to edgesw, but 5 lines
from coresw2 to edgesw.
I propose the following behavior:
* If the VLAN exists at both ends, show a solid line
* If the VLAN exists at one end only, show a dotted line
Of course, the "VLAN mismatch" report also highlights this issue.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://osl.uoregon.edu/redmine/my/account
------------------------------
_______________________________________________
Netdot-devel mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-devel
End of Netdot-devel Digest, Vol 88, Issue 6
*******************************************
