First, the essential ideas
- Hypervisor and VM
- A hypervisor allocates virtual hardware to virtual machines. Each VM runs its own guest operating system and kernel. A type 1 hypervisor runs directly on hardware; type 2 runs with a host operating system.
- Container and image
- A container is an isolated running process environment using the host kernel. An image supplies its packaged filesystem and defaults. Two containers from one image are still separate running instances.
- Virtual NIC and bridge
- A virtual network interface connects a guest or container to a software network. A bridge forwards Ethernet frames between its attached ports; it does not automatically supply application authorization.
- Namespace
- A Linux namespace gives processes a separate view of selected kernel resources, such as network interfaces and routes. A network namespace is not a complete independent guest kernel.
- VRF
- Virtual routing and forwarding gives groups of Layer 3 interfaces separate routing tables on a device. A VRF is neither a VM nor encryption; communication between VRFs requires an explicit design.
- Cloud service boundary
- A cloud service allocates provider resources on demand. Responsibility for guest systems, network policy and applications depends on the service model, not merely on where a server is located.
First ask which kernel runs the workload. Then ask which interface and forwarding context carry its traffic. A package called a container, a virtual network adapter and a routing table are different objects even when they exist on the same physical computer.
See the idea
The local container path stays inside the VM
A running container still needs its bridge attachment; this path does not traverse a cloud or the Internet.
Verify the baseline
d54-a sends a bounded ping through d54net to d54-b. Both containers share the VM kernel but have distinct network contexts.
What this model leaves out: This is the actual local lab path. The host-side virtual port names are generated. Hypervisor internals, VRFs and public-cloud resources are not shown or tested.
Full visual explanation and references
Container d54-a connects through the d54net bridge to container d54-b. Both endpoints and the bridge are inside one disconnected Ubuntu VM.
This is the actual local lab path. The host-side virtual port names are generated. Hypervisor internals, VRFs and public-cloud resources are not shown or tested.
- Verify the baseline
d54-a sends a bounded ping through d54net to d54-b. Both containers share the VM kernel but have distinct network contexts.
docs.gns3.com - Remove one attachment
Disconnect d54-b from d54net. Its process can remain running while the drawn destination attachment is absent and the test fails.
docs.gns3.com - Restore and retest
Reconnect d54-b at 172.30.54.20 and repeat the same ping. Preserve actual results; no public-cloud network has been exercised.
docs.gns3.com
One idea at a time
Start with something familiar.
Imagine following one packet from a process rather than assuming that everything on one computer is connected. The process uses its container's interface; a virtual link attaches it to the bridge; the bridge reaches the other container only while that attachment exists.
Why learn this?
A running workload can still have a disconnected network. Conversely, a reachable container may expose an application that should not be public. Checking process state, attachment, addressing and policy separately avoids both mistaken outages and accidental exposure.
An everyday comparison
A building can contain independent furnished apartments or several rooms sharing common facilities. Both arrangements provide separation, but the shared facilities and the doors between rooms affect what is actually isolated.
What happens in a network
A VM has a separate guest kernel, while containers on a Linux host share its kernel. Their network views can still be separate. The bridge is a deliberate connection between those views, not evidence that they share every resource.
Where the comparison stopsRooms do not model kernel vulnerabilities, privileged access or virtual switches. Neither a VM nor a container guarantees perfect isolation, and a door label cannot replace verification of an actual network policy.
Follow one worked example
- Separate packaging from execution.
The alpine:3.20 image is used twice to create d54-a and d54-b. They share the VM kernel but have distinct process and network contexts.
Why: An image name tells you the packaged environment, not which running instance owns an address.
- Trace the exact local path.
d54-a eth0 at 172.30.54.10 reaches bridge d54net and then d54-b eth0 at .20. No host port is published and the VM adapter is disconnected.
Why: This path stays inside the declared lab and cannot validate public-cloud reachability.
- Disconnect only the destination attachment.
d54-b keeps running but is removed from d54net. The original ping should fail until the same attachment and .20 address are restored.
Why: A running process and a usable interface are different evidence.
Your first small task
Label the kernel owner, interface and bridge for each container. Predict whether stopping the VM, disconnecting d54-b from the bridge and changing a cloud firewall rule would affect this exact local experiment.
Show a hint
Follow only declared dependencies. Do not add an Internet path just because the word Docker appears.
Check the expected result
Stopping the VM stops the lab; disconnecting the bridge attachment breaks the local path. A cloud rule has no role because no cloud resource exists here.
Pause and explain it in your own words
Is a Docker bridge the same thing as a VRF?
Show a hint
Compare Layer 2 frame forwarding with separate Layer 3 routing contexts.
Show the explanation
No. The bridge connects local Ethernet attachments. A VRF provides a separate routing table and associated Layer 3 interfaces. This lab configures the former, not the latter.
Short answer
What should you understand today?
A VM has a guest kernel on virtual hardware; a container normally shares its host kernel while isolating processes and resources. A VRF separates routing tables, and a cloud network adds provider-specific controls. These boundaries solve different problems and do not make all attached workloads trusted.
Before you begin
Learning targets
- Understand local IPv4 addressing and the distinction between a switch and router.
- Use a disposable Ubuntu 24.04 VM with Docker Engine 27.x and a preloaded official alpine:3.20 image.
- Have authorized sudo access only inside the disposable VM; disconnect its virtual NIC before the exercise.
- Distinguish hypervisors, guest kernels, container images and shared-kernel isolation.
- Trace a real local container-to-bridge-to-container path with exact endpoint addresses.
- Explain how VRFs and cloud network controls differ from this bridge.
- Remove one attachment, preserve evidence, restore it and repeat the baseline.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
Hypervisor and VM
A hypervisor allocates virtual hardware to virtual machines. Each VM runs its own guest operating system and kernel. A type 1 hypervisor runs directly on hardware; type 2 runs with a host operating system.
Container and image
A container is an isolated running process environment using the host kernel. An image supplies its packaged filesystem and defaults. Two containers from one image are still separate running instances.
Virtual NIC and bridge
A virtual network interface connects a guest or container to a software network. A bridge forwards Ethernet frames between its attached ports; it does not automatically supply application authorization.
Namespace
A Linux namespace gives processes a separate view of selected kernel resources, such as network interfaces and routes. A network namespace is not a complete independent guest kernel.
VRF
Virtual routing and forwarding gives groups of Layer 3 interfaces separate routing tables on a device. A VRF is neither a VM nor encryption; communication between VRFs requires an explicit design.
Cloud service boundary
A cloud service allocates provider resources on demand. Responsibility for guest systems, network policy and applications depends on the service model, not merely on where a server is located.
Identify the kernel and hardware boundary
Virtualization presents logical resources on shared physical hardware. A VM receives virtual CPU, memory, disks and NICs and boots a guest kernel. A hypervisor manages these resources; type 1 and type 2 describe different hosting arrangements. A virtual NIC still needs an attachment to a virtual switch or other network. A powered-on guest is not proof of a connected network or correct address.
- A VM's network attachment is distinct from its power state.
- Resource sharing requires monitoring and capacity planning, not assumptions about unlimited performance.
Treat a container as a process environment
A container image supplies files and metadata; a running container adds processes and a writable layer. Linux containers share the host kernel while namespaces and other controls restrict their view and resource use. This is different from booting a complete separate guest kernel. Privileged flags, host networking and host filesystem mounts can weaken the intended boundary. We use none of those options.
- Never infer perfect isolation merely from the word container.
- Deleting a container may discard its writable-layer data; persistence needs an explicit storage design.
Draw the actual forwarding path
A software bridge is a Layer 2 forwarding element. In ordinary Docker Engine, a user-defined bridge network manages container attachments and address assignment. This differs from GNS3's direct use of containers as emulated endpoints, where its topology manages links and often requires manual interface configuration. Do not paste this Docker Engine procedure into a GNS3 container console and expect identical network ownership.
- The host-side virtual interface names are generated; inspect them rather than inventing fixed port names.
- An internal bridge is not a strong boundary against an administrator controlling the Docker host.
Keep VRFs separate from workload isolation
A VRF associates Layer 3 interfaces with an independent routing table. Two VRFs may use overlapping addresses without automatically sharing routes. A route in the global table is not automatically usable inside every VRF. Deliberate interconnection or route leaking changes that separation and requires policy review. A VRF does not encrypt traffic, create a guest operating system or package an application.
- Ask which routing table owns the source interface.
- VRF configuration is conceptual supporting instruction here, not a performed Cisco practical.
Cloud boundaries require their own evidence
Cloud computing includes on-demand shared resources and service models such as infrastructure, platform and software as a service. A VM running locally is not by itself a public cloud. Provider networks may add virtual subnets, routing, gateways and policy controls, with details defined by the provider. Reachability and responsibility depend on those exact resources and the service contract. Do not equate a local bridge success with cloud security validation.
- No account, subscription, Internet gateway or billable resource is used in this lesson.
- Cloud responsibility boundaries vary by service; verify current provider documentation before operating.
Collect evidence at the right abstraction level
Inspect image identity, container state, network membership and endpoint addresses before running a ping. Compare those facts after a single disconnection fault. Restore the same IP and network rather than replacing the entire environment. Current v1.1 through 2 February 2027 includes virtualization fundamentals at 1.12; announced v2.0 from 3 February includes relevant concepts at 1.2. VRF and cloud boundaries are labeled supporting where the exact subobjective is narrower.
- Evidence from this exercise is local Linux bridge evidence only.
- A practical alternative is a paper path trace with no executed-network claim.
Real-world walkthrough
The application is running but its network is missing
In a fictional test host, a service container remains running after a network attachment is accidentally removed. A dashboard showing process state stays green, but another container cannot reach it. The team must distinguish an application crash from a missing local path before changing firewall policy.
- Write the intended source, destination, addresses and shared bridge name from the approved test plan.
- Inspect both containers' state and the bridge membership, rather than relying on a single green process indicator.
- Compare the destination's missing network attachment with the baseline record.
- Restore only that attachment at the original unused address, then repeat the same source-to-destination test.
- Record that the repaired local path does not establish application permissions or external cloud connectivity.
Guided GNS3 lab
Two containers on one isolated internal bridge
Create an exact local path inside a disconnected VM, remove one bridge attachment, and restore and verify it. Commands are executable instructions; no Docker runtime was executed during authoring.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| d54-a | eth0 | 172.30.54.10/24 | Source container. |
| d54net | Docker bridge gateway | 172.30.54.1/24 | Local bridge address; not an Internet gateway in this lab. |
| d54-b | eth0 | 172.30.54.20/24 | Destination container. |
Set up the lab
- Before isolation, install Docker Engine 27.x from its official distribution and preload official alpine:3.20; record its image ID or digest. The lab uses --pull=never.
- Disconnect the VM's external adapter in the hypervisor. Confirm the selected /24 does not conflict with any existing guest network.
- Use a fresh disposable VM and authorized sudo. If d54-a, d54-b or d54net already exists, stop rather than deleting unknown resources.
- The paper alternative draws the same path and predicts the attachment fault; label it unexecuted. No cloud account or Cisco image is required.
Confirm the isolated platform
Open the Ubuntu VM console and its Terminal. Inspect versions, the preloaded image and existing resources. Do not continue if names collide or the daemon is a remote production Docker context.
sudo docker context show
sudo docker version
sudo docker image inspect alpine:3.20
sudo docker ps -a
sudo docker network lsWhat each command means
sudo docker context show- Identify the active Docker context; require the local disposable VM daemon.
sudo docker version- Record actual client and server versions.
sudo docker image inspect alpine:3.20- Verify the image is already local and record its identity.
sudo docker ps -a- Check that the exercise container names are unused.
sudo docker network ls- Check that d54net is unused before creating it.
- What you should see
- Expect a local daemon and available image; stop on missing prerequisites.
- Why this step matters
- An explicit local target prevents accidental changes to a remote Docker host.
Create the bounded network
In the VM console Terminal, create only d54net with a fixed subnet and internal isolation flag. Inspect the resulting object before attaching any process to it.
sudo docker network create --driver bridge --internal --subnet 172.30.54.0/24 --gateway 172.30.54.1 d54net
sudo docker network inspect d54netWhat each command means
sudo docker network create --driver bridge --internal --subnet 172.30.54.0/24 --gateway 172.30.54.1 d54net- Create the named internal bridge with the exact address plan.
sudo docker network inspect d54net- Read back the driver, Internal flag, IPAM range and current membership.
- What you should see
- Expect bridge, Internal true and the declared /24; no containers are attached yet.
- Why this step matters
- The explicit network object makes scope and cleanup traceable.
Start two separate instances
In the VM console Terminal, create the two named containers from the existing image. The sleep process keeps each instance alive for inspection without serving any application.
sudo docker run -d --pull=never --name d54-a --network d54net --ip 172.30.54.10 alpine:3.20 sleep 3600
sudo docker run -d --pull=never --name d54-b --network d54net --ip 172.30.54.20 alpine:3.20 sleep 3600
sudo docker network inspect d54netWhat each command means
sudo docker run -d --pull=never --name d54-a --network d54net --ip 172.30.54.10 alpine:3.20 sleep 3600- Start the source with a fixed address and no port publishing.
sudo docker run -d --pull=never --name d54-b --network d54net --ip 172.30.54.20 alpine:3.20 sleep 3600- Start the destination at the other fixed address.
sudo docker network inspect d54net- Confirm both named containers and addresses appear in membership.
- What you should see
- Expect both containers attached with .10 and .20; record actual IDs without inventing them.
- Why this step matters
- Distinct names and fixed addresses keep the fault experiment repeatable.
Establish the local baseline
In the VM console Terminal, use docker exec to run each command inside the named container. Compare the kernel release and inspect the source interface before testing the destination.
uname -r
sudo docker exec d54-a uname -r
sudo docker exec d54-a ip address show eth0
sudo docker exec d54-a ping -c 3 -W 2 172.30.54.20What each command means
uname -r- Show the Ubuntu guest kernel used by this Docker host.
sudo docker exec d54-a uname -r- Show the kernel visible to the source container.
sudo docker exec d54-a ip address show eth0- Inspect the source container's actual interface address.
sudo docker exec d54-a ping -c 3 -W 2 172.30.54.20- Send a bounded ICMP test from the source container to the destination.
- What you should see
- Expect the kernel releases to match and the destination to reply; record actual results before faulting.
- Why this step matters
- Kernel sharing and local connectivity are separate observations, neither of which proves perfect isolation.
Remove one attachment only
In the VM console Terminal, detach d54-b from d54net while leaving its process running. Inspect both process state and network membership before repeating the same test.
sudo docker network disconnect d54net d54-b
sudo docker ps
sudo docker network inspect d54net
sudo docker exec d54-a ping -c 3 -W 2 172.30.54.20What each command means
sudo docker network disconnect d54net d54-b- Remove only the destination's attachment to the exercise network.
sudo docker ps- Check that d54-b's sleep process is still running.
sudo docker network inspect d54net- Verify d54-b is absent from this network's membership.
sudo docker exec d54-a ping -c 3 -W 2 172.30.54.20- Repeat the same bounded test after the single attachment change.
- What you should see
- Expect the process to remain up while the ping fails; retain any different observation.
- Why this step matters
- This fault separates compute state from the path needed for communication.
Restore the exact attachment
In the VM console Terminal, reconnect d54-b using its original address. Inspect the restored membership and rerun the identical source test; do not create a new network to hide the fault.
sudo docker network connect --ip 172.30.54.20 d54net d54-b
sudo docker network inspect d54net
sudo docker exec d54-a ping -c 3 -W 2 172.30.54.20What each command means
sudo docker network connect --ip 172.30.54.20 d54net d54-b- Restore the destination's original network and address.
sudo docker network inspect d54net- Confirm the repaired membership and .20 assignment.
sudo docker exec d54-a ping -c 3 -W 2 172.30.54.20- Retest the original source-to-destination path.
- What you should see
- Expect both memberships restored and replies matching the baseline.
- Why this step matters
- The narrow inverse and identical retest connect the repair to the observed failure.
Remove only exercise resources
In the VM console Terminal, preserve your observations first. Stop and remove only the two containers created here, then remove their now-unused network. Do not use prune or wildcard removal.
sudo docker stop d54-a d54-b
sudo docker rm d54-a d54-b
sudo docker network rm d54net
sudo docker network lsWhat each command means
sudo docker stop d54-a d54-b- Stop only the two named exercise processes.
sudo docker rm d54-a d54-b- Remove only the stopped exercise containers.
sudo docker network rm d54net- Remove the specific bridge after its endpoints are gone.
sudo docker network ls- Verify d54net is absent without altering other networks.
- What you should see
- Expect the exercise resources gone and the preloaded image retained.
- Why this step matters
- Explicit cleanup avoids deleting unrelated containers, networks, images or volumes.
Verify
- Record local daemon version, image identity and disconnected VM adapter.
- Inspect d54net driver, Internal flag, subnet and both endpoint addresses.
- Preserve the baseline ping from inside d54-a, not the Ubuntu host.
- During the fault, record d54-b running but absent from bridge membership and the failed retest.
- After restoration, verify .20 membership and the identical successful test; no public-cloud conclusion follows.
Troubleshoot
- If the image is missing, stop and return to the approved preload step; --pull=never intentionally prevents implicit downloads.
- If the containers exit after an hour, the sleep process expired; restart a fresh documented exercise instead of interpreting it as a bridge failure.
- If the address range overlaps another guest network, stop and redesign the entire plan consistently before creating resources.
- If sudo targets a remote Docker context or existing names, stop; do not remove unknown workloads to make this lab fit.
GNS3 does not provide Cisco images. A license or entitlement must permit the image in the selected environment; do not share or redistribute image files. Cisco Modeling Labs is an official alternative. Its supplied Cisco reference images are licensed for use within CML, not automatically for export to GNS3. An unlicensed learner must use the explicitly labeled paper alternative, not report simulated Cisco execution.
- Stop and remove only d54-a and d54-b, then remove d54net.
- Leave the VM disconnected and retain the image identity with your private evidence.
- Do not prune images or volumes, and do not modify any cloud account.
Practice set
Answer before you reveal
01What kernel does a Linux container use?
Its packaged userspace can differ from the host distribution without providing a separate running guest kernel.
02Why can a running container be unreachable?
Process state alone describes execution, not the complete traffic path to another endpoint.
03What does a VRF separate?
It does not create a new guest OS or encrypt the traffic. Interconnection requires an explicit routing design.
04Does an internal bridge isolate against the host administrator?
The lab limits ordinary external connectivity; it is not a claim of isolation from the privileged host.
05Why avoid publishing a container port here?
Publishing adds another reachability boundary and possible exposure that the current test does not need.
06Does a local ping validate a cloud network?
Provider subnet, gateway, identity and policy behavior requires its own specific configuration and evidence.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Identify the kernel owner before comparing VM and container isolation.
- Trace the actual NIC and bridge attachments instead of relying on process state.
- A VRF is a routing context, not encryption or an operating system.
- Local bridge results do not validate public-cloud resources.
- Use a bounded fault and restore the same address and attachment.
- Keep privileged host access and image provenance inside the safety boundary.