Code Monkey home page Code Monkey logo

terraform-provider-nxos's Introduction

Tests

Terraform Provider NX-OS

Requirements

Building The Provider

  1. Clone the repository
  2. Enter the repository directory
  3. Build the provider using the Go install command:
go install

Adding Dependencies

This provider uses Go modules. Please see the Go documentation for the most up to date information about using Go modules.

To add a new dependency github.com/author/dependency to your Terraform provider:

go get github.com/author/dependency
go mod tidy

Then commit the changes to go.mod and go.sum.

Using the provider

This Terraform Provider is available to install automatically via terraform init. If you're building the provider, follow the instructions to install it as a plugin. After placing it into your plugins directory, run terraform init to initialize it.

Additional documentation, including available resources and their arguments/attributes can be found on the Terraform documentation website.

Developing the Provider

If you wish to work on the provider, you'll first need Go installed on your machine (see Requirements above).

To compile the provider, run go install. This will build the provider and put the provider binary in the $GOPATH/bin directory.

To generate or update documentation, run go generate.

In order to run the full suite of Acceptance tests, run make testacc. Make sure the respective environment variables are set (e.g., NXOS_USERNAME, NXOS_PASSWORD, NXOS_URL).

Note: Acceptance tests create real resources.

make testacc

terraform-provider-nxos's People

Contributors

danischm avatar defo89 avatar dependabot[bot] avatar jgomezve avatar moskrive avatar smburrows avatar vaneuk avatar

Stargazers

avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar

Forkers

natilik bridgecrew-perf5 vaneuk patricermc defo89 sapcc smburrows danfael prognet3

terraform-provider-nxos's Issues

Please add support hsrp for SVI interfaces

Hi,
it is possible to add hsrp to provider "nxos_svi_interface" ?
We need this SVI interface configuration:

interface Vlan3812
  no shutdown
  vrf member ccsew
  no ip redirects
  ip address 172.25.51.234/29
  no ipv6 redirects
  hsrp bfd
  hsrp version 2
  hsrp 3812 
    preempt delay minimum 60 
    priority 200
    ip 172.25.51.233

terraform destroy item still present

After running a terraform destroy on applied configuration, it failed to delete the following items

features

feature ospf
feature bgp
feature lacp
feature lldp
feature bfd

Interfaces

Before destroy

interface Ethernet1/1
  description Layer2_port
  no switchport
  vrf member CORE
  ip address 10.255.2.0/31
  no ip ospf passive-interface
  ip router ospf UNDERLAY area 0.0.0.0
  ip ospf bfd
  no shutdown

After destoy

interface Ethernet1/1
  description Layer2_port
  no switchport
  no shutdown

Expected result

interface Ethernet1/1
  shutdown (this due to "system default switchport shutdown")

Rest command not cleaned up

system default switchport shutdown

Provider produced inconsistent result after apply with nxos_spanning_tree_interface

Terraform Version

Terraform v1.2.9
on linux_amd64
+ provider registry.terraform.io/netascode/nxos v0.3.22

Affected Resource(s)

  • nxos_spanning_tree_interface

Terraform Configuration Files

resource "nxos_spanning_tree_interface" "STP_Ports" {
  depends_on = [
    nxos_physical_interface.Trunks,
    nxos_physical_interface.Access,
    nxos_rest.Port_Channel_Trunk_Interfaces,
    nxos_rest.Port_Channel_Access_Interfaces
  ]

  for_each = {
    for int in concat(
      local.trunk_ports,
      local.access_ports,
      local.po_trunk_interfaces,
      local.po_access_interfaces,
      local.shared_trunk_ports,
    local.shared_access_ports) : contains(keys(int), "int") ? "${int.dev_name}/${int.int}" : "${int.dev_name}/${int.po_id}" => int
  }

  device       = each.value.dev_name
  interface_id = contains(keys(each.value), "int") ? each.value.int : "po${each.value.po_id}"
  mode         = each.value.stp_port_type
  ctrl         = "unspecified"
}

