From 118ec358c0c7fdfd44a70e4a757fa47362219163 Mon Sep 17 00:00:00 2001 From: Lasse Bang Mikkelsen Date: Thu, 4 Jul 2019 17:28:25 +0200 Subject: [PATCH] Fixes #3324: Doc incorrectly states child devices shown as non-racked --- docs/core-functionality/devices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core-functionality/devices.md b/docs/core-functionality/devices.md index 51486f7c1..d170b374e 100644 --- a/docs/core-functionality/devices.md +++ b/docs/core-functionality/devices.md @@ -95,7 +95,7 @@ Pass-through ports can also be used to model "bump in the wire" devices, such as ### Device Bays -Device bays represent the ability of a device to house child devices. For example, you might install four blade servers into a 2U chassis. The chassis would appear in the rack elevation as a 2U device with four device bays. Each server within it would be defined as a 0U device installed in one of the device bays. Child devices do not appear within rack elevations, but they are included in the "Non-Racked Devices" list within the rack view. +Device bays represent the ability of a device to house child devices. For example, you might install four blade servers into a 2U chassis. The chassis would appear in the rack elevation as a 2U device with four device bays. Each server within it would be defined as a 0U device installed in one of the device bays. Child devices do not appear within rack elevations or the "Non-Racked Devices" list within the rack view. Child devices are first-class Devices in their own right: that is, fully independent managed entities which don't share any control plane with the parent. Just like normal devices, child devices have their own platform (OS), role, tags, and interfaces. You cannot create a LAG between interfaces in different child devices.