Grouping network devices together - best approach for Cisco DCNM and VPC?

[tfboy]

I'm not sure how best to go about this.

I have a Cisco Nexus network infratsructure in a spine/leaf model where the leafs are always used in pairs: a server might have two NIC connections, one going back to Leaf 01 and another to Leaf 02. Those then might be put together as a LAG, etc.

Historically, we've had stacked switches. In this case, using the Virtual Chassis function in Netbox makes a lot of sense. Each interface has its stack number in the interface name making them unique (gi1/1 on switch 1 and gi2/1 on switch 2 for example).

However, in our new network infrastructure, this doesn't really work. All devices have their interfaces identified as "Ethernet 1/x". The "1" is constant, so a virtual chassis model doesn't really work as we end up with two lots of "Ethernet 1/x".

I could rename the first number on the second device so it's unique (Ethernet 2/x) but this then doesn't make sense when configuring at low level because in Cisco / DCNM / CLI world, it remains Ethernet 1/x.

I guess this would also break Napalm integration (I haven't had the chance to test) as the interface names wouldn't match.

So in this case, I think the concept of Virtual Chassis isn't really appropriate.

I could look at the "module" model, I haven't yet, not sure if this could be an alternative that works?

So my question is for those with similar network setups, have you find a way of logically grouping devices together in pairs or more without breaking the core interface names and Napalm integration?

Thoughts?

TIA :)

[jcollie]

Cisco VPCs are a pretty loose coupling so I agree that virtual chassis are not appropriate. I don't think that modules or even devices bays are appropriate either since the switches remain separate, only connected by cables. I just keep my Nexus switches as separate devices and the person behind the keyboard needs to keep track of the pairings. That's easy enough for me as I only have two sets. Anything more than that I think that you'd need to look at custom fields - add a device object custom field called "vpc_peer" or something like that. If you really wanted to get fancy you could create a plugin for managing the relationships but that's beyond my meager programming skills.

[bluikko]

I too keep them as separate devices. Unfortunately then there is no way to properly model MCLAG interfaces.

[mtinberg]

For vpc pairs I just use Clusters to associate them together, it's vdc that that require a little more thought. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Jeffrey C. Ollie ***@***.***> Sent: Monday, October 17, 2022 9:16:53 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] Grouping network devices together - best approach for Cisco DCNM and VPC? (Discussion #10662) Cisco VPCs are a pretty loose coupling so I agree that virtual chassis are not appropriate. I don't think that modules or even devices bays are appropriate either since the switches remain separate, only connected by cables. I just keep my Nexus switches as separate devices and the person behind the keyboard needs to keep track of the pairings. That's easy enough for me as I only have two sets. Anything more than that I think that you'd need to look at custom fields - add a device object custom field called "vpc_peer" or something like that. If you really wanted to get fancy you could create a plugin for managing the relationships but that's beyond my meager programming skills. — Reply to this email directly, view it on GitHub<#10662 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM4B2N4OPTD362L4ZGTWDVNVLANCNFSM6AAAAAARGZZEKA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mtinberg]

Yeah, MLAG just gets modeled as a single-port Port-channel on each member device, your config writing tools need to have the smarts to work out the cluster membership and push changes into the LAG interface record on both devices. Config tools which read the database to render config for each individual device can do the right thing without more detailed modeling. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: bluikko ***@***.***> Sent: Monday, October 24, 2022 1:13 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Grouping network devices together - best approach for Cisco DCNM and VPC? (Discussion #10662) I too keep them as separate devices. Unfortunately then there is no way to properly model MCLAG interfaces. — Reply to this email directly, view it on GitHub<#10662 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM55AV4JHRN64DGRYODWEYSJJANCNFSM6AAAAAARGZZEKA>. You are receiving this because you commented.Message ID: ***@***.***>

[bluikko]

Interesting idea to use Clusters for vPC pairs. I assume you mean Virtualization -> Clusters for it?
Then I guess VPC domain ID and port VPC IDs are custom fields?

Many vendors have different kind of MCLAG features and it would be nice if there was some support for generic MCLAG.

[mtinberg]

In my case I'm in a brownfield situation, so we have an existing numbering system for HA groups and my "Network"-Group Virtualization->Clusters names are just the number used for vPC (which is a string type but can be converted to a number in a new field using django .annotate when using custom Scripts and Reports) As far as adding support for MCLAG, I'm not sure what database relations you specifically want for MCLAG that are generic across vendors. I'm not a Netbox developer but I'm always leery of adding too much detail to the base system that makes it unwieldy for vast number of small deployments, custom_fields, tags and config_contexts are pretty powerful, escpecially custom object relations, so each site with more complex needs can straightforwardly extend the base data model to cover what their automation needs. If a particular set of custom fields or relations become common, then maybe it makes sense to add it the base data model, but I think custom_fields should do the heavy lifting in most cases. For vPC you could probably write a custom audit Report or Script that looks up the two Device records and their Interfaces that are in a Cluster pair and compare the fields of their Port-channel interfaces, or push settings to both of them, with a few well-written Django ORM filters and matching by name, without there being an explicit DB relationship, although you could use this in a Script to add a custom object relation between the two Port-channel interfaces so later queries could easily pair them up. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: bluikko ***@***.***> Sent: Monday, October 24, 2022 8:33 PM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Grouping network devices together - best approach for Cisco DCNM and VPC? (Discussion #10662) Interesting idea to use Clusters for vPC pairs. I assume you mean Virtualization -> Clusters for it? Then I guess VPC domain ID and port VPC IDs are custom fields? Many vendors have different kind of MCLAG features and it would be nice if there was some support for generic MCLAG. — Reply to this email directly, view it on GitHub<#10662 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM52YYDSLIX5WGKRKHLWE42IJANCNFSM6AAAAAARGZZEKA>. You are receiving this because you commented.Message ID: ***@***.***>