On an Ignition 7.8.2 redundant pair, the OPC-UA connection to the local Siemens OPC-UA server on port 4845 is defined once on the master and synchronized to the backup. Discovery on the master against opc.tcp://localhost:4845 returns endpoints named opc.tcp://GTC-N-EST:4845. The backup receives that same definition, so it targets the master's server name instead of opc.tcp://GTC-S-EST:4845. The Host override field does not change this behavior on 7.8.2. Ignition 7.8.3 adds separate settings for configuring the backup node.
Where does the request from the backup gateway actually go?
Trace the path hop by hop. The OPC-UA client module on the backup gateway reads the synchronized connection definition. That definition contains the endpoint URL chosen on the master during Discover. The URL host is the name the Siemens server advertises in its GetEndpoints response, not the localhost you typed. A hostname-based endpoint URL is therefore stored, and it names the master's machine.
| Hop | Master gateway | Backup gateway (7.8.2, as observed) | Required on backup |
|---|---|---|---|
| Discovery URL typed | opc.tcp://localhost:4845 |
Not entered; setting is synced |
opc.tcp://localhost:4845 or the local name |
| Endpoint stored | opc.tcp://GTC-N-EST:4845 |
opc.tcp://GTC-N-EST:4845 (copied) |
opc.tcp://GTC-S-EST:4845 |
| Server reached | Local Siemens server | Master's Siemens server across the network, or nothing | Local Siemens server on the backup host |
Two consequences follow. If the master host is down, the backup's connection points at a dead host during the exact event redundancy exists for. If the master host is up, the backup opens a remote session to it, which hides the fault until failover.
Which check identifies the fault first?
Run the checks in order. Each outcome names the next step.
| # | Reading to take | Outcome A | Outcome B |
|---|---|---|---|
| 1 | Gateway version on both nodes (status page) | 7.8.2: continue to check 2 | 7.8.3 or later: go to check 5 |
| 2 | Endpoint URL of the OPC-UA connection as shown on the backup |
GTC-N-EST: synced master endpoint, go to check 3 |
GTC-S-EST: the definition is correct, go to check 4 |
| 3 | Set Host override on the master and re-read the backup | No change (observed on 7.8.2): the override is not applied per node, go to the fix procedure | Changes: re-test discovery on the backup, go to check 4 |
| 4 | Discover against the local server from the backup host | Returns GTC-S-EST:4845 endpoints: server is healthy, look at trust and security policy |
Nothing returned: server down, port blocked, or wrong port, go to check 6 |
| 5 | Backup-node settings on the connection (7.8.3 and later) | Present but empty or wrong: set them in the fix procedure | Absent: gateway is not actually on 7.8.3 |
| 6 | TCP test to the server port | Connects: inspect server endpoint configuration | Fails: fix DNS, firewall, or server binding |
How do I confirm the name and port resolve on each node?
Physical and IP reachability come before OPC-UA. From each gateway host, test both server names on the port in use:
Test-NetConnection GTC-N-EST -Port 4845
Test-NetConnection GTC-S-EST -Port 4845
Test-NetConnection localhost -Port 4845Expected result: localhost and the node's own name succeed on each host. A cross-node success from the backup to GTC-N-EST confirms the backup can reach the master's server, which explains why a mis-pointed connection can look healthy until the master fails. A failed local test means the Siemens server is not listening on the address the hostname resolves to; correct that before touching Ignition.
Why does the discovered endpoint list show two security policies?
The Siemens server offers two endpoints per URL: SecurityPolicy: Basic128Rsa15, MessageSecurity: SignAndEncrypt and SecurityPolicy: None, MessageSecurity: None. The master uses None. The backup connection must use the same policy, because the synchronized definition carries the policy selection. Selecting the secured endpoint on one node adds a certificate trust step on the server for that node's client certificate. A backup that appears connected on None and refuses after a policy change is a trust problem, not a routing problem.
What is the fix procedure for the backup node?
Ignition 7.8.3 adds settings on the connection for configuring the backup node. Upgrade both gateways, since a redundant pair is expected to run matching versions. Stage it on a test pair first; the fix was available as a 7.8.3 beta build at the time of the report.
- Back up both gateways before upgrading.
- Upgrade the pair to 7.8.3 and confirm both nodes report the same version and a healthy redundancy sync state.
- Open the OPC-UA connection on the master. Keep the master endpoint at
opc.tcp://GTC-N-EST:4845withSecurityPolicy: None,MessageSecurity: None. - In the new backup-node settings, enter the backup's server host
GTC-S-EST, port4845, and the same security policy. Read the exact field names on the connection edit page; they are not reproduced here. - Save. Wait for the change to sync, then reopen the connection on the backup gateway.
- Run Discover from the backup and confirm that
opc.tcp://GTC-S-EST:4845is offered.
How do I verify the backup uses its own server?
Work through these in order and stop at the first failure.
- On the backup gateway, the connection reports Connected against
opc.tcp://GTC-S-EST:4845, notGTC-N-EST. - With the master's Siemens server stopped or the master gateway isolated, the backup connection stays Connected and its tags hold Good quality.
- On the Siemens server on the backup host, the session list shows the backup gateway as the connected client.
- Force a redundancy failover on the test pair and confirm tag values keep updating from the backup node's local server after the role change.
What happens if the backup keeps the master's endpoint URL after failover?
The backup's OPC-UA client targets opc.tcp://GTC-N-EST:4845. If the master host is down, the connection cannot establish and tags go bad at the moment the backup takes over.
What happens if I set Host override on 7.8.2?
It had no effect on the backup's endpoint in the reported installation. Ignition 7.8.3 provides dedicated backup-node settings instead.
What happens if I pick Basic128Rsa15 SignAndEncrypt on the backup but the master uses None?
The two nodes then differ in security policy. The backup needs its client certificate trusted on its own Siemens server, and the connection stays faulted until trust is completed. Match the master's None policy unless security is required.
What happens if only one gateway is upgraded to 7.8.3?
The pair runs mixed versions, so redundancy sync and the new backup-node settings cannot be relied on. Upgrade both nodes and check the sync state before testing the connection.