How the Edge reaches devices

The Connect+ Edge talks to every monitored device over plain IP. It addresses each device by IP address and speaks the device's own management protocol (HTTP(s), SNMP, IPMI or a vendor protocol) — see Requirements for the port list.

Five rules govern every Edge deployment:

1. Devices are reached by IP address. There is no discovery protocol, no broadcast or multicast, and no agent installed on the device. Nothing has to be on the same subnet as the Edge.
2. The Edge uses the host machine's network stack. It runs in Docker host network mode, so it sees the host's interfaces, IP addresses and routing table directly — there is no Docker bridge, no NAT and no port mapping to configure.
3. "Can the Edge reach the device?" is the same question as "can the host machine reach the device?" Anything you can reach from a shell on the Edge host, the Edge can reach. This makes every routing problem testable without involving Xyte.
4. All connections are outbound from the Edge. The Edge opens connections to devices and to the Xyte servers. It never listens for inbound connections — not from devices, not from Xyte, not from anywhere.
5. The Edge never routes between its own interfaces. Traffic arriving on one NIC is never forwarded out another. This is the property that makes the multi-NIC and DMZ topologies below safe.

📘

Because rule 2 puts routing entirely in the hands of the host OS, everything on this page is configured on the machine, not in the Edge itself. There are no network settings inside the Edge to change.

Addressing the Edge host

Give the Edge host a static IP address, or a permanent DHCP reservation.

The host's IP ends up referenced in places that do not update themselves — firewall rules, switch ACLs, and the source-address allowlists that many devices apply to their own management interface. If the address moves, monitoring silently stops.

On a multi-homed host (more than one NIC), each connected network needs its own address on that host, and each should be static or reserved for the same reason.

Routing

A single-NIC Edge host needs nothing beyond a working default gateway. As soon as the host has more than one NIC, routing becomes explicit:

• Only one interface can carry the default route. In every topology below, that is NIC1 — the interface facing the internet. Anything the host does not have a more specific route for goes out that interface.
• Directly attached subnets need no route. The host already knows how to reach the network its own NIC sits on.
• Anything behind a router needs a static route. If a device subnet is reachable only through a router on NIC2 or NIC3, add an explicit route for that subnet. Without it, the traffic leaves via the default gateway on NIC1 and never arrives.
• Leave IP forwarding disabled. It is off by default on all supported operating systems. Leaving it off guarantees the Edge host cannot become a bridge between networks that are meant to stay separate.

A static route is a normal OS-level command — for example, on Linux:

# Device network 10.20.0.0/16 is reachable via the router at 10.10.1.1, on eth1
sudo ip route add 10.20.0.0/16 via 10.10.1.1 dev eth1

macOS (sudo route -n add -net 10.20.0.0/16 10.10.1.1) and Windows (route -p add 10.20.0.0 mask 255.255.0.0 10.10.1.1) have direct equivalents. Add the route persistently so it survives a reboot — the exact mechanism depends on the distribution or OS.

Deployment topologies

The four patterns below cover essentially every site. They differ only in how many networks the Edge host is attached to and whether those networks are allowed to reach each other.

Basic setup

The Edge host uses a single NIC. Its default gateway routes both outbound to the Xyte servers and inbound to the device LAN.

This is the simplest and most common deployment. It suits any site where the devices sit on the same LAN as the Edge host, or on another subnet that the site router already routes to.

What the network has to provide

• A default route from the Edge host to the internet, with eu1.edge.xyte.io:443 reachable.
• A route from the Edge host's subnet to each device subnet, permitted by any firewall or ACL in between.

Connected VLANs

The Edge host uses two NICs. NIC1 faces the internet-facing router. NIC2 faces a router that serves LAN 1 and also routes onward to LAN 2.

Use this when device VLANs are routed to each other but are kept off the internet-facing network. The Edge only needs to be attached to one of them — the router on NIC2 handles the rest.

What the network has to provide

• The default route on NIC1 only.
• A static route on the Edge host for LAN 2's subnet, via the router on NIC2. LAN 1 is directly attached and needs no route; LAN 2 is not, and will otherwise be sent out the default gateway.
• Routing between LAN 1 and LAN 2 permitted on the router serving NIC2.

Separate VLANs

The Edge host uses three NICs, one per network: NIC1 to the internet, NIC2 to LAN 1, NIC3 to LAN 2. LAN 1 and LAN 2 have no route to each other and no route to the internet.

Use this when device VLANs must stay fully isolated — from each other and from the outside — while still being monitored. The Edge host is multi-homed and reaches each VLAN directly on its own interface, so no traffic ever has to cross between them.

What the network has to provide

• One IP address for the Edge host on each VLAN, static or reserved.
• The default route on NIC1 only — LAN 1 and LAN 2 are directly attached and need no routes of their own. Only subnets sitting behind a router inside those VLANs need static routes.
• IP forwarding left disabled on the host, so the Edge host does not become a path between the isolated VLANs.

👍

Adding another isolated VLAN is just another NIC. The pattern scales as far as the host has interfaces.

DMZ

The Edge host straddles a security boundary. NIC1 sits in the internet-facing (DMZ) segment. NIC2 sits in a device network that has no internet access of its own. The Edge is the only thing touching both networks — and because it never forwards between its interfaces, the device network stays unreachable from outside.

This is the strictest posture, and usually the one security teams ask for:

• The device network needs no internet access, no outbound firewall rules and no NAT. Devices never leave their own segment.
• Only the Edge host is permitted outbound, and only on 443 to the Xyte endpoints.
• Nothing on the internet can reach the devices. The Edge accepts no inbound connections at all, so there is no path in even if the DMZ segment is compromised.

What the network has to provide

• An address for the Edge host in the DMZ segment (NIC1) and one in the device network (NIC2).
• The default route on NIC1, pointing at the DMZ router.
• IP forwarding left disabled on the host — this is what keeps the boundary intact.

Choosing a topology

All four are equally supported. The Edge behaves identically in each — only the host's addressing and routing differ.

Verifying connectivity

Every check runs from a shell on the Edge host, not from the Edge itself. If a check passes on the host, the Edge will succeed too.

⚠️

A failed ping does not mean a failed driver. Many devices drop ICMP by policy while answering their management protocol normally. Test the actual protocol and port before concluding the device is unreachable.

Common pitfalls

More questions? Contact the Xyte Support team ([email protected]).