Workflow for importing IPs, devices, and interfaces

[Brian Candler]

I'd just like to outline the task I'm doing at the moment, and some limitations it has revealed in the UI - then perhaps we can come up with some ideas for improving this.

What I've done so far is:

1. Import all IP addresses. This was pretty straightforward.

2. I'm in the process of importing devices. This is also pretty straightforward, although I'm unable to import Comments/Status (#853) or custom fields (#568)

3. Where it becomes very cumbersome is in linking devices to IP addresses via interfaces.

Here's an example. I've imported a device "ix-asa1" which is a firewall. It has multiple physical interfaces:

GigabitEthernet1/1

GigabitEthernet1/2

GigabitEthernet1/3

But most of the IP addresses are associated with virtual (vlan) subinterfaces:

GigabitEthernet1/3.112

GigabitEthernet1/3.254

GigabitEthernet1/3.255

... etc

(Note: I hadn't pre-created any interfaces on the device type template - but even if I had, all these virtual interfaces would need creating anyway)

There are two ways I could tried to add these relationships in the GUI, but neither works.

(1) I go to the Device, and I click add Interface, and then I try to associate the interface with an IP address. But this attempts to create a duplicate IP address, rather than linking to the already-created one. (#786)

(2) I go to the IP Address, and try to associate it it with a Device and Interface. But this only allows me to associate it with an interface which already exists on a device; there is no option to create a new interface here.

So the workflow has to go in two phases:

- Firstly, work out all the interfaces and IP addresses I want to add. Navigate to the device, and add the interfaces. (Can add multiple interfaces in bulk via the Django admin page)

- Secondly, navigate to each IP Address in turn. Attach each one to the correct device and interface.

This process is very tedious.

Looking through the Netbox GUI, what Netbox wants me to have done is to import the devices first, *then* import the IP Addresses; the import of IP Addresses would also create interfaces for me. Unfortunately I didn't do it in that order.  That's an argument that I should throw away my existing work and start again :-(

So although I'm going to go ahead with this now, I wonder what a better process might be. Here are a few ideas:

* When you navigate to Device, and create an Interface, have an option to attach it to an existing IP address (already requested as #786)

* Conversely: when you navigate to IP Address, and request to attach it to a Device/Interface, have an option to create a *new* interface instead of using an existing interface (no ticket yet, but I will do if this is considered a good idea)

* Have some way to bulk-import interfaces linked to Device and IP Address.  This would be a table of Device,Interface Name,VRF,IP Address (+ other fields). The existing bulk import of 'IP Address' would work here, if it were able to attach to an existing IP Address object rather than always create new ones.

The rule would probably be: if the IP address already exists, then update its attributes. Also attach it to the given Device/Interface. If there is no such interface, then create that interface.

* Maybe the relationship between device<->interface<->IP address would be better represented via something like JSON rather than CSV?

Anyway, interested to hear what people think.

Cheers,  Brian Candler.

[Brian Candler]

> Looking through the Netbox GUI, what Netbox wants me to have done is to import the devices first, *then* import the IP Addresses; the import of IP Addresses would also create interfaces for me.

Actually, no it doesn't - it just tells me that the interface is invalid, if it doesn't already exist.

(I was hoping I could just export all my existing IPs, update them to point to device/interface, delete them and re-import them)

So the wishlist items now are:

1. Create interfaces automatically when doing an IP Address import - although this would require extra fields for the Interface if it doesn't already exist.

2. Allow the IP address import to *update* existing IP addresses if they already exist

and/or have an explicit way to import interfaces, or devices with their interfaces.

It looks like I may simply do direct SQL updates instead now.

[Brian Candler]

> 2. Allow the IP address import to *update* existing IP addresses if they already exist

Oops, that won't work: one interface can have multiple IP addresses associated with it.

[Jeremy Stretch]

The creation of interfaces and IP addresses have always been two discrete operations, because neither one depends on the other (you can have interfaces without IPs and vice versa). The recommended workflow is:

1. Create device types to represent the devices you're going to create. These serve as templates allowing for the automatic creation of interfaces and other components. These should match how a device appears in the real world.

2. Create the desired devices. Interfaces will be created automatically.

3. You may want to add extra interfaces that weren't specified by the device type (e.g. SVIs or other virtual subinterfaces). This can be done in bulk by selecting the desired devices, and selecting "Add Components > Interfaces" at the bottom of the device list. Interfaces can be specified as a set, range, or combination thereof. For example, `GigabitEthernet1/3.[112,254,255]` will create three interfaces. It's possible to add an arbitrary set of interfaces to an arbitrary set of devices in a single action (with the caveat that the interfaces must be of the same type).

4. IP addresses can then be imported and assigned to *existing* interfaces in bulk.

Interfaces cannot be created via IP assignment because NetBox needs to know the form factor and other information to create each interface. While we could theoretically enable this by adding the required fields, I'd much rather keep interface creation as a separate, discrete process to avoid confusion and simplify validation. NetBox doesn't currently support the bulk import of interfaces, but a feature request (#822) was recently opened for this.

As for your situation, you've hit a wall because you've already imported all your IPs, and then created the devices. You should be able to export, delete, and then re-import the IPs, this time including the interface assignments. Would that work? (I realize that a bulk assignment feature would help, but I'm not sure how that would work.)

Jeremy

On Mon, Jan 30, 2017 at 10:57 AM, Brian Candler <b.ca...@pobox.com> wrote:

> 2. Allow the IP address import to *update* existing IP addresses if they already exist

Oops, that won't work: one interface can have multiple IP addresses associated with it.

--
You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to netbox-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/512a175c-41e4-422d-963e-7b3c9189a696%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Brian Candler]

On Monday, 30 January 2017 16:18:54 UTC, Jeremy Stretch wrote:

As for your situation, you've hit a wall because you've already imported all your IPs, and then created the devices. You should be able to export, delete, and then re-import the IPs, this time including the interface assignments. Would that work? (I realize that a bulk assignment feature would help, but I'm not sure how that would work.)

I'm working along a similar path now.

* I have all the IPs exported via CSV

* I'm currently adding device and interface names to this spreadsheet

* I'll create the necessary interfaces from this same data (which it seems I can only realistically do via SQL import. I will just default the form factor)

* I could then delete and re-create the IP addresses; but it may be cleaner just to update the existing IP address records via SQL to point to these new interfaces

Thanks,

Brian.