WIP: cloud ha doc to accomodate dual node#1029
Conversation
| | cloud-redundancy-plugin-network | ip-network | default: 169.254.137.0/30 | The ip network to use for internal networking. This should only be configured when the default value conflicts with a different service in the configuration. | | ||
| | enabled | boolean | default: true | Enable or disable the cloud redundancy member. | | ||
| | cloud-redundancy-group | reference | required | The group that this member belongs to. | | ||
| | dns-server | list: ipv4 | max-value:2 | DNS servers to be used for Cloud HA specific management traffic. Defaults specific to the solution-type will be used if none are configured to. | |
There was a problem hiding this comment.
DNS servers to be used for Cloud HA specific management traffic. Defaults specific to the solution-type are used if none are configured.
| | enabled | boolean | default: true | Enable or disable the cloud redundancy member. | | ||
| | cloud-redundancy-group | reference | required | The group that this member belongs to. | | ||
| | dns-server | list: ipv4 | max-value:2 | DNS servers to be used for Cloud HA specific management traffic. Defaults specific to the solution-type will be used if none are configured to. | | ||
| | tgw-attachment-id | string | | The TGW Attachment ID to use when this member becomes active. This field is only relevant when solution-type is aws-tgw. Ex. tgw-attach-00000000000000001. If this field is not specified, then you must use the Tag approach to specify the information to. | |
There was a problem hiding this comment.
If this field is not specified, then you must use the Tag approach to specify the information to.
- What is the Tag approach?
- Once we define the "Tag Approach" we can link to that procedure, at least clearly describe the tag approach.
- Suggested text:
If this field is not specified, manually tag the to identify the attachment ID(?).
| * Priorities across all members in a group are unique. | ||
| * IP Network fields such as `remote-health-network` and `cloud-redundancy-plugin-network` are validated to be an acceptable prefix size. | ||
| * The `peer-reachability-timeout` for a group must be at least twice the amount of time as the `health-interval`. | ||
| * Cloud Redundancy Group referenced by membership does not exist. |
There was a problem hiding this comment.
Not clear - referenced by what membership?
| * `shared-phys-address` cannot be configured in cloud HA mode. | ||
| * `tgw-attachment-id` must be configured on both members when `auto-discover-route-table` is disabled for AWS TGW solution type. | ||
| * `tgw-route-table-id` must be configured when `auto-discover-route-table` is disabled for AWS TGW solution type. | ||
| * At least one `extra-route-table` must be configured when `auto-discover-route-table` is disabled for Azure VNET solution type. |
There was a problem hiding this comment.
Some of this list reads like limitations, some of it reads like criteria for the cloud plugin to work. Maybe break out the limitations?
|
|
||
| ### PCLI Enhancements | ||
| To check the state of the Cloud HA solution running on the router, the plugin adds output to the `show device-interface` command for the `cloud-ha` interface. This state information is also accessible from the SSR's public REST API with a `GET` on `/api/v1/router/<router>/node/<node>/cloud-ha/state`. | ||
| To check the state of the Cloud HA solution running on the router, the plugin adds output to the `show device-interface` command for the `cloud-ha` interface. From **version 6.x**, plugin output is available in `show plugins state detail 128T-cloud-ha` command. This state information is also accessible from the SSR's public REST API with a `GET` on `/api/v1/router/<router>/node/<node>/cloud-ha/state`. |
There was a problem hiding this comment.
Beginning with version 6.x, plugin output is available using the show plugins state detail 128T-cloud-ha command.
| | is-node-active | Whether the HA Agent considers itself active. | | ||
| | local-status | The understood state of the local node. | | ||
| | remote-status | The understood state of the remote node. | | ||
| | last-activity-change | The timestamp of the last time the node called the became active or became inactive API on the API Agent. | |
There was a problem hiding this comment.
The timestamp of the last status change (active/inactive) of the node.
| | local-status | The understood state of the local node. | | ||
| | remote-status | The understood state of the remote node. | | ||
| | last-activity-change | The timestamp of the last time the node called the became active or became inactive API on the API Agent. | | ||
| | redundant-target-interface | The name of the first interface from the list of `redundant-interface`s that is healthy. | |
There was a problem hiding this comment.
The name of the first healthy interface in the redundant-interfacelist.
| | remote-status | The understood state of the remote node. | | ||
| | last-activity-change | The timestamp of the last time the node called the became active or became inactive API on the API Agent. | | ||
| | redundant-target-interface | The name of the first interface from the list of `redundant-interface`s that is healthy. | | ||
| | redundant-target-mac-address | The mac address of the first interface from the list of `redundant-interface`s that is healthy. | |
There was a problem hiding this comment.
The mac address of the first healthy interface in the redundant-interface list.
|
|
||
| The Cloud HA plugin supports two modes of operation: **dual-node** and **dual-router**. | ||
|
|
||
| ### Dual Node Mode |
There was a problem hiding this comment.
These summaries are good. Please provide a link to the more detailed explanation here [concepts_ha_theoryofoperation.md]
No description provided.