Debug Output

Panic Output

Expected Behavior

Resource created.

Actual Behavior

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to nxos_spanning_tree_interface.STP_Ports["Prod-ACCESS-2/eth1/1"], provider "provider[\"registry.terraform.io/netascode/nxos\"]" produced an unexpected new value: .ctrl: was cty.StringVal("unspecified"), but
│ now cty.StringVal("").
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply

Important Factoids

Here's what the apply says is being created for that resource instance:

  # nxos_spanning_tree_interface.STP_Ports["Prod-ACCESS-2/eth1/1"] will be created
  + resource "nxos_spanning_tree_interface" "STP_Ports" {
      + admin_state  = "enabled"
      + bpdu_filter  = "default"
      + bpdu_guard   = "default"
      + cost         = 0
      + ctrl         = "unspecified"
      + device       = "Prod-ACCESS-2"
      + guard        = "default"
      + id           = (known after apply)
      + interface_id = "eth1/1"
      + link_type    = "auto"
      + mode         = "network"
      + priority     = 128
    }

References

IPv4 address did't apply

Hi
resource : nxos_ipv4_interface_address is not working.

terraform -v
Terraform v1.2.0
on windows_amd64
+ provider registry.terraform.io/netascode/nxos v0.3.12

v0.3.13 was also.

Affected Resource(s)

nxos_ipv4_interface_address

Terraform Configuration Files

terraform {
  required_providers {
    nxos = {
      source = "netascode/nxos"
      version = "0.3.12"
    }
  }
}

provider "nxos" {
  username = "admin"
  password = "cisco"
  # url      = "https://192.168.167.103"
}

provider "nxos" {
  alias = "leaf96"
  username = "admin"
  password = "cisco"
  url      = "https://192.168.160.96"
}

provider "nxos" {
  alias = "leaf97"
  username = "admin"
  password = "cisco"
  url      = "https://192.168.160.97"
}

resource "nxos_physical_interface" "bfd-leaf2-port2" {
  provider = nxos.leaf96
  interface_id             = "eth1/2"
  # bandwidth                = 1000
  admin_state              = "up"
  description              = "test"
  layer                    = "Layer3"
  link_logging             = "enable"
  mtu                      = 9216
}

resource "nxos_physical_interface" "bfd-leaf3-port2" {
  provider = nxos.leaf97
  interface_id             = "eth1/2"
  # bandwidth                = 1000
  admin_state              = "up"
  description              = "test"
  layer                    = "Layer3"
  link_logging             = "enable"
  mtu                      = 9216
}

resource "nxos_ipv4_interface_address" "ipv4-address-160_96-port2" {
  provider = nxos.leaf96
  vrf          = "default"
  interface_id = "eth1/2"
  address      = "123.123.123.1/30"
  type         = "primary"
}

resource "nxos_ipv4_interface_address" "ipv4-address-160_97-port2" {
  provider = nxos.leaf97
  vrf          = "default"
  interface_id = "eth1/2"
  address      = "123.123.123.1/30"
  type         = "primary"
}

Actual Behavior

What actually happened?

ip address is not configured.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply

  2. cisco nxos version : 9.3(7a)
    console.log

Missing legacy provider keys in OpenTofu Registry

Hello, I've been going through the organizations who have submitted provider keys in OpenTofu and saw the CiscoDevNet only uploaded their latest key and not any keys for older versions. As people migrate their infrastructure over to OpenTofu they run into issues only having knowledge of the latest provider key for older releases.

Could you submit your legacy public keys at: https://github.com/opentofu/registry/issues/new/choose

Error while installing ciscodevnet/nxos v0.1.0: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.1.1: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.2.0: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.2.1: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.2.2: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.2.3: authentication signature from unknown issuer
...
Error while installing ciscodevnet/nxos v0.4.0: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.4.1: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.4.2: authentication signature from unknown issuer

Thanks!

Please add support for BGP network statements

