Is there a sane reason why ACI Node numbers max out at 4000?

[RedNectar]

Hi all,

Just wondering....

Is there a sane reason why node numbers in ACI max out at the number 4000?

Now I understand working with processors where every bit counts (yes, I did write machine code for the 8 bit Z80 at one time in my life)

But last time I looked, it was the 21st century, and all ACI configuration is processed as text anyway.

I mean, is ACI so restricted that there is a 12bit register somewhere that stores the node id (12 bit because 2^12=4096).  And even if there is, why 4000? Why not 4095?

Or did someone one day think "You know, one day we might want to map this node ID to a VLAN - so we better make sure the node ID max out at 4000"

Or indeed, is there an actual use case where that happens - in which case I'd be glad to be enlightened of such a case.

The problem

You see, when trying to come up with a site/node numbering strategy, it would be REALLY nice to say:

Number you nodes according to the following rule:

<1 digit-site-id><3 digit switch id>

Which actually works well for up to 3 sites - or 4 if you allow 0 as the main site id. Now i do know that with multi-site you can use the same node IDs at each site, but it  would be nice to have the choice to avoid it until at least there are 10 sites.

And even then - why stop at 4 digits...

What about the digit switch id>? 

The logical extension of this scheme might be to divide the 3 digit switch-id into

100-199 - Spine IDs

200-299 - Local Leaf IDs

300-399 - Remote Leaf IDs

400-499 - <Shudder> Level 2 node IDs [Not a big fan of Level 2 nodes]

500-999 - Future

or some other logical pattern.

Now I'm sure I'm not the first to come up with this scheme or something similar, and we have ALL struggled to understand why Cisco has inflicted this pain on their customers.

For me - I just want to be able to tell customers

"There's a really good reason for restricting node IDs to 4000, and once you understand, you'll be happy to put up with the pain it causes you."

BUT until I know that reason, I have to say

"I can only imagine that someone was having a really bad day when they made that design decision, and didn't stop to think of the inconvenience it would cause customers"

[Sergiu.Daniluk]

Interesting observations as always.

My guess: the UI developers do not have a networking background, so when they get free hand to implement some objects' attributes, they do not have a network design in mind. For example: you are a developer and you are told "current supported numbers of leafs is 400, but make the range available for future expansion", probably you'll simply add a 0 at the end of that 400 and voilà.

I am also pretty sure the node_id is not restricted to bits (probably Angular used UI), so making the limit 4095 looks kinda silly if you ask me.

[Robert Burns · Accepted solution]

It's an arbitrary limit.  The object model can support >16K nodeIds (16*1024), but for reasons likely decided on almost 10 years ago, 4000 was decided to be the enforced limit.  I'd guess they were more concerned about accommodating scale rather than flexibility in a numbering convention.  This leaves the door open where the limitation could be increased with limited impact/concern (since the model is built to support it), but we'd also probably need to hear more customers asking for this before it would be considered.

Robert   

[RedNectar]

Hi @Robert Burns ,

Thanks for the reply. At least it gives me an alternative reply to the query.  Such a pity there is no "User community feedback portal" site like there is for Webex. https://blog.webex.com/team-collaboration/make-your-voice-heard-with-the-user-community-feedback-portal/

[Robert Burns]

There's no community-feedback, but there is the UI feedback button - this is closely monitoring by engineering. I promise it doesn't just land in the bin! (I agree the crowd sourcing feedback is a better option though)

Robert