Differences

This shows you the differences between two versions of the page.

--- zededa:patch-envelopes [2026/07/23 23:20] – mc
+++ zededa:patch-envelopes [2026/07/23 23:24] (current) – mc
@@ Line 100: / Line 100: @@
   * **Local-type NI can reach it; Switch-type cannot.** A **Local** network instance routes to ''169.254.169.254''. A **Switch** NI is pure **layer 2** (a bridge to the physical LAN) and has no path to an address that only exists inside EVE. So the app **must** have an interface on a **Local** NI to hit the metadata service.
   * **Multi-NIC default-route trap.** If a workload is attached to **two** network instances (e.g. one Local + one Switch, or two with default routes) and **both provide a default gateway**, the guest may pick the **Switch** interface as its default route — and then traffic to ''169.254.169.254'' goes out the wrong interface and **fails**.
-  * **Fix:** when both NIs run simultaneously, add a **static host route** for the metadata address inside the guest, pinned to the **Local** interface, e.g.: <code>ip route add 169.254.169.254/32 dev <local-iface></code> (or the netplan/cloud-init equivalent). That guarantees metadata traffic always uses the Local NI regardless of which interface owns the default route.
+  * **Fix — configure it on the Local network instance, NOT inside the guest.** EVE hands routes to the app through the **Local NI configuration** (advertised to the attached app via the NI's DHCP), not via manual ''ip route'' commands. Add a **static route** for the metadata address on the Local NI so the app always routes metadata traffic via that interface regardless of which one holds the default route. In the ''zedcloud_network_instance'' resource this is the ''static_routes'' block: <code>static_routes {
+  prefix  = "169.254.169.254/32"
+  gateway = "<Local NI gateway IP>"
+}</code> (The NI also has ''propagate_connected_routes'' for auto-propagating its connected routes.)
 **How to detect changes without busy-polling:** fetch ''description.json'' and compare the