We need the ability to add BGP network statements to our BGP configuration. here is an example

router bgp 65000
  router-id 192.168.0.158
  graceful-restart restart-time 240
  graceful-restart stalepath-time 1800
  address-family ipv4 unicast
    network 2.2.2.3/32
  neighbor 5.5.5.2
    remote-as 65000
    description BGP Neighbor 1
    address-family ipv4 unicast
      send-community
      send-community extended

I am using the following nxos_rest resource to configure this and it works, but terraform keeps telling me that it's adding the addr value every time we apply

resource "nxos_rest" "bgp_networks" {
  for_each   = {for bgp_network in local.bgp_networks_configs : bgp_network.key => bgp_network}
  device     = each.value.device
  dn         = "sys/bgp/inst/dom-default/af-[ipv4-ucast]"
  class_name = "bgpDomAf"
  children   = [
    {
      rn         = "prefix-[${each.value.network_address}/${each.value.mask}]"
      class_name = "bgpAdvPrefix"
      content    = {
        addr = "${each.value.network_address}${each.value.mask}"
      }
    }
  ]
}

This is what terraform tells me

  # nxos_rest.bgp_networks["switch_2-2.2.2.3"] will be updated in-place
  ~ resource "nxos_rest" "bgp_networks" {
      ~ children   = [
          ~ {
              + content    = {
                  + "addr" = "2.2.2.3/32"
                }
                # (2 unchanged attributes hidden)
            },
        ]
        id         = "sys/bgp/inst/dom-default/af-[ipv4-ucast]"
        # (4 unchanged attributes hidden)
    }

Like i said, it still pushes the change and configures the network statement in the BGP config, but I don't like Terraform telling me that it's changing something that's not really changing. I'm sure it has something to do with how the NX-API is presenting the data after it's added and it's throwing Terraform off, so it thinks it's a change.

BTW, I appreciate all the support thus far with all the new features added. It seems like the provider is really coming along.

Add VLAN

Hi there,

What is the possibility to add vlan ?
Missing resource to add vlan.
Is it planned to create such a resource in the future?

When "nxos_physical_interface" resource is destroyed, port config is not removed.

As per title, when "nxos_physical_interface" resource is destroyed, most of the config lines still remain on device configuration.

For example,

resource "nxos_physical_interface" "access_port_phy_interface" {

  for_each = local.access_port_map

  device                    = each.value.device
  description               = "${each.value.description}[i/ac]"
  layer                     = "Layer2"
  interface_id              = "eth${each.value.interface_id}"
  admin_state               = "up"
  mode                      = "access"
  access_vlan               = "vlan-${each.value.vlan_id}"
}

After resource destroyed, the device "show run interface" still look like below.

interface Ethernet1/45
  description T:Access_Port_01:eth0[i/ac]
  switchport
  switchport access vlan 20
  no shutdown

It is expected to remove the port description and vlan-related configuration, or fall back to default port config.

New Resource: Add Spanning Tree Interface Resource for MO stpIf (sys/stp/inst/if-[<int>])

Terraform Version

Terraform v1.2.7
on linux_amd64
+ provider registry.terraform.io/netascode/nxos v0.3.21

Affected Resource(s)

Terraform Configuration Files

Debug Output

Panic Output

Expected Behavior

Actual Behavior

Steps to Reproduce

Important Factoids

Not sure if this is covered under another resource, I couldn't find anything, but would like to be able to modify a port's Spanning Tree port type.

Proposed new resource: nxos_spanning_tree_interface
Proposed arguments:

  • interface_id (string, Must match first field in the output of show intf brief. Example: eth1/1)
  • port_type (string, one of: normal, network, edge, trunk)
  • bpdufilter (string, one of: enable, disable)
  • bpduguard (string, one of: enable, disable)
  • guard (string, one of: none, loop, root)
  • cost (string, auto or numerical range: 1-200000000)

References

Please add support for `copy run start`

