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 #1745] (New) ipv6 addresses on interfaces on
nexus 7K not working ([email protected])
2. [Netdot - Bug #1746] (New) patch : DHCPD Export Class drops
free text indentation ([email protected])
3. University of Michigan documents for review and comment
(William Bulley)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Mar 2013 13:41:37 -0700
From: [email protected]
Subject: [Netdot-devel] [Netdot - Bug #1745] (New) ipv6 addresses on
interfaces on nexus 7K not working
To: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Issue #1745 has been reported by Wim Vandersmissen.
----------------------------------------
Bug #1745: ipv6 addresses on interfaces on nexus 7K not working
https://osl.uoregon.edu/redmine/issues/1745
Author: Wim Vandersmissen
Status: New
Priority: Normal
Assignee:
Category:
Target version:
Resolution:
ipv6 addresses on vlan interfaces on nexus 7K weren't showing up
Seems like nexus is giving other values back on OID 1.3.6.1.2.1.4.34.1.5
(ipAddressType)
The current code uses the wrong field for the ifIndex identifier. It also seems
that for nexus the ifIndex id is always greater than 150000000
The following code works for me and fixes the issue.
<pre>
--- Device.pm 2012-12-05 17:35:01.000000000 +0100
+++ Device.pm 2013-03-27 14:56:26.000000000 +0100
@@ -1133,10 +1133,15 @@
if ( $key =~ /^.+\.((?:\d+\.){15}\d+)$/o ) {
$addr = $self->_octet_string_to_v6($1);
}
- if ( $val =~ /^(\d+)\.\d+\.\d+\.([\d\.]+)\.(\d+)$/o ) {
+ if ( $val =~ /^(\d+)\.(\d+)\.\d+\.([\d\.]+)\.(\d+)$/o ) {
# ifIndex, type, size, prefix length
- $iid = $1; $len = $3;
- $pfx = $self->_octet_string_to_v6($2);
+ if ( ($1 == 1) && ($2 > 150000000)) {
+ $iid=$2;
+ } else {
+ $iid=$1;
+ }
+ $len = $4;
+ $pfx = $self->_octet_string_to_v6($3);
}
if ( $iid && $addr && $pfx && $len ){
next unless (defined $dev{interface}{$iid});
</pre>
--
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: Thu, 28 Mar 2013 03:36:01 -0700
From: [email protected]
Subject: [Netdot-devel] [Netdot - Bug #1746] (New) patch : DHCPD
Export Class drops free text indentation
To: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Issue #1746 has been reported by Didier Moens.
----------------------------------------
Bug #1746: patch : DHCPD Export Class drops free text indentation
https://osl.uoregon.edu/redmine/issues/1746
Author: Didier Moens
Status: New
Priority: Normal
Assignee:
Category:
Target version:
Resolution:
When adding multiple lines in the 'Include Text'-field in the DhcpScope form,
DHCPD export only indents the first line.
The attached patch indents the full free-form text block.
--
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: Thu, 28 Mar 2013 14:55:21 -0400
From: William Bulley <[email protected]>
Subject: [Netdot-devel] University of Michigan documents for review
and comment
To: Carlos Vicente <[email protected]>
Cc: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
We have put together some design documents to illustrate our thinking
about networks and of ways to enhance NetDoT to better support networks.
Attached please find a textual/tutorial document written by Dr. Kurt
Hillig. His document refers to the other attachments (all PDF files).
Notes_On_Nets.txt
Dental_School_Network_Transition.pdf
Pathological_VLANs.pdf
Pathological_VLAN_Table_Structure.pdf
Summary_of_Netdot_Schema_Changes.pdf
We would like to solicit comments, suggestions, criticisms, etc. from
the NetDoT development community about the contents of these files.
Regards,
web...
--
William Bulley Email: [email protected]
72 characters width template ----------------------------------------->|
-------------- next part --------------
Some Notes on Nets and Databases
================================
What follows is an attempt to: A) describe some of our struggles with and
needs for tools to manage complex networks; B) provide some examples of
real-world cases of "pathological" complexity that we have encountered;
C) stimulate discussion on how network information databases - in particular
netdot - could/should be structured to meet these needs; and D) describe
the University of Michigan's current effort and thoughts along these lines
as a basis on which to start the discussion.
Introduction
============
Networking technology has become increasingly complex as networks have
evolved; thanks to VLANs, NAT, MPLS, TRILL, load balancing, Q-in-Q, IP
Anycast, multicast, and other virtualizations and abstractions, there is
no longer any direct congruency between network topologies at ISO layers
1-3. The distinction between routers and switches is murky; routing
protocols are carrying more information than just routes; Software-Defined
Networking allows end-users to build their own virtual networks; private
and public clouds blur the mapping between a "network" and a "customer";
virtual servers no longer have a fixed location, making troubleshooting
challenging at best.
Network information databases are needed to keep track of all of the bits
and pieces that "keep the trains running on time" - information spanning
the gamut from "layer 0" (physical location, power sources, conduit runs,
etc.) through layers 8 ("administrative domains" - VRFs, ASNs, etc.) and
9 (people - local network/desktop/server administrators, security and
business contacts, etc.) along with the traditional ISO layers 1-3 that
network operators are accustomed to thinking about.
Ideally a network information database should have the ability to:
A) incorporate sanity checks to identify conflicts such as overlapping or
duplicate IP subnet assignments, duplicate VLAN IDs for different networks
on the same switch, or OSPF area or IS-IS level mismatches on inter-router
links; B) discover network topology at layers 1-3 through SNMP or other
queries to network hardware; C) generate and/or audit/verify device
configurations for hardware from any vendor; D) audit/verify network
topology at layers 1-3; E) have the flexibility to embrace new networking
technologies as they arise without requiring a complete redesign; F) be
open-source to allow for user-driven fixes and improvements and low-cost
adoption.
We at the University of Michigan - like many other organizations - have
been struggling with the problem of increasing complexity in our network.
To that end we are working toward a replacement for our home-grown network
information database which is now 10 years old; we have selected netdot
from the University of Oregon - largely developed by Carlos Vicente - as
the framework on which to build.
In the course of this work we have found a number of design decisions in
netdot that (as with our old database) limit our ability to document our
actual network. Most obvious among these are the identity between "network"
and "VLAN" - netdot has no explicit "network" object - and the subsequent
restriction that VLAN IDs must be unique. In our environment we have:
Dozens of networks which aren't VLANs - for example point-to-point
WAN links.
Hundreds of distinct networks with identical VLAN IDs - for example
each of our 100+ per-building VoIP networks has VLAN ID 2, and
thousands of wireless access points are on per-building VLANs 9.
Occasional situations where one network has multiple VLAN IDs,
sometimes all on the same switch.
Multiple independent networks using overlapping RFC1918 address
blocks.
Networks (and network hardware) behind firewalls doing NAT/PAT,
such that the IP addresses/subnets known to the core routers do
not match the addresses/subnets configured on the firewalled
equipment.
IP Anycast-based services with the same IPv4 addresses and /32
routes appearing in multiple data centers.
Private cloud networks which can serve dozens or hundreds of
different customers (i.e. departments or services).
Three different routing protocols - OSPF, IS-IS and BGP - in use.
Questions that we would like to be able to ask the database include such
things as:
What customers are affected if cable X is cut or router Y crashes?
Is VLAN Z permitted on all inter-switch trunks that network A
should appear on?
Which OSPF area(s) on which routers does subnet S belong to?
What network(s) are bridged across MPLS pseudowire P or Q-in-Q
tunnel Q?
What should the IS-IS configuration of router R look like? What
should the spanning tree configuration for network N on switch W
look like? What would these be if the devices were Cisco rather
than Juniper?
Which ports on switch W are members of LAG group L and what is the
load-distribution algorithm that it uses?
Which WAN links are members of PPP multilink M on router R?
Who are the security contacts for the hosts on network N? Who is
responsible for IP address assignments on this network?
Underlying all of these is one fundamental question: What is a network?
In the early development of networking there was often a one-to-one relation
between physical and logical components - a network had one router port,
one set of physical switches on which it was carried, served one "customer"
(typically a department), resided in a single building, had one (or none)
VLAN ID, etc. In current network architectures many of these are no longer
true; our current thinking at the University of Michigan is that a network
is a collection of connected objects/entities of multiple types at multiple
layers, loosely modeled on the ISO network model:
Layer "0" - Switches, routers, UPSs, patch panels, cables, etc.
Layer "1" - Physical interfaces and the circuits between them,
virtual interfaces and pseudowire tunnels, etc.
Layer "2" - VLANs, spanning-tree domains, Q-in-Q tunnels, etc.
Layer "3" - IP/IPv6 networks (anyone still using IPX or Appletalk?)
Layer "8" - VRFs, routing domains, ASs, etc.
Layer "9" - Unit LAN admins, security teams, ISPs, etc.
We have had several conversations with Carlos over the past few months to
refine these ideas, and feel that now is the time for us to expose ourselves
to the wider netdot development community.
Database Structure
==================
We feel that a network information database should include the following:
1) A master network table, for which the unique identifier of a network
is its name (i.e. network names must be non-null and unique). A naming
convention may or may not be imposed, as users see fit.
(At UM we use names of the form "<type>-<customer>-<location>-<purpose>",
where one or more elements may be implicit. For example: "V-RESHALL-MJ-AP"
is a VLAN-type network that hosts wireless access points in the Mosher-
Jordan residence hall; "S-333MAYNARD" is a serial (T1) link between our
WAN router and an off-campus router at 333 Maynard St.; "O-LOOP-SEB" is
the Loopback0 network on the r-SEB router; and "DFW-ITS-AL2DC-WEB-PROD01"
is a network behind a data center firewall in the Arbor Lakes 2 data center
which hosts ITS-managed production web servers.)
2) Independent "domain" tables for each layer as described above, with the
idea that each network can be associated with one or more domains of each
layer type. Each domain entry would include a pointer to the network that
it belongs to.
3) "Object" tables for specific entities of each type - routers and
switches, interfaces, VLANs, IPv4 and IPv6 subnets, spanning-tree
instances, etc.
4) Mapping tables that associate each domain with the objects of a more
specific type that belong to that domain - for example each VLAN/device
tuple and each spanning tree instance (root ID and root priority tuple)
would be a member of a Layer 2 domain, while our security group would be
a "layer 9" entity.
Independent of the above structure, we intend to run two parallel database
instances, one which contains human-entered data - i.e what we think the
network should be - and the other holding "discovered" data from SNMP or
other queries - i.e. what the network actually is. Additional processes
would then run periodically or on demand to identify any discrepancies
between the two.
The rationale is that humans - both net admins and programmers - make
mistakes; we don't trust all of the data entered in the database to be
correct, and we don't trust device configurations to be correct. Thus we
don't want to automatically push configurations from the database to the
hardware nor update the database automatically from the configurations.
Current Work at the University of Michigan
==========================================
Our first efforts along these lines have focused on layer 2. In the
accompanying diagrams you can see 1) a real-world example where we had
to have multiple VLAN IDs for one network; 2) an idealized drawing of a
(not ideal!) "pathological" layer 2 configuration; 3) a proposal/example
of a table structure that can represent this pathological network.
1) Real-world example: Dental School. The Dental School network had
well over 1000 devices on several IP subnets on dozens of old non-VLAN-
aware switches; when the first firewalls were installed they were set up
as layer 2 devices, since firewalls don't support secondary IP subnets
on an interface. The firewall should isolate devices on different subnets
at layer 3 (since inter-subnet traffic should pass through the firewall to
reach the router), but it is trivial to configure most computers to recognize
multiple subnets as local and thus bypass the firewall for internal traffic.
The Dental School received funding for a complete network overhaul - Cat5e
wiring, new (VLAN-aware) switches with 10GE uplinks from the building
distribution switches, 10GE links to the campus backbone, and new high-
performance firewalls. To meet their security needs under HIPAA we had
to isolate their internal networks at layer 2 as well as 3. However this
upgrade had to be non-disruptive as clinical activity and instruction take
place year-round; it simply wasn't possible to do a forklift upgrade of the
entire network over one weekend.
To solve this problem we needed a transitional architecture that would
at minimum provide layer 3 isolation, allow VLAN-aware and non-VLAN-aware
switches to coexist, and allow for incremental migration of end devices
from a shared VLAN to separate VLANs without requiring firewall config
changes for each move. The (ugly!) solution was to retain the original
shared VLAN, add new per-service (and per-subnet) VLANs, and bridge these
all together in a single layer 2 domain. As each access switch was replaced,
the end devices would all initially be placed in the shared VLAN; as time
permitted the local admins would identify what subnet each device belonged
on and then change its switch port's VLAN assignment. Once all devices in
a subnet had been migrated off the old VLAN, the bridging "kludge" link
for that subnet/VLAN was removed. The overall migration took nearly two
years to complete.
The "Dental_Firewall_Transition" drawing shows the initial, final, and
transitional configuration of the Dental School network.
2) Pathological VLANs. The "Pathological_VLANs" drawing shows somewhat
simplified examples of several different layer 2 topologies that we have
encountered or expect to in the future. This includes cases where a
network can have multiple VLAN IDs on the same device (as in the above
Dental School example), where different networks can have the same VLAN ID
on different devices, and where a VLAN is tunneled through a device which
itself isn't aware of that VLAN's existence.
3) Table Structure. This drawing shows the proposed new "L2_DOMAIN" table
along with some of the changes needed in other netdot tables; the starred
columns indicate the primary key for each table.
Not shown in thse drawings are examples of other possible L2 domain types,
such as point-to-point ethernet, point-to-point WAN links, ATM PVCs and
SVCs, or non-broadcast multiple-access (NBMA) networks such as frame relay
or ATM LAN emulation.
In this structure there is no independent "VLAN" table; there are only
instances of VLANs on devices, and the unique VLAN ID constraint becomes a
unique VLAN ID/device tuple constraint - in other words different networks
can use the same VLAN ID on different devices, but no single device can have
two networks with the same VLAN ID. (In this context, multiple virtual
switches on a physical device would be treated as independent devices.)
At this point our proposed new netdot structure does the following:
A) Replaces the VLAN table with a NETWORK table, with the constraint that
no two networks can have the same name.
B) Adds several "Layer X Domain" tables to map VLANs, IP subnets, user
groups, devices, etc., to the networks that use them; for example the
L2DOMAIN table maps Layer 2 (broadcast) domains to networks.
C) Creates a new VLANDEVICE table to map VLAN IDs to the devices (switches)
that they are present on and to the L2 domain that each of these belongs
to, and to hold per-device, per-VLAN spanning tree information (e.g. the
STP bridge ID and priority).
D) Shuffles some STP information among the INTERFACEVLAN, VLANDEVICE and
STPINSTANCE tables to eliminate duplication of per-device or per-STP
instance information in various entries.
E) Updates a few other tables as well.
For a more complete description of the modified tables, see the attached
spreadsheet.
There is still substantial work needed for the other layers of abstraction;
for that matter there's plenty more work to be done at layer 2. Thoughts
and comments from the netdot community would be welcome!
For example: The concept of "VLAN Groups" defined as specific ranges of VLAN
IDs is useless for us; we tried defining set ranges for specific purposes
long ago, but quickly ran into situations where we had to break the rules.
Does anyone else use these as currently defined? Should these be updated,
eliminated, or left as is?
-- Kurt Hillig, 28 March 2013
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Dental_School_Network_Transition.pdf
Type: application/pdf
Size: 235747 bytes
Desc: not available
Url :
http://osl.uoregon.edu/pipermail/netdot-devel/attachments/20130328/ef4233fa/attachment.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pathological_VLANs.pdf
Type: application/pdf
Size: 64822 bytes
Desc: not available
Url :
http://osl.uoregon.edu/pipermail/netdot-devel/attachments/20130328/ef4233fa/attachment-0001.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pathological_VLAN_Table_Structure.pdf
Type: application/pdf
Size: 534281 bytes
Desc: not available
Url :
http://osl.uoregon.edu/pipermail/netdot-devel/attachments/20130328/ef4233fa/attachment-0002.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Summary_of_Netdot_Schema_Changes.pdf
Type: application/pdf
Size: 51489 bytes
Desc: not available
Url :
http://osl.uoregon.edu/pipermail/netdot-devel/attachments/20130328/ef4233fa/attachment-0003.pdf
------------------------------
_______________________________________________
Netdot-devel mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-devel
End of Netdot-devel Digest, Vol 72, Issue 8
*******************************************
