Initial ACI configuration without spine switches

[Alex Moore]

We have placed an order for some ACI equipment (APIC cluster, spine switches, and leaf switches), however the lead-time for the spine switches is significantly longer than we were anticipating.

Could anyone confirm whether it will be possible (and reasonable) for us to perform the initial configuration of the fabric once the APIC cluster and leaf switches have arrived, but while we continue to wait for the spine switches - in other words, will we be able to prepare the complete configuration while the APIC cluster is just connected to a single leaf switch, with no spines physically present? Or is that not possible / are there likely to be things we can't do config-wise until the spines are in place?

I'm trying to understand the likely impact to the overall timeline of the associated project due to the long ETA for the spines...

Thanks in advance!

Alex

[RedNectar]

Hi @Alex Moore ,

You won't be able to complete the initial discovery without at least one Spine.

To prepare for the initial configuration, I'd suggest that you give the APIC simulator a shot. https://www.cisco.com/c/en/us/products/cloud-systems-management/application-centric-infrastructure-simulator/index.html

If you are going to try the simulator, keep this in mind:

• Do NOT change any of the default values during setup EXCEPT the OOB management IP addresses and gateway
• Make sure you allocate the required 12 vCPUs and 24GB RAM - make this 16vCPUs (I allocated 20) if you want to run with 2 spines and 3 APICs
• If you want to run with 2 spines and 3 APICs (rather than the default 1 Spine 1 APIC) you'll get about 3 mins to make your choice when the VM FINALLY boots up for the first time - if you miss the question, it will automatically use a single Spine, Single APIC model

I hope this helps.

---

Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem.

---

[Alex Moore]

Thanks for the response.

I did have a brief look at the APIC simulator a while ago, and while it's better than nothing, it's seems like it would still be somewhat limiting. For example I imagine we wouldn't be able to do much by way of verification that our configuration does what we intend (ie connecting a few real systems and testing certain scenarios). And it means we wouldn't be configuring our real APIC cluster yet (even though we'll receive that in a reasonable timeframe), so we'd still have to transfer that configuration across to the real APIC cluster after the real spines finally arrive.

One other thought that I came up with was the possibility of sourcing a 2nd-hand previous-gen spine switch... eg the 9336PQ. It looks like that supports 14.x ACI releases (not sure about 15.x). Presumably connecting one of those temporarily would allow us to work on most/all of the config on the real APIC cluster, and then when the intended spine switches eventually show up, we can just connect them to the fabric, and remove the 9336PQ, with very little extra configuration work required at that stage. I guess there might be some functionality missing from the older platform, which could result in some limitations in what we can do config-wise, but I assume we'd at least be able to get most of the config in place, and tested. Does that sound like a viable approach?

[RedNectar · Accepted solution]

Hi @Alex Moore ,

I did have a brief look at the APIC simulator a while ago, and while it's better than nothing, it's seems like it would still be somewhat limiting.

Correct

For example I imagine we wouldn't be able to do much by way of verification that our configuration does what we intend (ie connecting a few real systems and testing certain scenarios).

Correct again

And it means we wouldn't be configuring our real APIC cluster yet (even though we'll receive that in a reasonable timeframe), so we'd still have to transfer that configuration across to the real APIC cluster after the real spines finally arrive.

And 3 times correct. BUT... you could:

• Work out a naming scheme that you are happy with
• Get your Access Policy Chains planned and with standard naming - these can be saved and transferred to a real system later, although without scripting is a lot of work

One other thought that I came up with was the possibility of sourcing a 2nd-hand previous-gen spine switch... eg the 9336PQ. It looks like that supports 14.x ACI releases

It does

(not sure about 15.x).

It doesn't

Presumably connecting one of those temporarily would allow us to work on most/all of the config on the real APIC cluster, and then when the intended spine switches eventually show up, we can just connect them to the fabric, and remove the 9336PQ, with very little extra configuration work required at that stage. 

If you can do this - this would certainly be the way to go. There is almost NO configuration for the spine, and I'd be 99% confidnet that your spine running 14.1 code would work fine with your leaf switches running 15.x except for IPN/ISN configurations in multi-pod/multi-site

I guess there might be some functionality missing from the older platform, which could result in some limitations in what we can do config-wise, but I assume we'd at least be able to get most of the config in place, and tested. Does that sound like a viable approach?

Definately viable

[Alex Moore]

Thanks a lot for the advice - for the record we did take the route of getting the second-hand 9336PQ, and it has proven to be sufficient to progress with configuration and testing in advance of the "real" spines turning up.