Docker Networking – Complete Guide with Practical Examples

Docker Networking is one of the most important Docker concepts, especially when working with ASP.NET Core Web API, SQL Server, multiple containers and microservices.

Let's understand it from the basics, using simple diagrams, CMD commands and practical examples on your Windows machine.

1. What is Docker Networking?

Docker Networking allows containers to communicate with each other, communicate with the host machine, and access external networks such as the internet.

Consider that you have two Docker containers:

• Container 1: ASP.NET Core Web API

• Container 2: SQL Server

Your Web API needs to communicate with SQL Server to retrieve customer information.

How can these two containers communicate?

Docker Networking provides this communication.

          Windows Host Machine
                   |
                   V
             Docker Engine
                   |
             Docker Network
                   |
          +--------+--------+
          |                 |
          V                 V
    Container 1        Container 2
    ASP.NET Core       SQL Server
       Web API             |
          |                |
          +----------------+
             Communication

Without proper networking, containers may not be able to communicate using the names and addresses you expect.

2. Why do we need Docker Networking?

Imagine an e-commerce application consisting of multiple services.

             E-Commerce Application
                       |
          +------------+------------+
          |            |            |
          V            V            V
      Web API       Payment API   SQL Server
      Container     Container     Container
          |            |            |
          +------------+------------+
                 Docker Network

Each container runs independently, but the application requires communication between them.

Docker Networking helps with:

3. Types of Docker Networks

Docker provides several network drivers.

The main network types you should understand are:

1. Bridge Network

2. Host Network

3. None Network

4. Overlay Network

5. Macvlan Network

Let's understand each one.

3.1 Bridge Network

A Bridge Network allows multiple containers running on the same Docker host to communicate with each other.

It is the default network driver for standalone Docker containers.

How does it work?

Imagine you create two containers:

• Container 1: ASP.NET Core API

• Container 2: SQL Server

Both containers are connected to the same Bridge Network.

               Docker Host
                    |
              Bridge Network
                    |
          +---------+---------+
          |                   |
          V                   V
     Container 1         Container 2
     ASP.NET Core        SQL Server
          |                   |
          +-------------------+
             Communication

Each container receives its own network interface and IP address.

For example:

Container 1: 172.20.0.2
Container 2: 172.20.0.3

These are illustrative addresses; Docker assigns the actual addresses.

Types of Bridge Networks

There are two important forms:

A. Default Bridge Network

Docker automatically provides a default network named bridge.

Check available networks:

docker network ls

Example output:

NETWORK ID     NAME      DRIVER
abc123         bridge    bridge
def456         host      host
ghi789         none      null

When you create a container without specifying a network:

docker run -d --name container1 nginx

Docker connects it to the default bridge network.

Create another container:

docker run -d --name container2 nginx

Both containers connect to the same default bridge network.

Important limitation: Containers on the default bridge network generally communicate using IP addresses, but automatic container-name DNS resolution is not provided in the same way as on user-defined bridge networks.

B. User-defined Bridge Network

This is the recommended approach for communication between standalone containers.

Create a custom network:

docker network create mynetwork

Check networks:

docker network ls

Create the first container:

docker run -d --name api-container --network mynetwork nginx

Create the second container:

docker run -d --name db-container --network mynetwork nginx

Now both containers belong to mynetwork.

You can communicate using container names.

For example, from api-container:

getent hosts db-container

This resolves the container name to its network IP address.

You can also test connectivity:

curl http://db-container

Since both containers are using Nginx, the second container responds with its default Nginx page.

Default Bridge vs User-defined Bridge

Interview point: Prefer user-defined Bridge Networks for multi-container applications because they provide automatic DNS-based service discovery.

3.2 Host Network

A Host Network allows a container to use the host's network namespace instead of getting an isolated network namespace.

In simple words:

The container shares the host's network environment.

How does it work?

Normally, Docker provides a separate network interface and IP address for each container.

