Device "Domains"

[netdisco-automation]

Use the VTP Domain or another field to assign devices to zones or domains of some kind.

Use this information either globally in searches etc (using drop-down selector in navbar) or simply to filter the layer 2 netmap image.

Reported by: ollyg

Original Ticket: netdisco/nd2-features/1

[netdisco-automation]

• labels: --> Wishlist
• Milestone: -->

Original comment by: ollyg

[netdisco-automation]

• Status: open --> new

Original comment by: ollyg

[netdisco-automation]

I like the concept of "Domains" as an arbitrary identifier of administrative control. I do not like the idea of using VTP Domain as it is vendor specific. I think the "Domain" should be a user specified field not necessarily tied to any data returned from a device and independent of IP addressing to support overlapping address space.

Original comment by: jeneric-placeholder

[netdisco-automation]

I have a feeling that being able to add an arbitrary list of tags to a device would be the way to go. That way you can easily create logical views - with some devices appearing in multiple views. For what I have in mind for our network (but not decided yet), filtering by VLAN ID in combination with this would be great.

If I describe "my" network it'll probably be clearer - but bear in mind this is one of those "if I were starting from scratch I'd do it differently" setups.

At our main office we have an internet connection presented as IP packets on an ethernet port (it's fibre back to the ISPs POP). This goes into a switch (I'll call it "I"), and from that we have two border routers (main and backup, RB).

On the inside of the routers we have another switch (FE), then a firewall (F), then another bunch of switches (Fn) - with a load of public facing servers hung off this front end network. A number of customers, and some systems that for performance reasons can't be behind the firewall, are attached to FE.

Then we have a backend network which is just a bunch of switches (Bn). And we have our office network (bunch of switches On) which is connected to FE and Bn with a 3 port router (RO).

At present, the frontend and backend switches (FE, Fn, Bn) aren't connected to other networks. On the backend they share the same IP space as the server backend connections, and on the frontend we have a separate subnet (so it's a shared subnet) for stuff like this. The office switches are on the office subnet.

To avoid the complications of routing etc, I've configured switch I with two VLANs, one for the internet traffic, one for management - for expediency it's currently on the office LAN/subnet.

And stuff that's coming up :
Well to start with, we have a standalone ADSL circuit (8M/800k) that's primarily used for guest WiFi. That's getting upgraded to FTTC (a VDSL service in the UK, we should get something like 60M/16M), and we'll be wanting to shunt our office traffic onto that. That means connecting the FTTC circuit into the network and adding an extra port on the office router. I'm thinking the logical way to do this is to add another VLAN to switch I and trunk it into the office router (RO).
I'll also need another interface on the office router for the guest WiFi - so another VLAN that will also need to be trunked out on the office physical connection to switches in another office down the corridor.

And potentially we may be getting an additional main internet connection. Our provider tells us that they cannot upgrade the current circuit, and they also can't port our public IPs to a new circuit. So we'd need to put a new circuit in and parallel run while we migrate everything to new IPs - good game, good game !

Once I'm trunking VLANs about, I think it then makes sense to have a separate management VLAN for all the switches and key network components etc. This means that what is now a simple diagram with switch I as the root and switches FE, Fn, Bn, On interconnected with routers/firewalls suddenly becomes a complicated interconnected mesh !

Just to add to the complication ...
We also manage another site, much simpler but larger. That has VLAN 1 for device management, and we'd have VLAN 1 for device management here - but they wouldn't be connected. Thus just filtering by VLAN wouldn't really work for network diagram purposes.

So what would work for me would be to be able to add arbitrary tags. Eg, I could tag devices I, BR, FE, F, Fn as "Frontend"; tag I, BR, FE, OR, On as "Office"; and so on. Then I could get a functional view of whatever was important to the task in hand.

Original comment by: simonhobson

[netdisco-automation]

Domain / Grouping would help tremendously. For example to be able to group things into Core / Distribution / Access / DataCenter categories but then based on network topology also group them into Clusters or Campus areas.

Some of that can be done by using IP ranges, other -more automated- methods would probably require a significant coding effort (isolate on pure L3 boundaries etc)...

Original comment by: jpvelders

[netdisco-automation]

Use the VTP Domain or another field to assign devices to zones or domains of some kind

To be clear, are you suggesting storing an arbitrary list of tags in the VTP field - or just one tag/switch ? A switch can be in more than one logical view.
Also, would this fail if some of the switches are using VTP - as some of mine are ?

Original comment by: simonhobson

[netdisco-automation]

I originally mentioned VTP domain field as an example of creating device domains.

However no, we would not re-use that field. If we do implement tags, it'd be a separate table with tag and device. An alternative is to have subnet based domains (same as for discover_only type config).

Original comment by: ollyg

[netdisco-automation]

Ticket moved from /p/netdisco/netdisco2/27/

Original comment by: ollyg

[ollyg]

Moved to Wishlist page in wiki