The NXOS provider currently lacks a resource for saving the running configuration to startup, similar to the iosxe_save_config resource available for the IOSXE provider. Is it possible to incorporate this feature into the NXOS provider as well?

For reference, the Cisco DevNet API documentation outlines this functionality:
Copy Running Config to Startup Config
I've successfully tested this API endpoint on a 9000v running version 9.3(9), and it works as expected.

For comparison, here is the resource for the IOSXE provider:
iosxe_save_config Resource

Also, I want to express my gratitude for your continuous support for this and the other DevNet Terraform providers.

ACL changes cannot be validated by Terraform with NXOS provider

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform: v1.2.3
netascode/nxos: 0.3.20

Affected Resource(s)

  • nxos_ipv4_access_list_entry

Terraform Configuration Files

https://github.com/netascode/terraform-nxos-acl-example/blob/main/main.tf

Expected Behavior

ACL should be created using the int16 value required by the API, but the response is a string in some cases, and the validation portion of the terraform apply needs to know to expect different string values.

Actual Behavior

The value gets properly set in the switch, but you get the following errors message because the validation cannot complete:
Error: Incorrect attribute value type

│   on main.tf line 69, in resource "nxos_ipv4_access_list_entry" "acl_entry":
│   69:   destination_port_1        = each.value.destination_port_1
│     ├────────────────
│     │ each.value.destination_port_1 is "domain"
│
│ Inappropriate value for attribute "destination_port_1": a number is required.

Steps to Reproduce

  1. terraform apply

References

https://pubhub.devnetcloud.com/media/nxapi-dme-model-reference/docs/Security%20and%20Policing/ipv4acl:ACE/

The reference doesn't make clear that the the POST for changes requires unit16, but GET will return a string that changes the name to reference common protocols as listed in the above link.

static routes are always forced to replace

when running a terraform job, the static routes are always a forced replacement. here is my resouse and local blocks

main.tf

  resource "nxos_ipv4_static_route" "static_routes" {
    for_each  = {for route in local.static_routes : route.key => route}
    device    = each.value.device
    vrf_name  = each.value.vrf
    prefix    = each.value.destination
    next_hops = [
      {
        interface_id = each.value.next_hop_interface == "" ? "unspecified" : each.value.next_hop_interface
        address      = each.value.next_hop_address
        vrf_name     = each.value.vrf
      }
    ]
  
    depends_on = [
      module.features,
      nxos_ipv4_vrf.default_vrf,
      nxos_vrf.vrf_config
    ]
  }

local.tf

  static_route_config_files = fileset(local.configs_path, "**/static_routes.csv")

  static_routes = flatten([
    for static_routes_config in local.static_route_config_files : [
      for static_route in csvdecode(file("${local.configs_path}${static_routes_config}")) :
      {
        key                = "${basename(dirname("${local.configs_path}${static_routes_config}"))}-${static_route.destination_network}"
        device             = basename(dirname("${local.configs_path}${static_routes_config}"))
        destination        = static_route.destination_network
        next_hop_address   = static_route.next_hop_ip
        next_hop_interface = static_route.next_hop_interface
        vrf                = static_route.vrf
        description        = static_route.description
        track_object       = static_route.track_object
        preference         = static_route.preference

      }
    ]
  ])

terraform apply output

# nxos_ipv4_static_route.static_routes["switch_2-9.9.9.0"] must be replaced
-/+ resource "nxos_ipv4_static_route" "static_routes" {
      ~ id        = "sys/ipv4/inst/dom-[default]/rt-[9.9.9.0]" -> (known after apply)
      ~ next_hops = [
          ~ {
              ~ interface_id = "" -> "Null0" # forces replacement
              ~ vrf_name     = "" -> "default" # forces replacement
                # (1 unchanged attribute hidden)
            },
        ]
        # (3 unchanged attributes hidden)
    }

i've checked this on the device and it is in fact removing the route and re-adding it. this will cause an outage for any routes that are redistributed

Please add support for VPC Configurations (Keepalive VRF and VPC Peer-links)