With Host Networking, the container uses the host network directly.

          Host Machine
               |
          Host Network
               |
        +------+------+
        |             |
        V             V
    Host Process   Container
                   Application

Practical example

On a native Linux Docker host:

docker run -d --name nginx-host --network host nginx

Nginx listens on port 80.

You can access it through:

http://localhost:80

Notice that we did not specify -p 8080:80.

Why?

Because Host Networking does not use Docker's normal port-mapping mechanism. The container uses the host's network namespace directly.

Important points

• No separate container network namespace.

• No normal Docker port mapping is required.

• Port conflicts can occur with other host processes.

• Primarily useful in specific Linux networking scenarios.

Windows Docker Desktop note: Host networking has platform and configuration limitations. It is not identical to native Linux host networking and requires supported Docker Desktop settings. For your Windows practice, use Bridge Networking for now.

3.3 None Network

A None Network completely isolates a container from external network communication.

The container does not receive a normal external network connection.

Practical example

Execute:

docker run -it --name isolated-container --network none ubuntu bash

Now execute:

ip addr

You will generally see:

lo: 127.0.0.1

The loopback interface is available.

Try accessing the internet:

curl https://google.com

The request will fail because the container has no external network connection.

Why do we need None Network?

Consider an application that processes sensitive files.

You want it to process files locally without communicating with external systems.

You can use None Networking to isolate it.

Use cases:

• Security testing.

• Offline processing.

• Isolated batch jobs.

• Applications that do not require network connectivity.

3.4 Overlay Network

An Overlay Network allows containers running on different Docker hosts to communicate with each other.

This is particularly useful in distributed applications.

Imagine you have two physical or virtual servers:

• Server 1: Runs an ASP.NET Core Web API container.

• Server 2: Runs a Payment API container.

Both containers need to communicate even though they run on different servers.

An Overlay Network provides a virtual network connecting them.

Architecture

             Overlay Network
                    |
          +---------+---------+
          |                   |
          V                   V
      Docker Host 1       Docker Host 2
          |                   |
          V                   V
     Container 1         Container 2
     Web API             Payment API
          |                   |
          +-------------------+
             Communication

Where is it used?

• Docker Swarm.

• Distributed microservices.

• Multi-host container communication.

Practical example

Overlay Networks are commonly used with Docker Swarm.

First, initialize Swarm on the manager node:

docker swarm init

Create an attachable overlay network:

docker network create -d overlay --attachable my-overlay

Check the network:

docker network ls

Output:

NETWORK ID     NAME         DRIVER
abc123         my-overlay   overlay

You can create a service:

docker service create --name web --network my-overlay nginx

The service can communicate with other services connected to the same overlay network.

Important: Overlay Networking requires Docker Swarm or another supported multi-host networking setup. A normal standalone Docker container cannot simply use an overlay network without the required configuration.

3.5 Macvlan Network

Macvlan allows a container to appear as a separate physical device on the host's network.

Normally, containers communicate through Docker's virtual networking infrastructure.

With Macvlan, each container can receive its own MAC address and an IP address from the physical LAN subnet.

Architecture

             Physical Network
                    |
                Router
                    |
              Docker Host
                    |
                Macvlan
                    |
          +---------+---------+
          |                   |
          V                   V
     Container 1         Container 2
     IP: 192.168.1.10    IP: 192.168.1.11
     MAC: Unique         MAC: Unique

The IP addresses above are examples.

Why do we need Macvlan?

Consider a legacy application that expects to communicate with another application using a physical network IP address.

Macvlan allows containers to appear as separate devices on the physical network.

Use cases:

• Legacy applications.

• Network appliances.

• Applications requiring direct LAN connectivity.

• Specific network integration scenarios.

Important points

• Each container gets a separate MAC address.

• Containers can obtain IP addresses from the LAN subnet.

• Network infrastructure must support the additional MAC addresses.

