Import capability for the aws_dx_bgp_peer resource

[fsvives]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

The creation of for instance an aws_dx_hosted_private_virtual_interface resource requires as input a single choice of what address_family (AF) the BGP peer is. This means for setting-up both IPv4 and IPv6 peering over the same VIF, we need to resort to the use of the aws_dx_bgp_peer resource.

In a case where multiple VIFs were created manually with peerings for both AF, only the import of the VIF and its associated AF would be possible, but not the secondary peer and AF. Hence, being able to import dx_bgp_peer would be very useful to have.

Alternatively, the VIFs resources should also accept "dual_stack" or "both" for the address_family input variable and plan/apply accordingly.

New or Affected Resource(s)

• aws_dx_bgp_peer [Optional - depends on the implementation]
• aws_dx_hosted_private_virtual_interface [Optional - depends on the implementation]
• aws_dx_hosted_public_virtual_interface [Optional - depends on the implementation]
• aws_dx_hosted_transit_virtual_interface [Optional - depends on the implementation]
• aws_dx_private_virtual_interface [Optional - depends on the implementation]
• aws_dx_public_virtual_interface [Optional - depends on the implementation]
• aws_dx_transit_virtual_interface [Optional - depends on the implementation]

Potential Terraform Configuration

Only if instead of enabling the import of aws_dx_bgp_peer resources the decision is to refactor the virtual interfaces would we need a different terraform configuration, and that would be for the virtual interface resources. In such case, it might be worth considering deprecating the aws_dx_bgp_peer resource. For example, in the case of the aws_dx_private_virtual_interface it could look as below.

resource "aws_dx_private_virtual_interface" "dualstack_private_vif" {
  address_family = "both"

  connection_id = "dxlag-abcdefgh"
  bgp_asn          = 65000
  name             = "my-dualstack-vif"
  vlan             = 1000
  amazon_address_v4   = 192.0.2.1/30
  customer_address_v4 = 192.0.2.2/30
  amazon_address_v6   = 2001:DB8::1/125
  customer_address_v6 = 2001:DB8::2/125

Note that for brevity some optional fields are disregarded. Also, the amazon_address and the customer_address fields would need to either get a suffix depending on the AF to be able to define all (ipv6 always optional), or the input variable redefined to expect an object with at least the IPv4 addresses defined.

References

I'm neither aware nor could I found any similar request.

[github-actions[bot]]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!