Microsoft Connected Cache (MCC) Networking and Management Design

Gerald Rodriguez 20 Reputation points
2026-06-28T08:11:12.75+00:00

Hi everyone,

We're currently designing a Microsoft Connected Cache (MCC) deployment on bare-metal RHEL 9.x servers using Azure IoT Edge (Moby Engine). I have a few questions regarding the recommended networking architecture:

  1. Does MCC use the host network stack, or does it run on a Docker/Moby bridge or another network mode?
  2. The Azure provisioning portal requires a Server IP Address. Should this always be the host's production/service IP, or can it be a private IP/NAT address depending on the deployment?
  3. Is it supported or recommended to have a separate in-band management network for the RHEL host (e.g., dedicated management NIC or management VLAN for SSH, monitoring, and patching), while MCC traffic uses a separate production network?
  4. If a separate management network is used, are there any limitations or special considerations for Azure IoT Edge or the MCC container when the host has multiple network interfaces?
  5. Are there any Microsoft best practices or reference architectures for host networking and management network separation that are not covered in the public documentation?

I'd appreciate any insights from anyone who has deployed MCC in a production environment. Thanks!

Azure IoT Edge
Azure IoT Edge

An Azure service that is used to deploy cloud workloads to run on internet of things (IoT) edge devices via standard containers.

0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. Vinodh247-1375 44,796 Reputation points Volunteer Moderator
    2026-06-28T10:39:12.9666667+00:00

    Hi ,

    Thanks for reaching out to Microsoft Q&A.

    In prod MCC deployments on RHEL with azure IoT Edge, the MCC container typically runs using the default Moby (Dockercompatible) bridge network, not full host networking, but it still binds to the host’s IP and ports for cache delivery; host n/w mode is generally not required unless you have very specific performance or routing constraints. The “Server IP Address” in the azure portal should be the routable production IP that clients use to reach the cache (not a management IP), and it must be reachable by downstream devices, so NAT is only acceptable if it is stable and correctly mapped for inbound traffic.

    Using a separate in-band management network (dedicated NIC or VLAN for SSH, monitoring, patching) alongside a production network for MCC traffic is both supported and recommended in enterprise setups, as it aligns with standard separation of concerns and security practices. With multiple NICs, ensure proper routing (default route typically via the production network), DNS resolution, and that IoT Edge and MCC container bindings explicitly use the intended interface; also validate firewall rules and avoid asymmetric routing. There are no deeply prescriptive Microsoft reference arch beyond general IoT Edge guidance, but field best practice is clear: dual homed hosts with strict routing control, prod IP for MCC advertisement and management isolated, with careful validation of port exposure (typically 80/443) and consistent identity between what azure registers and what clients actually reach.

    Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.