• Host-to-container communication has additional configuration requirements.

• Macvlan is not generally needed for ordinary ASP.NET Core applications.

Windows Docker Desktop: Macvlan is not a straightforward option for your regular Windows Docker Desktop setup. It is primarily a Linux host networking feature.

4. Comparison of All Docker Network Types

This table is important for interviews.

Which network should you use?

For your current ASP.NET Core and SQL Server Docker practice:

• Bridge: Use this for normal multi-container applications.

• Host: Understand the concept; generally not required for your Windows practice.

• None: Use when network isolation is required.

• Overlay: Learn when moving to Docker Swarm and multi-host deployments.

• Macvlan: Learn for advanced networking scenarios.

5. Docker Port Mapping – Very Important

This is another important Docker Networking concept.

Suppose your ASP.NET Core API is running inside a container on port 8080.

How can you access it from your Windows browser?

You need Port Mapping.

Port Mapping connects a port on your host machine to a port inside the container.

Example

docker run -d --name myapi -p 8080:80 nginx

Understand this:

-p HOST_PORT:CONTAINER_PORT

In our example:

The communication flow:

Windows Browser
      |
      V
http://localhost:8080
      |
      V
Docker Port Mapping
      |
      V
Container Port 80
      |
      V
Nginx Application

Now open:

http://localhost:8080

You should see the Nginx welcome page.

More port mapping examples

docker run -d -p 8081:80 nginx

Host port 8081 connects to container port 80.

docker run -d -p 5000:8080 myapi:v1

Host port 5000 connects to container port 8080.

Important: Port mapping is not the same as Docker Networking. It is a mechanism for exposing container services through the host.

6. Docker Network Commands

These are the commands you should know.

Example: Inspect a network

docker network inspect bridge

This displays:

• Network name.

• Network driver.

• Subnet.

• Gateway.

• Connected containers.

• Container IP addresses.

Example: Connect an existing container

Suppose you already have a container:

docker run -d --name api-container nginx

Create a network:

docker network create mynetwork

Connect the existing container:

docker network connect mynetwork api-container

Now the container is connected to the additional network.

A container can be connected to multiple networks.

7. Container-to-Container Communication Using Container Names

This is one of the most important concepts in Docker Networking.

Imagine you have:

Container 1                 Container 2
ASP.NET Core API             SQL Server
     |                           |
     +---------- Network --------+

Your API needs to connect to SQL Server.

You might think you need the SQL Server container's IP address.

But Docker provides DNS-based service discovery on user-defined networks.

You can use the container name instead.

For example:

Server=sqlserver-container,1433;

Here, sqlserver-container is the SQL Server container name.

Docker resolves this name to the container's IP address on the shared network.

Why is this useful?

Container IP addresses can change when containers are recreated.

But if you reuse the same container name or service name, your application configuration can remain unchanged.

For example:

Old SQL Server IP: 172.20.0.2
New SQL Server IP: 172.20.0.4

Container name: sqlserver-container

Your application can continue using:

sqlserver-container

This is particularly useful in microservices architecture.

Important: Container-name DNS resolution works on user-defined Bridge Networks and supported service networks. Do not assume the same behavior on Docker's default Bridge Network.

8. Docker Network Isolation

Docker Networks also provide network isolation.

Consider an application with two separate networks.

                 Docker Host
                      |
          +-----------+-----------+
          |                       |
          V                       V
      frontend-net             backend-net
          |                       |
          V                       V
     Frontend API             SQL Server
          |                       |
          +---- Not directly -----+
                connected

If two containers are not connected to a common network, they generally cannot communicate directly through Docker's private container networking.

This helps separate application components.

Practical example

Create two networks:

docker network create frontend-net
docker network create backend-net

Create containers:

docker run -d --name frontend --network frontend-net nginx

docker run -d --name database --network backend-net nginx

Now:

• Frontend belongs to frontend-net.