VPC Configuration by Terraform can be helpful by allowing:

  1. Resource "nxos_vpc_domain" could support peer-keepalive command for custom VRF
    peer-keepalive destination 192.168.1.1 source 192.168.1.2 vrf VPC_KeepAlive

  2. Resource "nxos_vpc_interface" "could support "vpc peerlink" command for VPC peerlink interface
    interface port-channel1
    vpc peer-link

#Cosmetic# provider fails to check credentials before trying to apply config

When deploying configuration with incorrect credentials, the provider instantly tries to deploy configuration without checking validity of the given credentials.
This result in the following:

nxos_feature_bgp.bgp: Creating...
nxos_feature_bgp.bgp: Still creating... [10s elapsed]
nxos_feature_bgp.bgp: Still creating... [20s elapsed]
nxos_feature_bgp.bgp: Still creating... [30s elapsed]

and after the timeout a hard crash from terraform

 Error: Client Error

   with nxos_feature_bgp.bgp,
   on system.tf line 18, in resource "nxos_feature_bgp" "bgp":
   18: resource "nxos_feature_bgp" "bgp" {
Failed to post object, got error: JSON error: {"imdata":[{"error": {"attributes": {"code": "403","text": "Need a valid webtoken cookie (named APIC-Cookie) or a signed request with signature in the cookie APIC-Request-Signature for all REST API requests"}}}]}

Compared to ACI provider which returns a "nice" error just stating
"unable to authenticate" with no time delay

Problem with resource "nxos_port_channel_interface_member" with list of interfaces

Hello,

we wrote an modul that create interfaces and an portchannel but got an error when trying to attached multiple interfaces to the portchannel. This first interfaces is fine, but we get an error to add the other interfaces. When apply terrafrom again, everthing is fine.

Module main.tf

terraform {
  required_providers {
    nxos = {
      source = "CiscoDevNet/nxos"
      #version = "0.5.1"
    }
  }
}
resource "nxos_physical_interface" "r_nxos_physical_interface" {
  for_each = toset(var.physical_intfs)
  interface_id             =  each.key
  admin_state              = var.admin_state
  description              =  var.description
  mode                      = var.switchport_mode
  trunk_vlans               = "1010-1500"
  device                    = "dc3-spktaggr-pw01"
}

resource "nxos_port_channel_interface" "r_nxos_port_channel_interface" {
  interface_id          = var.port-channel_id
  port_channel_mode     = var.port_channel_mode
  admin_state           = var.admin_state
  description           = local.updated_description
  link_logging          = "enable"
  mode                  = var.switchport_mode
  trunk_vlans           = var.trunk_vlans_po
  }
  
resource "nxos_port_channel_interface_member" "r_nxos_port_channel_interface_member" {
 for_each = toset(var.physical_intfs)
 interface_dn = "sys/intf/phys-[${each.key}]"
 interface_id = nxos_port_channel_interface.r_nxos_port_channel_interface.interface_id
 depends_on =[nxos_physical_interface.r_nxos_physical_interface]
 device = var.device

Calling the module

module "nxos_port_channel_dc3-spktaggr-pw01-po520" {
  source                    = "./modules/port_channel"
  physical_intfs            = ["eth1/29", "eth1/30"]
  admin_state               = "up"
  description               = "meine_neue_description"
  switchport_mode           = "trunk"
  trunk_vlans_po            = "1010-1500"
  port-channel_id           = "po520"
  port_channel_mode         = "active"
  vpc-port-channel_id       = null
  device                    = "dc3-spktaggr-pw01"
}

Error Message

module.nxos_port_channel_dc3-spktaggr-pw01-po520.nxos_port_channel_interface_member.r_nxos_port_channel_interface_member-sec-intf["eth1/29"]: Creation complete after 0s [id=sys/intf/aggr-[po520]/rsmbrIfs-[sys/intf/phys-[eth1/29]]]
╷
│ Error: Client Error
│ 
│   with module.nxos_port_channel_dc3-spktaggr-pw01-po520.nxos_port_channel_interface_member.r_nxos_port_channel_interface_member-sec-intf["eth1/30"],
│   on modules/port_channel/nxos_port_channel.tf line 68, in resource "nxos_port_channel_interface_member" "r_nxos_port_channel_interface_member-sec-intf":
│   68: resource "nxos_port_channel_interface_member" "r_nxos_port_channel_interface_member-sec-intf" {
│ 
│ Failed to post object, got error: JSON error: {"imdata":[{"error": {"attributes": {"code": "1","text": "Command failed: Port not compatible \n  Buffer boost : Port-channel has buffer-boost capability unset and interface has the
│ capability set \n** You can use force option to override the port's parameters \n** (e.g. \"channel-group X force\") \n** Use \"show port-channel compatibility-parameters\" to get more information on
│ failure\n\nfaulty_dn=sys\/intf\/aggr-[po520]\/rsmbrIfs-[sys\/intf\/phys-[eth1\/30]]"}}}]}`

EVPN/VXLAN modules

Hello,

I am looking at this provider in order to deploy EVPN services on a Nexus VXLAN fabric. Services that I deploy are the classic ones:
-VLAN with L2VNI/BGP configuration
-VRF with L3VNI/BGP configuration

I was wondering if this could be part of modules to simplify it

Switchport trunk allowed vlan add/remove

combination bug/feature request

currently this provider uses the DME-API interface and i'm not sure if its supported via that, but can see its supported via the NXAPI-CLI method and via cli.

can we have add and remove vlans from switchport trunk groups. (switchport trunk allowed vlan add/remove)

the DME interface overwrites the entire vlan list regardless of what is listed. Which means to be safe you need to read it back, add a vlan and then sort to avoid a situation where you are somehow out of sync with the network.

This is compounded by the fact that the trunk_vlans requires a sorted list, so the read back and add and remove logic is also not simple.

so this is fine
trunk_vlans = "10,100,200"

this is not and throws an error.
trunk_vlans = "200,10,100"

Missing resources in generic bgp configuration

Usecase

I've been looking into deploying some nexus switching using terraform as the orchestration tool.
I found the following resources were missing from the available resources

Ability to set local as on bgp peer

resource "nxos_rest" "bgp_localas" {
    for_each = local.bgp_neighbor
    dn = "sys/bgp/inst/dom-[${nxos_bgp_address_family.address_family.vrf}]/peer-[${nxos_bgp_peer.peer[each.key].address}]/localasn"
    class_name = "bgpLocalAsn"
    content = {
      localAsn = each.value.local_as
    }
}

Ability to set BFD, TTL (eBGP multihop) and password og bgp peer

resource "nxos_rest" "system_interface_default_shutdown" {
    for_each = local.bgp_neighbor
    dn = "sys/bgp/inst/dom-[${nxos_bgp_address_family.address_family.vrf}]/peer-[${nxos_bgp_peer.peer[each.key].address}]"
    class_name = "bgpPeer"
    content  = {
      passwdType = 0
      password = each.value.password
      ctrl = each.value.bfd
      ttl = each.value.ebgp_multihop 
    }
}

The password seems to be returned in the encrypted state - is there a way to encrypt the password prior to deploying it? and then in turn deploy it using passwdType 3?

Ability to set passive-interface default and bfd on ospf instance

resource "nxos_rest" "ospf_ctrl" {
    for_each = local.bgp_neighbor
    dn = "sys/ospf/inst-${var.ospf_name}/dom-${nxos_ospf_vrf.vrf.name}"
    class_name = "ospfDom"
    content = {
      ctrl = 5
    }
}

General security, ability to change the default state of physical ports

resource "nxos_rest" "system_interface_default_shutdown" {
    dn = "sys/ethpm/inst"
    class_name = "ethpmInst"
    content = {
      systemDefaultAdminSt = "down"
    }

}

0.4.1 causing token/auth errors

Using the following script on the version 0.4.1, i'm getting auth errors. here is the script i'm using:

terraform {
  required_providers {
    nxos = {
      source  = "netascode/nxos"
      version = "0.4.1"
    }
  }
}

provider "nxos" {
  username = "admin"
  password = "<pw>"
  devices  = local.switches
}

locals {
  switches = [
    {
      name         = "switch_1"
      url          = "https://192.168.0.154"
      vrf          = "default"
      prefix       = "11.11.11.0/24"
      interface_id = "unspecified"
      address      = "5.2.2.2"
    },
    {
      name         = "switch_2"
      url          = "https://192.168.0.155"
      vrf          = "default"
      prefix       = "11.12.11.0/24"
      interface_id = "unspecified"
      address      = "5.2.2.1"
    }
  ]
}


resource "nxos_ipv4_static_route" "example" {
  for_each  = {for device in local.switches : device.name => device}
  device    = each.value.name
  vrf_name  = each.value.vrf
  prefix    = each.value.prefix
  next_hops = [
    {
      interface_id = each.value.interface_id
      address      = each.value.address
      vrf_name     = each.value.vrf
      description  = "My Description"
    }
  ]
}

And here is the error i'm seeing:

│ Error: Client Error
│
│   with nxos_ipv4_static_route.example["switch_2"],
│   on main.tf line 38, in resource "nxos_ipv4_static_route" "example":
│   38: resource "nxos_ipv4_static_route" "example" {
│
│ Failed to retrieve object, got error: JSON error: {"imdata":[{"error": {"attributes": {"code": "403","text": "Need a valid webtoken cookie (named APIC-Cookie) or a signed request with signature in the cookie APIC-Request-Signature for all REST API requests"}}}]}
╵

I don't get auth errors when downgrading to 0.4.0

Please add support for static routes / port-channel interfaces (with vpc) / vpc domain config

it would be extremally helpful if you could add the following to the provider:

  • static routes (this currently can't be accomplished via the nxos_rest resource as two simultaneous calls are need, one for the destination prefix and another for the next-hop and it appears that the nxos_rest resource can only manage a single object at a time)
  • port-channel configs
  • vpc config (this would be a resource that lets you create the vpc domain and then an option on the ethernet interface to set the vpc number

Cannot create sys/vpc/inst/dom/if-<id> with nxos_rest

Terraform Version

Terraform v1.2.9
on linux_amd64
+ provider registry.terraform.io/netascode/nxos v0.3.21

Affected Resource(s)

nxos_rest

Specifically dn=sys/vpc/inst/dom/if-
Class Name = vpcIf

Terraform Configuration Files

resource "nxos_rest" "VPC_Member_Port" {
  device     = "Prod-ACCESS-1"
  dn         = "sys/vpc/inst/dom/if-2"
  class_name = "vpcIf"
  content = {
    id = "2"
  }
}

Debug Output

tftrace.log

Panic Output

Expected Behavior

vpcIf object created in the DME

Actual Behavior

Plan: 1 to add, 0 to change, 0 to destroy.
nxos_rest.VPC_Member_Ports: Creating...
╷
│ Error: Client Error
│ 
│   with nxos_rest.VPC_Member_Ports,
│   on main.tf line 706, in resource "nxos_rest" "VPC_Member_Ports":
│  706: resource "nxos_rest" "VPC_Member_Ports" {
│ 
│ Failed to post object, got error: JSON error: {"imdata":[{"error": {"attributes": {"code": "1","text": "ERROR: vPC configuration does not exist\nfaulty_dn=sys\/vpc\/inst\/dom\/if-2"}}}]}

Of course it doesn't, I'm trying to create it :D

Steps to Reproduce

  1. terraform apply

Important Factoids

Using the NXAPI sandbox, adding the VPC command to port-channel 2 does this:

{
  "topSystem": {
    "children": [
      {
        "vpcEntity": {
          "children": [
            {
              "vpcInst": {
                "children": [
                  {
                    "vpcDom": {
                      "children": [
                        {
                          "vpcIf": {
                            "attributes": {
                              "id": "2"
                            },
                            "children": [
                              {
                                "vpcRsVpcConf": {
                                  "attributes": {
                                    "tDn": "sys/intf/aggr-[po2]"
                                  }
                                }
                              }
                            ]
                          }
                        }
                      ]
                    }
                  }
                ]
              }
            }
          ]
        }
      },
      {
        "interfaceEntity": {
          "children": [
            {
              "pcAggrIf": {
                "attributes": {
                  "id": "po2"
                }
              }
            }
          ]
        }
      }
    ]
  }
}

The vpc dom object is already in the DME, and the port-channel exists, so I'm not sure why it's having trouble adding the vpcIf object.

References

Please add support for route maps to the redistributed routes under the "ipv4 unicast" address family.

Hi,
could you please add support for route maps to redistributed routes.

We need this configuration:

router bgp 65251
  vrf abcd
    address-family ipv4 unicast
      redistribute direct route-map <RouteMap>
      redistribute static route-map <RouteMap>

API Doku see:
https://developer.cisco.com/docs/cisco-nexus-3000-and-9000-series-nx-api-rest-sdk-user-guide-and-api-reference-release-102x/#!configuring-an-ipv4-unicast-address-family/configuring-a-route-map-to-redistributed-routes

Regards

Error when updating `nxos_ipv4_access_list_entry` resource

Initially I run the following Terraform Execution plan

resource "nxos_ipv4_access_list" "acl" {
  name = "TEST"
}

resource "nxos_ipv4_access_list_entry" "acl_entry" {
  name                      = "TEST"
  sequence_number           = 10
  protocol                  = "ip"
  action                    = "permit"
  source_prefix             = "10.0.0.0"
  source_prefix_length      = "8"
  destination_prefix        = "192.168.0.0"
  destination_prefix_length = "16"

  depends_on = [nxos_ipv4_access_list.acl]
}

Then I logged into the switch and performed and out-of-band change with the following lines:

configure terminal
ip access-list TEST
no 10
10 permit ip 10.0.0.0/8 192.168.0.0/24

Then after running terraform apply, out-of-band changes were detected on that resource

$ terraform apply
nxos_ipv4_access_list.acl: Refreshing state... [id=sys/acl/ipv4/name-[TEST]]
nxos_ipv4_access_list_entry.acl_entry: Refreshing state... [id=sys/acl/ipv4/name-[TEST]/seq-[10]]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # nxos_ipv4_access_list_entry.acl_entry will be updated in-place
  ~ resource "nxos_ipv4_access_list_entry" "acl_entry" {
      ~ destination_prefix_length = "24" -> "16"
        id                        = "sys/acl/ipv4/name-[TEST]/seq-[10]"
        name                      = "TEST"
        # (19 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

But at the configuration time Terraform failed

  Enter a value: yes

nxos_ipv4_access_list_entry.acl_entry: Modifying... [id=sys/acl/ipv4/name-[TEST]/seq-[10]]
╷
│ Error: Client Error
│ 
│   with nxos_ipv4_access_list_entry.acl_entry,
│   on main.tf line 21, in resource "nxos_ipv4_access_list_entry" "acl_entry":
│   21: resource "nxos_ipv4_access_list_entry" "acl_entry" {
│ 
│ Failed to update object, got error: JSON error: {"imdata":[{"error": {"attributes": {"code": "1","text": "Duplicate sequence
│ number\nfaulty_dn=sys\/acl\/ipv4\/name-TEST\/seq-10"}}}]}

Add support for route-map and prefix-lists

I noticed that there are no Route-Map and Prefix-List resources in the provider. I think it would be awesome if we could get those added. They're pretty important for network configuration, and it would be a huge help to have them available in Provider.

adding the ability to assign the prefix list or route-map to bgp neighbors would also be helpful

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.