From d156a9bfa808a83194c0626f2290f51900439bae Mon Sep 17 00:00:00 2001 From: David Ward Date: Mon, 24 Jul 2023 05:15:36 -0400 Subject: [PATCH] network: Fix terminology for Macvlan and IPvlan network drivers (#17776) * network: Replace "damage" with "degrade" The word "damage" here is rather misleading, as it suggests physical harm to networking equipment. * network: Format "802.1Q" correctly This refers to an IEEE 802.1 Working Group standard, instead of an amendment (such as 802.1ad), so the letter is always capitalized. See "project naming" at https://1.ieee802.org. --- network/drivers/ipvlan.md | 12 ++++++------ network/drivers/macvlan.md | 8 ++++---- network/network-tutorial-macvlan.md | 10 +++++----- 3 files changed, 15 insertions(+), 15 deletions(-) diff --git a/network/drivers/ipvlan.md b/network/drivers/ipvlan.md index da48971b10..42d9da0b79 100644 --- a/network/drivers/ipvlan.md +++ b/network/drivers/ipvlan.md @@ -155,12 +155,12 @@ $ 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 CAM table pressure in ToR switches, one MAC per port and MAC exhaustion on a -host's parent NIC to name a few. The 802.1q trunk scenario looks the same. Both +host's parent NIC to name a few. The 802.1Q trunk scenario looks the same. Both modes adhere to tagging standards and have seamless integration with the physical network for underlay integration and hardware vendor plugin integrations. @@ -272,10 +272,10 @@ $ docker run --net=ipvlan114 --ip=192.168.114.11 -it --rm alpine /bin/sh A key takeaway is, operators have the ability to map their physical network into their virtual network for integrating containers into their environment with no -operational overhauls required. NetOps drops an 802.1q trunk into the +operational overhauls required. NetOps drops an 802.1Q trunk into the Docker host. That virtual link would be the `-o parent=` passed in the network creation. For untagged (non-VLAN) links, it is as simple as `-o parent=eth0` or -for 802.1q trunks with VLAN IDs each network gets mapped to the corresponding +for 802.1Q trunks with VLAN IDs each network gets mapped to the corresponding VLAN/Subnet from the network. An example being, NetOps provides VLAN ID and the associated subnets for VLANs @@ -510,7 +510,7 @@ $ docker run --net=ipvlan140 --ip=192.168.140.10 -it --rm alpine /bin/sh ## 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 @@ -581,7 +581,7 @@ 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 diff --git a/network/drivers/macvlan.md b/network/drivers/macvlan.md index 467a0ddf84..1eb26b76f1 100644 --- a/network/drivers/macvlan.md +++ b/network/drivers/macvlan.md @@ -20,7 +20,7 @@ isolate your Macvlan networks using different physical network interfaces. Keep the following things in mind: -- You may unintentionally damage your network due to IP address +- You may unintentionally degrade your network due to IP address exhaustion or to "VLAN spread", a situation that occurs when you have an inappropriately large number of unique MAC addresses in your network. @@ -43,12 +43,12 @@ The following table describes the driver-specific options that you can pass to ## Create a Macvlan network -When you create a Macvlan network, it can either be in bridge mode or 802.1q +When you create a Macvlan network, it can either be in bridge mode or 802.1Q trunk bridge mode. - In bridge mode, Macvlan traffic goes through a physical device on the host. -- In 802.1q trunk bridge mode, traffic goes through an 802.1q sub-interface +- In 802.1Q trunk bridge mode, traffic goes through an 802.1Q sub-interface which Docker creates on the fly. This allows you to control routing and filtering at a more granular level. @@ -78,7 +78,7 @@ $ docker network create -d macvlan \ -o parent=eth0 macnet32 ``` -### 802.1q trunk bridge mode +### 802.1Q trunk bridge mode If you specify a `parent` interface name with a dot included, such as `eth0.50`, Docker interprets that as a sub-interface of `eth0` and creates the sub-interface diff --git a/network/network-tutorial-macvlan.md b/network/network-tutorial-macvlan.md index b1a9d6cf1e..16a379794d 100644 --- a/network/network-tutorial-macvlan.md +++ b/network/network-tutorial-macvlan.md @@ -1,7 +1,7 @@ --- title: Networking using a macvlan network -description: Tutorials for networking using a macvlan bridge network and 802.1q trunk bridge network -keywords: networking, macvlan, 802.1q, standalone +description: Tutorials for networking using a macvlan bridge network and 802.1Q trunk bridge network +keywords: networking, macvlan, 802.1Q, standalone --- This series of tutorials deals with networking standalone containers which @@ -13,7 +13,7 @@ to the appropriate container. For other networking topics, see the ## Goal The goal of these tutorials is to set up a bridged `macvlan` network and attach -a container to it, then set up an 802.1q trunked `macvlan` network and attach a +a container to it, then set up an 802.1Q trunked `macvlan` network and attach a container to it. ## Prerequisites @@ -119,9 +119,9 @@ on your network, your container appears to be physically attached to the network $ docker network rm my-macvlan-net ``` -## 802.1q trunked bridge example +## 802.1Q trunked bridge example -In the 802.1q trunked bridge example, your traffic flows through a sub-interface +In the 802.1Q trunked bridge example, your traffic flows through a sub-interface of `eth0` (called `eth0.10`) and Docker routes traffic to your container using its MAC address. To network devices on your network, your container appears to be physically attached to the network.