• Database belongs to backend-net.

• They do not share a Docker network.

You can connect a container to multiple networks when necessary.

Real-world use: Separate public-facing application components from internal backend components.

Note that network isolation is one security layer, not a complete security solution. You should also configure authentication, authorization and firewall rules.

9. Practical Exercise – Docker Networking on Windows

Now let's perform a complete practical exercise.

We will create two Nginx containers and connect them using a custom Bridge Network.

Our objective:

1. Create a custom network.

2. Create two containers.

3. Connect both containers to the same network.

4. Communicate using container names.

5. Access a container from Windows using port mapping.

6. Inspect network details.

Step 1: Create a custom Bridge Network

Open CMD:

docker network create practice-network

Check:

docker network ls

You should see:

NETWORK ID     NAME               DRIVER
abc123         practice-network   bridge

Step 2: Create the first container

docker run -d --name web1 --network practice-network nginx

Step 3: Create the second container

docker run -d --name web2 --network practice-network nginx

Now both containers are connected to practice-network.

Step 4: Check the network

docker network inspect practice-network

Look for the Containers section.

You should see both containers:

Containers:
    web1
    web2

Step 5: Test communication between containers

Execute:

docker exec web1 curl http://web2

Expected output:

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to nginx!</title>
</head>
<body>
    <h1>Welcome to nginx!</h1>
</body>
</html>

Why does this work?

1. Both containers belong to the same custom Bridge Network.

2. Docker provides DNS resolution.

3. Docker resolves web2 to its container IP.

4. The HTTP request reaches Nginx running inside web2.

You have successfully established container-to-container communication!

Step 6: Test the reverse communication

docker exec web2 curl http://web1

This should also return the Nginx welcome page.

Both containers can communicate with each other.

Step 7: Expose a container to Windows

So far, our containers can communicate internally.

Now let's expose web1 to Windows.

First, stop and remove web1:

docker rm -f web1

Recreate it with port mapping:

docker run -d --name web1 --network practice-network -p 8080:80 nginx

Open your browser:

http://localhost:8080

You should see the Nginx welcome page.

Notice:

• Windows accesses the container using port 8080.

• Other containers can access it using web1 and port 80.

• Port 8080 is not required for communication between containers on the same network.

This distinction is very important.

10. Real-world ASP.NET Core + SQL Server Networking

Let's connect this concept to your actual development environment.

Suppose you have two containers:

• portfolio-api: ASP.NET Core Web API.

• portfolio-sql: SQL Server.

Create a network:

docker network create portfolio-network

Run SQL Server:

docker run -d ^
  --name portfolio-sql ^
  --network portfolio-network ^
  -e ACCEPT_EULA=Y ^
  -e MSSQL_SA_PASSWORD=YourStrong!Pass123 ^
  -p 1433:1433 ^
  mcr.microsoft.com/mssql/server:2022-latest

Run your API:

docker run -d ^
  --name portfolio-api ^
  --network portfolio-network ^
  -p 8080:8080 ^
  myportfolioapi:v1

In your ASP.NET Core application, configure the connection string:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=portfolio-sql,1433;Database=PortfolioDB;User Id=sa;Password=YourStrong!Pass123;TrustServerCertificate=True;"
  }
}

Notice:

Server=portfolio-sql,1433

We are using the SQL Server container name instead of localhost.

Why?

Inside the API container, localhost refers to the API container itself, not the SQL Server container.

Docker DNS resolves portfolio-sql to the SQL Server container's network IP.

Also, both containers must be connected to the same network.

For production, use Docker secrets or another secure secret-management solution rather than storing database passwords in appsettings.json or command history. A production database port generally does not need to be published to the host unless external access is required.

11. Important Docker Networking Interview Questions

These are the questions I recommend preparing for interviews.

12. Knowledge Check – Scenario-based Questions

Let's test your understanding. Docker Networking Assessment.