From 5ddf631cd45eae0246ec6b7538122e93274e726e Mon Sep 17 00:00:00 2001
From: Allie Sadler <102604716+aevesdocker@users.noreply.github.com>
Date: Thu, 11 Jan 2024 08:19:40 +0000
Subject: [PATCH] Engdocs 1938 tier1 (#19068)

* ENGDOCS-1938-tier1

* .

* .
---
 content/network/drivers/ipvlan.md             | 35 ++++++++++---------
 content/network/drivers/macvlan.md            |  2 +-
 content/network/drivers/none.md               |  2 +-
 content/network/links.md                      | 29 ++++++++-------
 content/network/network-tutorial-host.md      |  5 +--
 content/network/network-tutorial-macvlan.md   |  8 ++---
 content/network/network-tutorial-overlay.md   | 17 +++++----
 .../network/network-tutorial-standalone.md    | 13 +++----
 content/network/packet-filtering-firewalls.md |  6 ++--
 9 files changed, 58 insertions(+), 59 deletions(-)

diff --git a/content/network/drivers/ipvlan.md b/content/network/drivers/ipvlan.md
index 2a540dd348..42c5311932 100644
--- a/content/network/drivers/ipvlan.md
+++ b/content/network/drivers/ipvlan.md
@@ -39,7 +39,9 @@ The following table describes the driver-specific options that you can pass to
 | `ipvlan_flag` | `bridge` | Sets the IPvlan mode flag. Can be one of: `bridge`, `private`, `vepa` |
 | `parent`      |          | Specifies the parent interface to use.                                |
 
-## Prerequisites
+## Examples
+
+### Prerequisites
 
 - The examples on this page are all single host.
 - All examples can be performed on a single host running Docker. Any
@@ -49,10 +51,9 @@ The following table describes the driver-specific options that you can pass to
   `docker network create` all together and the driver will create a `dummy`
   interface that will enable local host connectivity to perform the examples.
 - Kernel requirements:
-    - To check your current kernel version, use `uname -r`
-    - IPvlan Linux kernel v4.2+ (support for earlier kernels exists but is buggy)
+    - IPvlan Linux kernel v4.2+ (support for earlier kernels exists but is buggy). To check your current kernel version, use `uname -r`
 
-## IPvlan L2 mode example usage
+### IPvlan L2 mode example usage
 
 An example of the IPvlan `L2` mode topology is shown in the following image.
 The driver is specified with `-d driver_name` option. In this case `-d ipvlan`.
@@ -88,7 +89,7 @@ $ docker run --net=db_net -it --rm alpine /bin/sh
 # they are intentionally filtered by Linux for additional isolation.
 ```
 
-The default mode for IPvlan is `l2`. If `-o ipvlan_mode=` are left unspecified,
+The default mode for IPvlan is `l2`. If `-o ipvlan_mode=` is left unspecified,
 the default mode will be used. Similarly, if the `--gateway` is left empty, the
 first usable address on the network will be set as the gateway. For example, if
 the subnet provided in the network create is `--subnet=192.168.1.0/24` then the
@@ -156,7 +157,7 @@ $ docker exec -it cid2 /bin/sh
 $ docker exec -it cid3 /bin/sh
 ```
 
-## IPvlan 802.1Q trunk L2 mode example usage
+### IPvlan 802.1Q trunk L2 mode example usage
 
 Architecturally, IPvlan L2 mode trunking is the same as Macvlan with regard to
 gateways and L2 path isolation. There are nuances that can be advantageous for
@@ -202,7 +203,7 @@ without a router routing between the two networks. The default namespace is not
 reachable per IPvlan design in order to isolate container namespaces from the
 underlying host.
 
-### VLAN ID 20
+#### VLAN ID 20
 
 In the first network tagged and isolated by the Docker host, `eth0.20` is the
 parent interface tagged with VLAN id `20` specified with `-o parent=eth0.20`.
@@ -222,7 +223,7 @@ $ docker run --net=ipvlan20 -it --name ivlan_test1 --rm alpine /bin/sh
 $ docker run --net=ipvlan20 -it --name ivlan_test2 --rm alpine /bin/sh
 ```
 
-### VLAN ID 30
+#### VLAN ID 30
 
 In the second network, tagged and isolated by the Docker host, `eth0.30` is the
 parent interface tagged with VLAN id `30` specified with `-o parent=eth0.30`. The
@@ -296,7 +297,7 @@ are as follows:
 - VLAN: 30, Subnet: 10.1.100.0/16, Gateway: 10.1.100.1
     - `--subnet=10.1.100.0/16 --gateway=10.1.100.1 -o parent=eth0.30`
 
-## IPvlan L3 mode example
+### IPvlan L3 mode example
 
 IPvlan will require routes to be distributed to each endpoint. The driver only
 builds the IPvlan L3 mode port and attaches the container to the interface. Route
@@ -327,7 +328,7 @@ mode that reduces a failure domain to a local host only.
   requires a netlink route in the default namespace pointing to the IPvlan parent
   interface.
 - The parent interface used in this example is `eth0` and it is on the subnet
-  `192.168.1.0/24`. Notice the `docker network` is **not** on the same subnet
+  `192.168.1.0/24`. Notice the `docker network` is not on the same subnet
   as `eth0`.
 - Unlike IPvlan l2 modes, different subnets/networks can ping one another as
   long as they share the same parent interface `-o parent=`.
@@ -388,7 +389,7 @@ able to ping a remote host, the remote host or the physical network in between
 need to have a route pointing to the host IP address of the container's Docker
 host eth interface.
 
-## Dual stack IPv4 IPv6 IPvlan L2 mode
+### Dual stack IPv4 IPv6 IPvlan L2 mode
 
 - Not only does Libnetwork give you complete control over IPv4 addressing, but
   it also gives you total control over IPv6 addressing as well as feature parity
@@ -509,9 +510,9 @@ $ docker run --net=ipvlan140 --ip=192.168.140.10 -it --rm alpine /bin/sh
 > subnet. However, IPvlan `L3` will route the unicast traffic between disparate
 > subnets as long as they share the same `-o parent` parent link.
 
-## Dual stack IPv4 IPv6 IPvlan L3 mode
+### Dual stack IPv4 IPv6 IPvlan L3 mode
 
-**Example:** IPvlan L3 Mode Dual Stack IPv4/IPv6, Multi-Subnet w/ 802.1Q VLAN Tag:118
+Example: IPvlan L3 Mode Dual Stack IPv4/IPv6, Multi-Subnet w/ 802.1Q VLAN Tag:118
 
 As in all of the examples, a tagged VLAN interface does not have to be used. The
 sub-interfaces can be swapped with `eth0`, `eth1`, `bond0` or any other valid
@@ -571,7 +572,7 @@ $$ ip -6 route
 default dev eth0  metric 1024
 ```
 
-> *Note*
+> **Note**
 >
 > There may be a bug when specifying `--ip6=` addresses when you delete a
 > container with a specified v6 address and then start a new container with the
@@ -582,9 +583,9 @@ default dev eth0  metric 1024
 docker: Error response from daemon: Address already in use.
 ```
 
-## Manually create 802.1Q links
+### Manually create 802.1Q links
 
-### VLAN ID 40
+#### VLAN ID 40
 
 If a user does not want the driver to create the VLAN sub-interface, it needs to
 exist before running `docker network create`. If you have sub-interface
@@ -613,7 +614,7 @@ $ docker run --net=ipvlan40 -it --name ivlan_test5 --rm alpine /bin/sh
 $ docker run --net=ipvlan40 -it --name ivlan_test6 --rm alpine /bin/sh
 ```
 
-**Example:** VLAN sub-interface manually created with any name:
+Example: VLAN sub-interface manually created with any name:
 
 ```console
 # create a new sub interface tied to dot1q vlan 40
diff --git a/content/network/drivers/macvlan.md b/content/network/drivers/macvlan.md
index 3eb96b98d1..d440f6a95b 100644
--- a/content/network/drivers/macvlan.md
+++ b/content/network/drivers/macvlan.md
@@ -122,4 +122,4 @@ $ docker network create -d macvlan \
 ## Next steps
 
 Learn how to use the Macvlan driver in the
-[Macvlan networking tutorial](../network-tutorial-macvlan.md)
\ No newline at end of file
+[Macvlan networking tutorial](../network-tutorial-macvlan.md).
\ No newline at end of file
diff --git a/content/network/drivers/none.md b/content/network/drivers/none.md
index 16e24e62df..1c828a62a5 100644
--- a/content/network/drivers/none.md
+++ b/content/network/drivers/none.md
@@ -31,7 +31,7 @@ $ docker run --rm --network none --name no-net-alpine alpine:latest ip addr show
 
 ## Next steps
 
--  Go through the [host networking tutorial](../network-tutorial-host.md)
+- Go through the [host networking tutorial](../network-tutorial-host.md)
 - Learn about [networking from the container's point of view](../index.md)
 - Learn about [bridge networks](bridge.md)
 - Learn about [overlay networks](overlay.md)
diff --git a/content/network/links.md b/content/network/links.md
index 14f3b313df..1cc9dabf1e 100644
--- a/content/network/links.md
+++ b/content/network/links.md
@@ -44,7 +44,8 @@ Let's say you used this command to run a simple Python Flask application:
 $ docker run -d -P training/webapp python app.py
 ```
 
-> **Note**:
+> **Note**
+>
 > Containers have an internal network and an IP address.
 > Docker can have a variety of network configurations. You can see more
 > information on Docker networking [here](index.md).
@@ -118,12 +119,14 @@ $ docker port nostalgic_morse 5000
 127.0.0.1:49155
 ```
 
-> **Note**:
+> **Note**
+>
 > The `-p` flag can be used multiple times to configure multiple ports.
 
 ## Connect with the linking system
 
-> **Note**:
+> **Note**
+>
 > This section covers the legacy link feature in the default `bridge` network.
 > Refer to [differences between user-defined bridges and the default bridge](drivers/bridge.md#differences-between-user-defined-bridges-and-the-default-bridge)
 > for more information on links in user-defined networks.
@@ -170,7 +173,8 @@ aed84ee21bde  training/webapp:latest python app.py  12 hours ago  Up 2 seconds 0
 You can also use `docker inspect` to return the container's name.
 
 
-> **Note**:
+> **Note**
+>
 > Container names must be unique. That means you can only call
 > one container `web`. If you want to re-use a container name you must delete
 > the old container (with `docker container rm`) before you can create a new
@@ -266,9 +270,10 @@ command when the source container is started
 These environment variables enable programmatic discovery from within the
 target container of information related to the source container.
 
-> **Warning**:
-> It is important to understand that *all* environment variables originating
-> from Docker within a container are made available to *any* container
+> **Warning**
+>
+> It is important to understand that all environment variables originating
+> from Docker within a container are made available to any container
 > that links to it. This could have serious security implications if sensitive
 > data is stored in them.
 { .warning }
@@ -279,9 +284,7 @@ listed in the `--link` parameter. For example, if a new container called
 then Docker creates a `WEBDB_NAME=/web/webdb` variable in the `web` container.
 
 Docker also defines a set of environment variables for each port exposed by the
-source container. Each variable has a unique prefix in the form:
-
-    <name>_PORT_<port>_<protocol>
+source container. Each variable has a unique prefix in the form `<name>_PORT_<port>_<protocol>`
 
 The components in this prefix are:
 
@@ -383,7 +386,8 @@ PING webdb (172.17.0.5): 48 data bytes
 56 bytes from 172.17.0.5: icmp_seq=2 ttl=64 time=0.256 ms
 ```
 
-> **Note**:
+> **Note**
+>
 > In the example, you had to install `ping` because it was not included
 > in the container initially.
 
@@ -391,7 +395,8 @@ Here, you used the `ping` command to ping the `db` container using its host entr
 which resolves to `172.17.0.5`. You can use this host entry to configure an application
 to make use of your `db` container.
 
-> **Note**:
+> **Note**
+>
 > You can link multiple recipient containers to a single source. For
 > example, you could have multiple (differently named) web containers attached to your
 >`db` container.
diff --git a/content/network/network-tutorial-host.md b/content/network/network-tutorial-host.md
index df4c57017e..c575dededc 100644
--- a/content/network/network-tutorial-host.md
+++ b/content/network/network-tutorial-host.md
@@ -55,15 +55,12 @@ host.
 
 4.  Stop the container. It will be removed automatically as it was started using the `--rm` option.
 
-    ```basn
+    ```console
     docker container stop my_nginx
     ```
 
 ## Other networking tutorials
 
-Now that you have completed the networking tutorials for standalone containers,
-you might want to run through these other networking tutorials:
-
 - [Standalone networking tutorial](network-tutorial-standalone.md)
 - [Overlay networking tutorial](network-tutorial-overlay.md)
 - [Macvlan networking tutorial](network-tutorial-macvlan.md)
\ No newline at end of file
diff --git a/content/network/network-tutorial-macvlan.md b/content/network/network-tutorial-macvlan.md
index 7ac446c0b5..ab5bafdd1e 100644
--- a/content/network/network-tutorial-macvlan.md
+++ b/content/network/network-tutorial-macvlan.md
@@ -68,7 +68,7 @@ on your network, your container appears to be physically attached to the network
 3.  Inspect the `my-macvlan-alpine` container and notice the `MacAddress` key
     within the `Networks` key:
 
-    ```none
+    ```console
     $ docker container inspect my-macvlan-alpine
 
     ...truncated...
@@ -162,7 +162,7 @@ be physically attached to the network.
 3.  Inspect the `my-second-macvlan-alpine` container and notice the `MacAddress`
     key within the `Networks` key:
 
-    ```none
+    ```console
     $ docker container inspect my-second-macvlan-alpine
 
     ...truncated...
@@ -217,10 +217,6 @@ be physically attached to the network.
     ```
 
 ## Other networking tutorials
-
-Now that you have completed the networking tutorial for `macvlan` networks,
-you might want to run through these other networking tutorials:
-
 - [Standalone networking tutorial](network-tutorial-standalone.md)
 - [Overlay networking tutorial](network-tutorial-overlay.md)
 - [Host networking tutorial](network-tutorial-host.md)
\ No newline at end of file
diff --git a/content/network/network-tutorial-overlay.md b/content/network/network-tutorial-overlay.md
index 5d5c684587..a139dc9027 100644
--- a/content/network/network-tutorial-overlay.md
+++ b/content/network/network-tutorial-overlay.md
@@ -168,7 +168,9 @@ connect a service to each of them.
     service will publish port 80 to the outside world. All of the service
     task containers can communicate with each other without opening any ports.
 
-    > **Note**: Services can only be created on a manager.
+    > **Note**
+    >
+    > Services can only be created on a manager.
 
     ```console
     $ docker service create \
@@ -222,7 +224,9 @@ connect a service to each of them.
     `nginx-net-2` and notice that all the service task containers are connected
     to it.
 
-    > **Note**: Even though overlay networks are automatically created on swarm
+    > **Note**
+    >
+    > Even though overlay networks are automatically created on swarm
     > worker nodes as needed, they are not automatically removed.
 
 8.  Clean up the service and the networks. From `manager`, run the following
@@ -369,6 +373,8 @@ example also uses Linux hosts, but the same commands work on Windows.
     fb635f5ece59563e7b8b99556f816d24e6949a5f6a5b1fbd92ca244db17a4342
     ```
 
+    > **Note**
+    >
     > Automatic DNS container discovery only works with unique container names.
 
 6. On `host2`, verify that `test-net` was created (and has the same NETWORK ID as `test-net` on `host1`):
@@ -455,8 +461,8 @@ need to have Docker installed and running.
     The default `bridge` network is listed, along with `host` and `none`. The
     latter two are not fully-fledged networks, but are used to start a container
     connected directly to the Docker daemon host's networking stack, or to start
-    a container with no network devices. **This tutorial will connect two
-    containers to the `bridge` network.**
+    a container with no network devices. This tutorial will connect two
+    containers to the `bridge` network.
 
 2.  Start two `alpine` containers running `ash`, which is Alpine's default shell
     rather than `bash`. The `-dit` flags mean to start the container detached
@@ -634,9 +640,6 @@ learn about user-defined bridge networks, continue to the
 
 ## Other networking tutorials
 
-Now that you have completed the networking tutorials for overlay networks,
-you might want to run through these other networking tutorials:
-
 - [Host networking tutorial](network-tutorial-host.md)
 - [Standalone networking tutorial](network-tutorial-standalone.md)
 - [Macvlan networking tutorial](network-tutorial-macvlan.md)
\ No newline at end of file
diff --git a/content/network/network-tutorial-standalone.md b/content/network/network-tutorial-standalone.md
index 80d63f0f01..4059c8b3e8 100644
--- a/content/network/network-tutorial-standalone.md
+++ b/content/network/network-tutorial-standalone.md
@@ -9,8 +9,8 @@ For networking with swarm services, see
 [Networking with swarm services](network-tutorial-overlay.md). If you need to
 learn more about Docker networking in general, see the [overview](index.md).
 
-This topic includes three different tutorials. You can run each of them on
-Linux, Windows, or a Mac, but for the last two, you need a second Docker
+This topic includes two different tutorials. You can run each of them on
+Linux, Windows, or a Mac, but for the last one, you need a second Docker
 host running elsewhere.
 
 - [Use the default bridge network](#use-the-default-bridge-network) demonstrates
@@ -49,8 +49,8 @@ need to have Docker installed and running.
     The default `bridge` network is listed, along with `host` and `none`. The
     latter two are not fully-fledged networks, but are used to start a container
     connected directly to the Docker daemon host's networking stack, or to start
-    a container with no network devices. **This tutorial will connect two
-    containers to the `bridge` network.**
+    a container with no network devices. This tutorial will connect two
+    containers to the `bridge` network.
 
 2.  Start two `alpine` containers running `ash`, which is Alpine's default shell
     rather than `bash`. The `-dit` flags mean to start the container detached
@@ -433,7 +433,7 @@ connected to both networks.
 
 5.  On user-defined networks like `alpine-net`, containers can not only
     communicate by IP address, but can also resolve a container name to an IP
-    address. This capability is called **automatic service discovery**. Let's
+    address. This capability is called automatic service discovery. Let's
     connect to `alpine1` and test this out. `alpine1` should be able to resolve
     `alpine2` and `alpine4` (and `alpine1`, itself) to IP addresses.
     
@@ -615,9 +615,6 @@ connected to both networks.
 
 ## Other networking tutorials
 
-Now that you have completed the networking tutorials for standalone containers,
-you might want to run through these other networking tutorials:
-
 - [Host networking tutorial](network-tutorial-host.md)
 - [Overlay networking tutorial](network-tutorial-overlay.md)
 - [Macvlan networking tutorial](network-tutorial-macvlan.md)
diff --git a/content/network/packet-filtering-firewalls.md b/content/network/packet-filtering-firewalls.md
index 6d93db4072..259ef41f9c 100644
--- a/content/network/packet-filtering-firewalls.md
+++ b/content/network/packet-filtering-firewalls.md
@@ -19,7 +19,7 @@ describes how to achieve that, and what caveats you need to be aware of.
 
 ## Add iptables policies before Docker's rules
 
-Docker installs two custom iptables chains named `DOCKER-USER` and `DOCKER`,
+Docker installs two custom `iptables` chains named `DOCKER-USER` and `DOCKER`,
 and it ensures that incoming packets are always checked by these two chains
 first. These chains are part of the `FORWARD` chain.
 
@@ -68,7 +68,7 @@ following rule restricts external access from all IP addresses except `192.168.1
 $ iptables -I DOCKER-USER -i ext_if ! -s 192.168.1.1 -j DROP
 ```
 
-Please note that you will need to change `ext_if` to correspond with your
+You will need to change `ext_if` to correspond with your
 host's actual external interface. You could instead allow connections from a
 source subnet. The following rule only allows access from the subnet `192.168.1.0/24`:
 
@@ -153,7 +153,7 @@ $ docker network create mybridge \
   -o "com.docker.network.bridge.host_binding_ipv4=127.0.0.1"
 ```
 
-## Integration with Firewalld
+## Integration with firewalld
 
 If you are running Docker with [firewalld](https://firewalld.org)
 on your system with `--iptables` enabled, Docker automatically creates a `firewalld`