Feature Request - Statically Allocate ASN and Loopback IPs to Border Leafs

[fengwang523]

leaf ASN and Loopback IPs are allocated via the apstra_datacenter_resource_pool_allocation resource; the values are dynamically allocated and re-deploy a blueprint will change these values.

This imposes a major challenge for apstra_datacenter_external_gateway resource which needs to specify the remote border leaf ASN and Loopback IP values.

The feature request is for a resource or some workaround in the terraform code to be able to:

• ASN and IP Pools are still used to assign the values to spine, leaf and access nodes; but on top of this,
• border leaf ASN and Loopback IP can use static values from the resource pools

[chrismarget-j]

Hi Feng,

Thank you for opening this issue.

Have you noticed the new system_attributes attribute in the apstra_datacenter_device_allocation resource?

It's related, but I think not quite exactly what you're looking for.

I don't think Apstra has a way to allocate an element of a resource pool so that it can be re-used through destruction and re-creation of an object.

It sounds to me like the ideal solution would be something along the lines of the AWS elastic IP object, which enables allocation of an IP address from the pool independent of the use of the IP, thereby decoupling the lifecycle of the address from the lifecycle of the object to which it's assigned.

Does it sound like I'm understanding your problem?

[rajagopalans]

This might be a super-simplistic way of doing it, but couldn't we do ranges with single ASNs and then assign them? It would be pretty hard and annoying to do by hand, but with terraform might be a loopable resource

[fengwang523]

first to answer Raj's comment: no it is not possible to create a pool with a single ASN in it and assign to a particular leaf. Apstra's concept is to assign a pool to a fabric role. For the ASN, there are two roles: spine vs leaf.

second for Chris's comment: yes I just noticed the new system_attributes introduced. it sounds to me that it is the solution to address the problem. I could still use an Apstra ASN and IP pools to assign dynamic values to fabric spine and leaf roles, but meanwhile, I can try to use the new system_attributes to hardcode an ASN value and a loopback IP for each border leaf. I'll yet need to update current repo variable definition to accept system_attributes

[steve-hartt]

Unfortunately, it seems system-attributes is only for lo0.0. What about the loopbacks generated within a routing-zone? (i.e., lo0.2)

[chrismarget-j]

Hi @steve-hartt,

Do you want to prescribe the specific addresses used on each leaf switch (system-attributes style), or merely get some address assigned to the per-routing-zone loopback interfaces?

The former can be accomplished by using the routing_zone_id attribute with the apstra_datacenter_resource_pool_allocation resource.

Assigning prescribed IDs isn't something I know how to deal with offhand, but I can look into it.

edit: Per Apstra product management, setting/changing the in-RZ loopback interface isn't currently supported.

[chrismarget-j]

Assigning values which overlap with a resource pool risks collisions. An enhancement request for explicit "check out" from a resource pool is being tracked in RFE-3202.

As a workaround, it's possible to "check out" pool resources within a Freeform Blueprint. These could be the same pools used within a DC blueprint.

If/when we get explicit checkout within the DC reference design, the workflow will be:

1. Assign pool to whatever role.
2. Apstra will begin pulling resources from the pool as needed.
3. Check out resource from the pool (Apstra won't know what you intend to do with it)
4. Explicitly assign checked-out resource to a fabric function which needs to be predictable.
5. The auto-assigned resource value will be displaced in the previous step, and returned to the pool.

Closing this issue for now... I don't think there's much we can do with it on the client end at this time.