Oninit
Talk to an expert →

Informix Error -51

-51 Network is unreachable.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. If you are attempting to use Informix STAR or IBM Informix NET, contact your system administrator to find out what the network problem is. If not, note all circumstances and contact IBM Informix Technical Support.

Oninit® Troubleshooting Guidance

This is an operating-system error number, not an Informix diagnosis.

The same errno is returned by many different operations, so on its own it says what the operating system refused, not what Informix was trying to do. Informix will usually have reported a more specific error alongside it — in the message log, in the SQL or ISAM error pair, or in the accompanying assert failure — and that error normally defines the real cause far more precisely than the errno does. Find it before diagnosing from this number alone.

This matters less than it used to. Later versions of the engine trap many of these conditions and report them as specific Informix errors naming the operation, the object and the context, so a bare errno in this range is increasingly a sign of an older version, an unusual code path, or a failure early in startup before the better reporting is available. If you are seeing one on a current version, the more specific error is worth looking for even harder.

Important platform note. Error codes in this range represent operating-system errno values whose meanings vary between Unix platforms and versions. Confirm the native errno definition on the server where the Informix error occurred before diagnosing the problem from the number alone.

Determine the Native Error Meaning
Value Symbol
Catalogue text — Network is unreachable 51 ENETUNREACH on BSD
The same condition on Linux 101 ENETUNREACH
Errno 51 on Linux 51 EL2HLT — Level 2 halted, STREAMS-era

Codes -42 to -55 are the BSD socket block and each sits 50 higher on Linux.

python3 -c 'import os; print(51, os.strerror(51)); print(101, os.strerror(101))'
What ENETUNREACH Actually Tells You

There is no route to the destination. The local stack decided this before a packet left the host — it consulted the routing table, found nothing that covers the destination, and failed immediately.

That immediacy is the useful property. Unlike a timeout, this error is instant and local, which narrows the investigation sharply:

Error Symbol Where the decision was made
-51 ENETUNREACH Locally — no route in the table
-50 ENETDOWN Locally — the interface itself is down
(113 on Linux) EHOSTUNREACH Usually remotely — a router replied that the host is unreachable
(110 on Linux) ETIMEDOUT Nowhere — nothing replied at all

A no-route failure is a routing or interface problem on this host. A timeout is a problem somewhere along the path. They feel similar to a user and are diagnosed in completely different places.

What This Means in Informix

Inbound connections do not produce this — a client that cannot reach the server fails on the client side. So a -51 in the engine's own log means the instance was connecting outward:

  • HDR, RSS or ER connecting to a replication partner, especially after a failover has moved the partner to a different subnet.
  • Connection Manager reaching an instance it proxies for.
  • A distributed query opening a connection to another server named in sqlhosts.
  • onbar reaching a storage manager on another host.
  • An ALARMPROGRAM or monitoring script sending alerts outward.
  • Name resolution or directory lookups to a server on an unreachable network — which affects connection handling even though nothing about the database is at fault.

The context that produces it most often is a change elsewhere: a route withdrawn, a VPN or tunnel dropped, an interface reconfigured, or a container's networking rebuilt. The database host is usually the place where the consequence is noticed rather than the place where the change happened.

Common Causes
  1. A missing or withdrawn route to the destination network.
  2. No default gateway, or a gateway that has gone away.
  3. An interface down or unconfigured that carried the route — see -50.
  4. A VPN or tunnel dropped, taking its routes with it.
  5. A container or namespace without a route to the destination.
  6. A failover that moved a partner to a subnet this host cannot reach.
  7. IPv6 attempted with no IPv6 route, where resolution offered an address the host cannot route to — related to -47.
Diagnostic Checks

Ask the routing table what it would do. ip route get is the precise tool, because it answers for the exact destination rather than leaving you to read a table:

ip route get <destination-ip>
ip route show
ip -6 route get <destination-ip6> 2>/dev/null

$ ip route get 10.9.4.12
RTNETLINK answers: Network is unreachable

