Deployed 40831f1 to dev with MkDocs 1.5.3 and mike 1.1.2

dev/architecture/fabric/index.html

@@ -1370,15 +1370,15 @@ <h3 id="spine-leaf">Spine-Leaf</h3>
 underlay network.</p>
 <h2 id="overlay-network">Overlay Network</h2>
 <p>The overlay network runs on top the underlay network to create a virtual network. The overlay network isolates control
-and data plane traffic between different virtual networks and the underlay network. Visualization is achieved in the
+and data plane traffic between different virtual networks and the underlay network. Virtualization is achieved in the
 Hedgehog Fabric by encapsulating workload traffic over VXLAN tunnels that are source and terminated on the leaf switches
 in the network. The fabric uses BGP-EVPN/VXLAN to enable the creation and management of virtual networks on top of the
 physical one. The fabric supports multiple virtual networks over the same underlay network to support multi-tenancy.
 Each virtual network in the Hedgehog Fabric is identified by a <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr>. The following subsections contain a high-level
 overview of how VPCs are implemented in the Hedgehog Fabric and its associated objects.</p>
 <h2 id="vpc"><abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr></h2>
-<p>The previous subsections have described what a <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr> is, and how to attach workloads to a specific <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr>. Here comes a
-description of how VPCs are actually implemented on the network to provide the view of a private network.</p>
+<p>The previous subsections have described what a <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr> is, and how to attach workloads to a specific <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr>. The following bullet points
+describe how VPCs are actually implemented in the network to ensure a private view the network.</p>
 <ul>
 <li>Each <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr> is modeled as a VRF on each switch where there are <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr> attachments defined for this <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr>. The VRF is allocated
   its own VNI. The VRF is local to each switch and the VNI is global for the entire fabric. By mapping the VRF to a VNI
@@ -1412,7 +1412,7 @@ <h2 id="vpc-peering"><abbr title="Virtual Private Cloud, similar to the public c
   attached workloads, the fabric automatically allocates a pair of ports on the switch to route traffic between these
   VRFs using static routes. This is required because of limitations in the underlying platform. The net result of these
   limitations is that the bandwidth between these 2 VPCs is limited by the bandwidth of the loopback interfaces
-  allocated on the switch.</li>
+  allocated on the switch. Traffic between the peered VPCs will not leave the switch that connects them.</li>
 <li>Remote Peering: Remote peering is implemented using a dedicated peering switch/switches which is used as a rendezvous
   point for the 2 <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr>'s in the fabric. The set of switches to be used for peering is determined by configuration in the
   peering policy. When a remote peering policy is applied for a pair of VPCs, the VRFs corresponding to these VPCs on
@@ -1427,7 +1427,7 @@ <h2 id="vpc-peering"><abbr title="Virtual Private Cloud, similar to the public c
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">May 6, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">July 2, 2024</span>
 
         <br>
         Created:

dev/reference/profiles/index.html

@@ -1387,7 +1387,7 @@
 
 
 <h1 id="switch-profiles-catalog">Switch Profiles Catalog</h1>
-<p>The following is a list of all supported switches. Please, make sure to use correct version of documentation to get an
+<p>The following is a list of all supported switches. Please, make sure to use the version of documentation that matches your environment to get an
 up-to-date list of supported switches, their features and port naming scheme.</p>
 <h2 id="celestica-ds3000">Celestica DS3000</h2>
 <p>Profile Name (to use in switch.spec.profile): <strong>celestica-ds3000</strong></p>
@@ -5102,7 +5102,7 @@ <h2 id="virtual-switch">Virtual Switch</h2>
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">June 5, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">July 2, 2024</span>
 
         <br>
         Created:

dev/user-guide/connections/index.html

@@ -1467,8 +1467,8 @@
 <h1 id="connections">Connections</h1>
 <p>The <code>Connection</code> object represents logical and physical connections between any devices in the Fabric (<code>Switch</code>,
 <code>Server</code> and <code>External</code> objects). It's needed to define all connections between the devices in the Wiring Diagram.</p>
-<p>All connections referencing some switch and device ports. Only port naming defined by switch profiles could be used in
-the wiring diagram for thr switches, NOS (or any other) port names aren't supported. Server ports aren't validated by
+<p>All connections referencing some switch and device ports. Only port naming defined by switch profiles can be used in
+the wiring diagram for the switches, NOS (or any other) port names aren't supported. Server ports aren't validated by
 the Fabric API other than for uniqueness. See the <a href="../profiles/">Switch Profiles and Port Naming</a> section
 for more details.</p>
 <p>There are multiple types of connections.</p>
@@ -1696,7 +1696,7 @@ <h3 id="external"><abbr title="Definition of the &quot;external system&quot; to
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">June 5, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">July 3, 2024</span>
 
         <br>
         Created:

dev/user-guide/external/index.html

@@ -1549,14 +1549,16 @@ <h2 id="overview">Overview</h2>
 <p><abbr title="Definition of the &quot;external system&quot; to peer with (could be one or multiple devices such as edge/provider routers)">External</abbr> Peering is only available on the switch devices that are capable for sub-interfaces.</p>
 </div>
 <h3 id="connect-border-leaf-to-edge-device">Connect Border Leaf to Edge device</h3>
