Virtual Chassis Management IP Assignment & Device Names

[packe1bb]

My apologies if this is the wrong location for this, or if I am not following proper etiquette or something (first time posting in a repository :/ ). Hopefully this is a simple enough question, but oddly I could not find a related post about this which makes me believe there is a way to do it that I am just unaware of and its probably a noob question.

How have you all been modeling switch stacks and assigning management IPs to them, and then referencing devices in automation tasks? Currently, I cannot seem to find a way to assign a management IP to a virtual chassis (which was the most intuitive way I could see to model a switch stack). IP addresses and names assigned to devices also have to be unique from my understanding. I have hundreds of devices with serial numbers and asset tags for automated inventory tracking/auditing purposes, but then I also need to be able to run AWX tasks on the Netbox inventory for automation initiatives, and I would like to do so with as little complexity and logic having to be handled within the playbook itself.

I was considering using the "Master" switch and have the management IPs assigned there... but the problem I foresee is then when looping through the inventory there will be devices without an IP address. Not to mention I would have to crack a whip to make sure if that "Master" switch got replaced or whatever that IPs have been reassigned or updated. Just seems like there should be a simple way of doing this so I can use the Netbox inventory for automation tasks, but also have it be useful for inventory tracking of individual assets... any thoughts?

[DanSheps]

I currently do this for our switch stacks:

1. Master has a management IP
2. Members have no management IP
3. Make sure master is assigned to every chassis
4. Look at devices, filter on vc_master_for (I think that is the field, it is the reverse of the master field on the VC model). I don't believe there is a corresponding web/api filter but this could be something we could look at adding in a later release if there is enough desire for it.

[packe1bb]

That was my thought, but I got hung up on how I would parse out the VC and single switches from things like expansion modules, PSUs, etc. You put me on the right path though and I have found the following that looks promising and I am going to test with against your suggestion:

https://docs.ansible.com/ansible/latest/collections/netbox/netbox/nb_inventory_inventory.html

has_primary_ip is a useful way to filter out patch panels and other passive devices

[DanSheps]

Well, I use only Cisco, so... Technically every Catalyst is a stack, just a stack of 1 normally.

[DanSheps]

That was my thought, but I got hung up on how I would parse out the VC and single switches from things like expansion modules, PSUs, etc. You put me on the right path though and I have found the following that looks promising and I am going to test with against your suggestion:

I just noticed this. Modules, PSUs, etc should not be modeled as devices

[mtinberg]

This is a great question, we all had to figure this stuff out at some point. The way you think this should work is right, virtual interfaces (vlan, LAG, etc.) and the management IP are associated with the primary switch in the stack, when gathering inventory for automation you can filter on has_primary_ip=True to only see Device records that correspond to managed network devices and not anything else that can be tracked. When you view the primary stack member the UI will query all the stack member interfaces to show a complete list and you can do something similar with nb_lookup filters. I use the Virtual Chassis for grouping but don't use it much when querying, I name the stack members and filter on that, eg primary is switch-01 and members are switch-01:2 ... so I can query '/dcim/devices/?name__isw=${device_name}' and get all of them without needing to look up the vc then query filtered on that. As far as replacments, that is more tricky, I'm not sure the best process for that, if you keep the Device record tied to the individual unit/serial then you'd need to remove it from the VC, rename it, remove the interfaces/ip assignments, reassign the new unit, rename it, and recreate all the virtual interfaces, ip assigments, etc. which could be a bunch depending on the device role. If you cheat and just update the serial number, then you don't quite have a per-device lifecycle record. I wonder if you can PATCH the interface records for virtual interfaces (vlan, lag, etc.) and reassign them to the new device. Either way a custom script or external script using the API would be best to make all the changes needed reliably and not make an engineer manually try and keep it straight, invariably they will be interrupted and lose track of something leading to failures down the road. Script is more reliable than whip 8-)

…

--- plugin: netbox.netbox.nb_inventory # Using NETBOX_API and NETBOX_TOKEN environment variables by default # ANSIBLE_HOST_KEY_AUTO_ADD=true and ANSIBLE_NETWORK_IMPORT_MODULES=yes # are also useful environment variables to set along with # ANSIBLE_LOG_PATH=~/ansible.log and ANSIBLE_PERSISTENT_LOG_MESSAGES=true # when testing #uncomment api_endpoint and token for vagrant #api_endpoint: http://netbox #token: 0123456789abcdef0123456789abcdef01234567 #validate_certs: False config_context: True interfaces: False # Slow OpenAPI generation (fixed with caching in 3.x) timeout: 300 # fetch_all: no # max_uri_length: 1000 group_by: - sites - device_roles - device_types - tags - platforms query_filters: - has_primary_ip: True - status: "active" — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