That output is the diagnosis in one line, and it names the error exactly.

Check the interfaces and the default route:

ip -br link
ip -br addr
ip route show default

Check what the engine was trying to reach:

cat "${INFORMIXSQLHOSTS:-$INFORMIXDIR/etc/sqlhosts}"
getent ahosts <partner-hostname>
grep -nE 'DRAUTO|HA_|LOG_INDEX' "$INFORMIXDIR/etc/$ONCONFIG" 2>/dev/null
onstat -g dri
onstat -g rss 2>/dev/null

Resolve the family question, since an IPv6 answer on a host with no IPv6 route produces this without anything being wrong with IPv4:

getent ahosts   <partner-hostname>
getent ahostsv4 <partner-hostname>
ip -6 route show

Check whether something was withdrawn recently:

journalctl -k --since '1 day ago' | grep -iE 'link|route|carrier|down'
dmesg -T | grep -iE 'link is (down|up)|carrier'
ip -s link show <iface> | head -6

And the engine's own record:

tail -300 "$INFORMIXDIR/tmp/online.log"
onstat -g ntt
Solutions / Resolution
  1. Run ip route get against the actual destination first. It gives a definitive local answer in one command, and it distinguishes this error from a timeout without any need to involve the network team.
  2. If there is no route, this is not a database problem. Escalate it as a routing question with the destination address and the ip route get output; that is a complete report and it avoids a long conversation about the database.
  3. Check the interface before the routes. A route that has vanished is often a symptom of the interface that carried it going down — see -50, where the distinction is set out.
  4. For replication, check the partner's current address rather than the one in the runbook. A failover that moved a partner to another subnet produces exactly this, and the configuration is correct for where the partner used to be.
  5. If resolution is offering IPv6 and there is no IPv6 route, that is the fault — see -47. Forcing IPv4 or removing the AAAA record for that name resolves it; adding an IPv6 route because an error mentioned it does not.
  6. In a container, check the namespace's routes, not the host's. They are frequently different and the host's table proves nothing.
  7. Expect replication to recover on its own once the route returns, but verify rather than assume — check the partner's state afterwards instead of waiting for the absence of errors.
Examples
The route, not the partner
$ ip route get 10.9.4.12
RTNETLINK answers: Network is unreachable

$ ip route show | grep -c '10\.9\.'
0

$ ip route show default
default via 10.4.1.1 dev eth0

There is a default route, and nothing covering 10.9.4.0/24 — so the destination is expected to be reached by a specific route that is no longer present. The partner is very likely fine; the path to it is not.

Resolution offered a family with no route
$ getent ahosts hdr-partner | head -1
2001:db8:9::12  STREAM hdr-partner

$ ip -6 route show
$

The name resolves to IPv6 first and the host has no IPv6 routing at all. The IPv4 address is present in resolution and never reached. This is the same underlying fault as -47, arriving through the routing layer rather than the socket layer.

Platform Note
Platform This condition Errno 51 there means
Linux errno 101 EL2HLT — STREAMS-era, unrelated
Solaris, AIX, HP-UX confirm on the host confirm on the host
BSD, Darwin errno 51 this condition
Task Linux Solaris AIX
Route for a destination ip route get <ip> route get <ip> route get <ip>
Routing table ip route show netstat -rn netstat -rn
Interface state ip -br link dladm show-link, ipadm netstat -in, entstat

route get exists on Solaris and AIX with the same purpose as ip route get, and is equally the right first command there.

Related Errors / Related Topics
  • -50 — Network is down. The interface itself rather than the route. Check it first, since a down interface removes its routes and produces this as a consequence.
  • -49 — Can't assign requested address, the inbound counterpart where the address is not available locally.
  • -54 — Connection reset by peer, where a route exists and the connection was aborted by the far end.

A -51 is decided locally and instantly, which makes it one of the quicker errors in this range to resolve: ip route get either produces a route or reproduces the error, and either outcome tells you where the work belongs.