-<p>In order to distinguish <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr> traffic, an Edge device should be able to:
-- Set up BGP IPv4 to advertise and receive routes from the Fabric
-- Connect to a Fabric Border Leaf over VLAN
-- Be able to mark egress routes towards the Fabric with BGP Communities
-- Be able to filter ingress routes from the Fabric by BGP Communities</p>
+<p>In order to distinguish <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr> traffic, an Edge device should be able to:</p>
+<ul>
+<li>Set up BGP IPv4 to advertise and receive routes from the Fabric</li>
+<li>Connect to a Fabric Border Leaf over VLAN</li>
+<li>Be able to mark egress routes towards the Fabric with BGP Communities</li>
+<li>Be able to filter ingress routes from the Fabric by BGP Communities</li>
+</ul>
 <p>All other filtering and processing of L3 Routed Fabric traffic should be done on the Edge devices.</p>
 <h3 id="control-plane">Control Plane</h3>
-<p>Fabric is sharing <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr> routes with Edge devices via BGP. Peering is done over VLAN in IPv4 Unicast AFI/SAFI.</p>
+<p>The Fabric shares <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr> routes with Edge devices via BGP. Peering is done over VLAN in IPv4 Unicast AFI/SAFI.</p>
 <h3 id="data-plane">Data Plane</h3>
 <p><abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr> L3 routable traffic will be tagged with VLAN and sent to Edge device. Later processing of <abbr title="Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP">VPC</abbr> traffic
 (NAT, PBR, etc) should happen on Edge devices.</p>
@@ -1767,7 +1769,7 @@ <h3 id="example-edge-side-bgp-configuration-based-on-sonic-os">Example Edge side
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">May 7, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">July 3, 2024</span>
 
         <br>
         Created:

dev/user-guide/shrink-expand/index.html

@@ -1278,10 +1278,10 @@ <h1 id="fabric-shrinkexpand">Fabric Shrink/Expand</h1>
 <p>This section provides a brief overview of how to add or remove switches within the fabric using Hedgehog Fabric API, and
 how to manage connections between them.</p>
 <p>Manipulating API objects is done with the assumption that target devices are correctly cabeled and connected.</p>
-<p>This article operates terms that can be found in the <a href="../../concepts/overview/">Hedgehog Concepts</a>, the <a href="../overview/">User
+<p>This article uses terms that can be found in the <a href="../../concepts/overview/">Hedgehog Concepts</a>, the <a href="../overview/">User
 Guide</a> documentation, and the <a href="../../reference/api/">Fabric API</a> reference.</p>
 <h3 id="add-a-switch-to-the-existing-fabric">Add a switch to the existing fabric</h3>
-<p>To be added to the Hedgehog Fabric, a switch should have a corresponding <code>Switch</code> object. An example on how to define
+<p>In order to be added to the Hedgehog Fabric, a switch should have a corresponding <code>Switch</code> object. An example on how to define
 this object is available in the <a href="../devices/">User Guilde</a>.</p>
 <div class="admonition note">
 <p class="admonition-title">Note</p>
@@ -1322,7 +1322,7 @@ <h3 id="remove-a-switch-from-the-existing-fabric">Remove a switch from the exist
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">May 6, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">July 2, 2024</span>
 
         <br>
         Created:

dev/vlab/demo/index.html

@@ -1441,14 +1441,14 @@ <h2 id="creating-and-attaching-vpcs">Creating and attaching VPCs</h2>
 </span><span id="__span-2-6"><a id="__codelineno-2-6" name="__codelineno-2-6" href="#__codelineno-2-6"></a><span class="go">spine-01   spine         VS-04           16m       3          3          v0.23.0</span>
 </span><span id="__span-2-7"><a id="__codelineno-2-7" name="__codelineno-2-7" href="#__codelineno-2-7"></a><span class="go">spine-02   spine         VS-05           18m       4          4          v0.23.0</span>
 </span></code></pre></div>
-<p>In this example, the values in columns <code>APPLIED</code> and <code>APPLIEDG</code> are equal which means that the requested configuration
+<p>In this example, the values in columns <code>APPLIEDG</code> and <code>CURRENTG</code> are equal which means that the requested configuration
 has been applied.</p>
 <h2 id="setting-up-networking-on-test-servers">Setting up networking on test servers</h2>
 <p>You can use <code>hhfab vlab ssh</code> on the host to SSH into the test servers and configure networking there. For example, for
 both <code>server-01</code> (MCLAG attached to both <code>leaf-01</code> and <code>leaf-02</code>) we need to configure a bond with a VLAN on top of it
 and for the <code>server-05</code> (single-homed unbundled attached to <code>leaf-03</code>) we need to configure just a VLAN and they both
 will get an IP address from the DHCP server. You can use the <code>ip</code> command to configure networking on the servers or use
-the little helper preinstalled by Fabricator on test servers.</p>
+the little helper preinstalled by Fabricator on test servers, <code>hhnet</code>.</p>
 <p>For <code>server-01</code>:</p>
 <div class="language-console highlight"><pre><span></span><code><span id="__span-3-1"><a id="__codelineno-3-1" name="__codelineno-3-1" href="#__codelineno-3-1"></a><span class="gp">core@server-01 ~ $ </span>hhnet<span class="w"> </span>cleanup
 </span><span id="__span-3-2"><a id="__codelineno-3-2" name="__codelineno-3-2" href="#__codelineno-3-2"></a><span class="gp">core@server-01 ~ $ </span>hhnet<span class="w"> </span>bond<span class="w"> </span><span class="m">1001</span><span class="w"> </span>enp2s1<span class="w"> </span>enp2s2
@@ -1627,7 +1627,7 @@ <h2 id="using-vpcs-with-overlapping-subnets">Using VPCs with overlapping subnets
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">July 2, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">July 3, 2024</span>
 
         <br>
         Created: