Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getting error "[node_check_object fail! for ring-rx 0]" when trying to modify interface configuration #336

Open
rasanentimo opened this issue Sep 25, 2024 · 5 comments

Comments

@rasanentimo
Copy link

Description

I'm trying to modify interface configuration with fortios provider but getting following error

│ Error: Error updating SystemInterface resource: Internal Server Error - Internal error when processing the request (500)
│ Cli response: 
│ [node_check_object fail! for ring-rx 0]

Terraform and fortios provider version:

# terraform version
Terraform v1.9.6
on linux_amd64
+ provider registry.terraform.io/fortinetdev/fortios v1.21.0
fw1 # get system status 
Version: FortiGate-VM64-KVM v7.6.0,build3401,240724 (GA.F)
First GA patch build date: 240724

Expected result

Interface configuration changed.

Steps To Reproduce

Configure interface

resource "fortios_system_interface" "oob" {
  ip           = "10.0.3.13 255.255.255.248"
  name         = "port4"
  type         = "physical"
  vdom         = "root"
  mode         = "static"
  description  = "OOB port1"
}

Interface configuration is accepted.

Modify, for example, interface description

resource "fortios_system_interface" "oob" {
  ip           = "10.0.3.13 255.255.255.248"
  name         = "port4"
  type         = "physical"
  vdom         = "root"
  mode         = "static"
  description  = "OOB port2"
}
# terraform apply
fortios_system_interface.wan: Refreshing state... [id=port3]
fortios_system_interface.oob: Refreshing state... [id=port4]

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:

  # fortios_system_interface.oob will be updated in-place
  ~ resource "fortios_system_interface" "oob" {
      ~ description                                = "OOB port1" -> "OOB port2"
        id                                         = "port4"
        name                                       = "port4"
        # (221 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: yes

fortios_system_interface.oob: Modifying... [id=port4]
╷
│ Error: Error updating SystemInterface resource: Internal Server Error - Internal error when processing the request (500)
│ Cli response: 
│ [node_check_object fail! for ring-rx 0]

However, if I run 'terraform destroy' and then again 'terraform apply', the changes are applied. Although 'terraform destroy' doesn't remove any of the applied configurations from the FW configuration

@MaxxLiu22
Copy link

Hi @rasanentimo ,

Thank you for bringing up this issue. I was able to reproduce it, and it seems that the default value of ring-rx is set to 0. When you update the port, Terraform attempts to send 0 to FOS, but FOS does not accept 0 as a valid value; it only supports values between 1 and 1024. As a temporary solution, could you try using a generic resource? I have reported this to the development team for further investigation and resolution.

resource "fortios_json_generic_api" "test2" {
  path   = "/api/v2/cmdb/system/interface/port4"
  method = "PUT"
  json   = <<EOF
{
  "description": "test_generic"
}
EOF
}

Thanks,
Maxx

@rasanentimo
Copy link
Author

I'm just trying things out, so I can wait for the resolution for this issue. Is it also expected that the changes made with terraform are not removed when running 'terraform destroy' or just removing/commenting out certain lines from terraform? I see that the terraform state is modified but there's no changes on the FOS configuration, i.e. the interface config remains as it is.

@rasanentimo
Copy link
Author

I made another test by creating custom FW service based on this, https://registry.terraform.io/providers/fortinetdev/fortios/latest/docs/resources/fortios_firewallservice_custom, and it fails as well

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # fortios_firewallservice_custom.trname will be created
  + resource "fortios_firewallservice_custom" "trname" {
      + app_service_type      = "disable"
      + category              = "General"
      + check_reset_range     = "default"
      + color                 = 0
      + dynamic_sort_subtable = "false"
      + fabric_object         = (known after apply)
      + get_all_tables        = "false"
      + helper                = "auto"
      + id                    = (known after apply)
      + iprange               = "0.0.0.0"
      + name                  = "sservice_custom2"
      + protocol              = "TCP/UDP/SCTP"
      + protocol_number       = 6
      + proxy                 = "disable"
      + tcp_halfclose_timer   = 0
      + tcp_halfopen_timer    = 0
      + tcp_portrange         = "223-332"
      + tcp_timewait_timer    = 0
      + udp_idle_timer        = 0
      + uuid                  = (known after apply)
      + vdomparam             = (known after apply)
      + visibility            = "enable"
    }

Plan: 1 to add, 0 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: yes

fortios_firewallservice_custom.trname: Creating...
╷
│ Error: Error creating FirewallServiceCustom resource: Internal Server Error - Internal error when processing the request (500)
│ Cli response: 
│ []
│ 
│   with fortios_firewallservice_custom.trname,
│   on main.tf line 85, in resource "fortios_firewallservice_custom" "trname":
│   85: resource "fortios_firewallservice_custom" "trname" {

Could this be related to the FOS version being used, i.e. 7.6.0?

@MaxxLiu22
Copy link

Hi @rasanentimo ,

Thank you very much for your questions. For created objects such as firewall policies, static routes, etc., using terraform destroy will remove them from FortiOS. For modified objects, such as system global settings or alert email configurations, terraform destroy will reset all configurations to their default values. If certain arguments can be unset to their default or empty values, you may achieve this by either not setting them or commenting them out. In such cases, Terraform should perform the unset operation. The Terraform state file stores the remote FortiGate configuration, and each time you run terraform apply, the state file will be refreshed to reflect the current state of your FortiGate. I hope this clarifies your query.

Regarding the fortios_firewallservice_custom resource, please note that the protocol option was updated in version 7.6.0 to support TCP/UDP/UDP-Lite/SCTP. As our Terraform FortiOS provider is compatible with a wide range of FortiOS versions (6.0, 6.2, 6.4, 7.0, 7.2, 7.4, 7.6), there may be some configuration examples that do not fully align with certain versions. We sincerely apologize for any inconvenience this may cause.

Please feel free to let me know if you have further questions or need additional clarification.

resource "fortios_firewallservice_custom" "trname" {
  app_service_type    = "disable"
  category            = "General"
  check_reset_range   = "default"
  color               = 0
  helper              = "auto"
  iprange             = "0.0.0.0"
  name                = "sservice_custom2"
  protocol            = "TCP/UDP/UDP-Lite/SCTP"
  protocol_number     = 6
  proxy               = "disable"
  tcp_halfclose_timer = 0
  tcp_halfopen_timer  = 0
  tcp_portrange       = "223-332"
  tcp_timewait_timer  = 0
  udp_idle_timer      = 0
  visibility          = "enable"
}

Thanks,
Maxx

@rasanentimo
Copy link
Author

Hi @MaxxLiu22!

Thanks for the quick reply! I can confirm that changing the protocol from ""TCP/UDP/SCTP" to "TCP/UDP/UDP-Lite/SCTP" solved the issue of creating the custom service.

Here's the steps which I tried for the modifying the interface.

initial state, i.e no IP address configured

fw1 # show system interface port4
config system interface
    edit "port4"
        set vdom "root"
        set type physical
        set snmp-index 4
    next
end

fw1 # 

Run terraform

resource "fortios_system_interface" "oob" {
  ip           = "10.0.3.13 255.255.255.248"
  name         = "port4"
  type         = "physical"
  vdom         = "root"
  mode         = "static"
  description  = "OOB port2"
}

and the interface is configured with an IP

fw1 # show system interface port4
config system interface
    edit "port4"
        set vdom "root"
        set ip 10.0.3.13 255.255.255.248
        set type physical
        set description "OOB port2"
        set snmp-index 4
    next
end

fw1 # 

Comment out the changes and run terraform again

# resource "fortios_system_interface" "oob" {
#   ip           = "10.0.3.13 255.255.255.248"
#   name         = "port4"
#   type         = "physical"
#   vdom         = "root"
#   mode         = "static"
#   description  = "OOB port2"
# }

However, the changes are not reverted back

fw1 # show system interface port4
config system interface
    edit "port4"
        set vdom "root"
        set ip 10.0.3.13 255.255.255.248
        set type physical
        set description "OOB port2"
        set snmp-index 4
    next
end

fw1 # 

Although terraform lists it on the actions to be performed

      - description                                = "OOB port2" -> null
      - ip                                         = "10.0.3.13 255.255.255.248" -> null

Is this expected behaviour or could this be related to some changes with 7.6.0 as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants