IOx is enabled on a Catalyst 9000, but a networked Guest Shell app still has no reachability. What hosting interface concept is missing?
Select an answer to reveal the explanation.
Short Explanation
The app needs a door to the network—AppGigabitEthernet or management mapped to a vNIC. Enabled IOx with no data plane still leaves a networked app stranded.
Full Explanation
Networked Guest Shell or IOx apps need a data path into the container’s vNIC. On Catalyst 9000, that commonly means connectivity via AppGigabitEthernet and/or management interfaces mapped into the app. When IOx is enabled but a networked Guest Shell app still has no reachability, the missing hosting interface concept is that app networking mapping—not a random Layer-2 tweak unrelated to IOx.
Changing only an EtherChannel hash algorithm as the only required app NIC fails to provision AppGig or management mapping into the container. Disabling all switch uplinks so the app uses an air-gapped loopback only may isolate the box from the civic network the app was meant to monitor. Replacing IOx with VTP transparent mode for container networking confuses VLAN trunking protocol modes with application hosting interfaces.
Exam caveat: exact CLI and Yang for AppGig mapping vary by release—learn the concept that apps need a mapped interface. Management VRF versus front-panel reachability choices affect how monitoring apps see the campus.
Operational check: map AppGigabitEthernet or management into the Guest Shell/app vNIC per platform docs, ping a known civic IP from inside the app, and document the mapping in the municipal runbook.