________________________________ From: packe1bb ***@***.***> Sent: Wednesday, January 5, 2022 8:34 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: [netbox-community/netbox] Virtual Chassis Management IP Assignment & Device Names (Discussion #8242) My apologies if this is the wrong location for this, or if I am not following proper etiquette or something (first time posting in a repository :/ ). Hopefully this is a simple enough question, but oddly I could not find a related post about this which makes me believe there is a way to do it that I am just unaware of and its probably a noob question. How have you all been modeling switch stacks and assigning management IPs to them, and then referencing devices in automation tasks? Currently, I cannot seem to find a way to assign a management IP to a virtual chassis (which was the most intuitive way I could see to model a switch stack). IP addresses and names assigned to devices also have to be unique from my understanding. I have hundreds of devices with serial numbers and asset tags for automated inventory tracking/auditing purposes, but then I also need to be able to run AWX tasks on the Netbox inventory for automation initiatives, and I would like to do so with as little complexity and logic having to be handled within the playbook itself. I was considering using the "Master" switch and have the management IPs assigned there... but the problem I foresee is then when looping through the inventory there will be devices without an IP address. Not to mention I would have to crack a whip to make sure if that "Master" switch got replaced or whatever that IPs have been reassigned or updated. Just seems like there should be a simple way of doing this so I can use the Netbox inventory for automation tasks, but also have it be useful for inventory tracking of individual assets... any thoughts? — Reply to this email directly, view it on GitHub<#8242>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM654FFRQESV2GJ3YTLUURJIVANCNFSM5LKBXSEQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[packe1bb]

It is nice to see another Higher Ed network professional doing this stuff! I am the only one that has any real SDN/NetDev experience so I am the one who would be writing all the scripts and what not which is not an issue... but getting the old timers to actually remember to run the things they need to run is where the whip comes in handy for my (Central Michigan University - OIT - Network Services) team 🤣

When I came on they were all using notepad text files as golden configs for copy pasting and what not cause that is the way they have always done it :cringe:.... immediately got to work replacing that with Netmiko scripts, but am now looking to advance that even further and implement RBAC with AWX and consolidate the dozen or so distributed systems that are used as different sources of truth into one system (Netbox).

Anywho, thanks for the input, I like that idea and think I was getting hung up on imaginary problems of keeping the device names in Netbox the exact same as the hostnames on the switches themselves which is not really necessary so long as I can tell what is what in the code 😜

[mtinberg]

I think it's easier if the primary device and vc name matches the DNS name, so you can set hostname {{ inventory_hostname }}​ and while nb_inventory will use the associated IP to connect (which will always be there if filtering on has_primary_ip) Ansible can fall back to doing a DNS lookup if you have a very impoverished inventory. It's also easy for external tools to link to /dcim/devices/?name=${device_name}​ (or name__isw) for navigating between them. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: packe1bb ***@***.***> Sent: Wednesday, January 5, 2022 11:09 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Virtual Chassis Management IP Assignment & Device Names (Discussion #8242) It is nice to see another Higher Ed network professional doing this stuff! I am the only one that has any real SDN/NetDev experience so I am the one who would be writing all the scripts and what not which is not an issue... but getting the old timers to actually remember to run the things they need to run is where the whip comes in handy for my (Central Michigan University - OIT - Network Services) team 🤣 When I came on they were all using notepad text files as golden configs for copy pasting and what not cause that is the way they have always done it :cringe:.... immediately got to work replacing that with Netmiko scripts, but am now looking to advance that even further and implement RBAC with AWX and consolidate the dozen or so distributed systems that are used as different sources of truth into one system (Netbox). Anywho, thanks for the input, I like that idea and think I was getting hung up on imaginary problems of keeping the device names in Netbox the exact same as the hostnames on the switches themselves which is not really necessary so long as I can tell what is what in the code 😜 — Reply to this email directly, view it on GitHub<#8242 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM2PPUNUHD2N3XKJETTUUR3NVANCNFSM5LKBXSEQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>