diff --git a/dev/install-upgrade/upgrade/index.html b/dev/install-upgrade/upgrade/index.html
index 645305e..23c58d0 100644
--- a/dev/install-upgrade/upgrade/index.html
+++ b/dev/install-upgrade/upgrade/index.html
@@ -97,7 +97,7 @@
     <div data-md-component="skip">
       
         
-        <a href="#upgrading-from-alpha-7-to-beta-1" class="md-skip">
+        <a href="#upgrade" class="md-skip">
           Skip to content
         </a>
       
@@ -652,15 +652,49 @@
     <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
       
         <li class="md-nav__item">
-  <a href="#control-node" class="md-nav__link">
+  <a href="#upgrades-from-beta-1-onwards" class="md-nav__link">
     <span class="md-ellipsis">
-      Control Node
+      Upgrades from Beta-1 onwards
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Upgrades from Beta-1 onwards">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#init-hhfab-dir-from-the-running-installation" class="md-nav__link">
+    <span class="md-ellipsis">
+      Init hhfab dir from the running installation
     </span>
   </a>
   
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
         <li class="md-nav__item">
+  <a href="#upgrade-from-alpha-7-to-beta-1" class="md-nav__link">
+    <span class="md-ellipsis">
+      Upgrade from Alpha-7 to Beta-1
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Upgrade from Alpha-7 to Beta-1">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#control-node" class="md-nav__link">
+    <span class="md-ellipsis">
+      Control Node
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
   <a href="#management-network" class="md-nav__link">
     <span class="md-ellipsis">
       Management Network
@@ -668,8 +702,8 @@
   </a>
   
 </li>
-      
-        <li class="md-nav__item">
+        
+          <li class="md-nav__item">
   <a href="#install-switch-vendor-onie" class="md-nav__link">
     <span class="md-ellipsis">
       Install Switch Vendor ONIE
@@ -677,8 +711,8 @@
   </a>
   
 </li>
-      
-        <li class="md-nav__item">
+        
+          <li class="md-nav__item">
   <a href="#changes-to-the-wiring-diagram" class="md-nav__link">
     <span class="md-ellipsis">
       Changes to the Wiring Diagram
@@ -686,8 +720,8 @@
   </a>
   
 </li>
-      
-        <li class="md-nav__item">
+        
+          <li class="md-nav__item">
   <a href="#install-the-control-node" class="md-nav__link">
     <span class="md-ellipsis">
       Install The Control Node
@@ -695,14 +729,19 @@
   </a>
   
 </li>
-      
-        <li class="md-nav__item">
+        
+          <li class="md-nav__item">
   <a href="#install-nos-using-onie-nos-install-option" class="md-nav__link">
     <span class="md-ellipsis">
       Install NOS using ONIE NOS Install Option
     </span>
   </a>
   
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
     </ul>
@@ -1320,15 +1359,49 @@
     <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
       
         <li class="md-nav__item">
-  <a href="#control-node" class="md-nav__link">
+  <a href="#upgrades-from-beta-1-onwards" class="md-nav__link">
     <span class="md-ellipsis">
-      Control Node
+      Upgrades from Beta-1 onwards
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Upgrades from Beta-1 onwards">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#init-hhfab-dir-from-the-running-installation" class="md-nav__link">
+    <span class="md-ellipsis">
+      Init hhfab dir from the running installation
     </span>
   </a>
   
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
         <li class="md-nav__item">
+  <a href="#upgrade-from-alpha-7-to-beta-1" class="md-nav__link">
+    <span class="md-ellipsis">
+      Upgrade from Alpha-7 to Beta-1
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="Upgrade from Alpha-7 to Beta-1">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#control-node" class="md-nav__link">
+    <span class="md-ellipsis">
+      Control Node
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
   <a href="#management-network" class="md-nav__link">
     <span class="md-ellipsis">
       Management Network
@@ -1336,8 +1409,8 @@
   </a>
   
 </li>
-      
-        <li class="md-nav__item">
+        
+          <li class="md-nav__item">
   <a href="#install-switch-vendor-onie" class="md-nav__link">
     <span class="md-ellipsis">
       Install Switch Vendor ONIE
@@ -1345,8 +1418,8 @@
   </a>
   
 </li>
-      
-        <li class="md-nav__item">
+        
+          <li class="md-nav__item">
   <a href="#changes-to-the-wiring-diagram" class="md-nav__link">
     <span class="md-ellipsis">
       Changes to the Wiring Diagram
@@ -1354,8 +1427,8 @@
   </a>
   
 </li>
-      
-        <li class="md-nav__item">
+        
+          <li class="md-nav__item">
   <a href="#install-the-control-node" class="md-nav__link">
     <span class="md-ellipsis">
       Install The Control Node
@@ -1363,14 +1436,19 @@
   </a>
   
 </li>
-      
-        <li class="md-nav__item">
+        
+          <li class="md-nav__item">
   <a href="#install-nos-using-onie-nos-install-option" class="md-nav__link">
     <span class="md-ellipsis">
       Install NOS using ONIE NOS Install Option
     </span>
   </a>
   
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
       
     </ul>
@@ -1396,14 +1474,43 @@
   
 
 
-<h1 id="upgrading-from-alpha-7-to-beta-1">Upgrading from Alpha-7 to Beta-1</h1>
-<h2 id="control-node">Control Node</h2>
+<h1 id="upgrade">Upgrade</h1>
+<h2 id="upgrades-from-beta-1-onwards">Upgrades from Beta-1 onwards</h2>
+<p>Starting with Beta-1 release and onwards, the upgrade process is more streamlined and fully automated. The control node
+is upgraded in place and the agents/switches is upgraded using the control node.</p>
+<p>In order to apply the upgrade, the following steps need to be followed:</p>
+<ul>
+<li>use the <code>hhfab</code> directory from the initial deployment or init the new one using the configs from the running installation</li>
+<li>run <code>hhfab build --mode=manual</code> to generate fully self-contained (airgap) upgrade package</li>
+<li>for control node named <code>control-1</code> it will be <code>result/control-1-install.tgz</code></li>
+<li>upload it to the control node (e.g. using <code>scp</code>)</li>
+<li>unpack and run <code>hhfab-recipe control upgrade</code> from the resulting directory</li>
+</ul>
+<div class="language-bash highlight"><pre><span></span><code><span id="__span-0-1"><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a>tar<span class="w"> </span>xzf<span class="w"> </span>control-1-install.tgz
+</span><span id="__span-0-2"><a id="__codelineno-0-2" name="__codelineno-0-2" href="#__codelineno-0-2"></a><span class="nb">cd</span><span class="w"> </span>control-1-install
+</span><span id="__span-0-3"><a id="__codelineno-0-3" name="__codelineno-0-3" href="#__codelineno-0-3"></a>./hhfab-recipe<span class="w"> </span>control<span class="w"> </span>upgrade
+</span></code></pre></div>
+<p>It'll do all necessary steps to upgrade the control node and the agents/switches. Resulting version could be checked
+using <code>kubectl -n fab get fab/default -o=jsonpath='{.status.versions.fabricator.controller}'</code> and compare to the
+fabricator version in the release notes.</p>
+<p>Upgrade process is idempotent and can be run multiple times without any issues.</p>
+<h3 id="init-hhfab-dir-from-the-running-installation">Init hhfab dir from the running installation</h3>
+<p>If the original <code>hhfab</code> directory is no longer available, it is possible to export the current configuration from the
+running installation and init the new <code>hhfab</code> directory with it.</p>
+<div class="language-bash highlight"><pre><span></span><code><span id="__span-1-1"><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a><span class="c1"># on a control node</span>
+</span><span id="__span-1-2"><a id="__codelineno-1-2" name="__codelineno-1-2" href="#__codelineno-1-2"></a>kubectl<span class="w"> </span>hhfab<span class="w"> </span>config<span class="w"> </span><span class="nb">export</span><span class="w"> </span>&gt;<span class="w"> </span>fab.yaml
+</span><span id="__span-1-3"><a id="__codelineno-1-3" name="__codelineno-1-3" href="#__codelineno-1-3"></a>
+</span><span id="__span-1-4"><a id="__codelineno-1-4" name="__codelineno-1-4" href="#__codelineno-1-4"></a><span class="c1"># on a node with internet access using the exported config</span>
+</span><span id="__span-1-5"><a id="__codelineno-1-5" name="__codelineno-1-5" href="#__codelineno-1-5"></a>hhfab<span class="w"> </span>init<span class="w"> </span>-c<span class="w"> </span>fab.yaml
+</span></code></pre></div>
+<h2 id="upgrade-from-alpha-7-to-beta-1">Upgrade from Alpha-7 to Beta-1</h2>
+<h3 id="control-node">Control Node</h3>
 <p>Ensure the hardware that is to be used for the control node meets the <a href="../requirements/#control-node">system requirements</a>. The upgrade process is destructive of the host, so ensure all data needed is removed from the selected server before the upgrade is started.</p>
-<h2 id="management-network">Management Network</h2>
+<h3 id="management-network">Management Network</h3>
 <p>Beta-1 uses the RJ-45 management ports of the switches instead of front panel ports. A simple management network will need to be in place and cabled before the install of Beta-1. The control node will run a DHCP server on this network and must be the sole DHCP server. Do not co-mingle other services or equipment on this network, it is for the exclusive use of the control node and switches.</p>
-<h2 id="install-switch-vendor-onie">Install Switch Vendor ONIE</h2>
+<h3 id="install-switch-vendor-onie">Install Switch Vendor ONIE</h3>
 <p>Beta-1 uses the switch vendor ONIE for installation of the NOS. The latest vendor provided version of ONIE is recommended to be installed. Hedgehog ONIE <strong>must not</strong> be used.</p>
-<h2 id="changes-to-the-wiring-diagram">Changes to the Wiring Diagram</h2>
+<h3 id="changes-to-the-wiring-diagram">Changes to the Wiring Diagram</h3>
 <ul>
 <li>All API versions changed from <code>v1alpha2</code> to <code>v1beta1</code></li>
 <li><code>Server[control=true]</code> object type was removed and replaced with <code>ControlNode</code> object in the <code>fabricator.githedgehog.com/v1beta1</code> API (.spec.control field removed), <code>Server</code> object only describes workload server now</li>
@@ -1412,9 +1519,9 @@ <h2 id="changes-to-the-wiring-diagram">Changes to the Wiring Diagram</h2>
 <li><code>.spec.location</code> remove from <code>Switch</code> object</li>
 <li><code>.spec.boot</code> added to <code>Switch</code> object with <code>mac</code> and <code>serial</code> fields, at least <strong>one</strong> of them is required to identify switch for installation</li>
 </ul>
-<h2 id="install-the-control-node">Install The Control Node</h2>
+<h3 id="install-the-control-node">Install The Control Node</h3>
 <p>Follow the <a href="../install/#build-control-node-configuration-and-installer">instructions</a> for installing the Beta-1 Fabric on a control node.</p>
-<h2 id="install-nos-using-onie-nos-install-option">Install NOS using ONIE NOS Install Option</h2>
+<h3 id="install-nos-using-onie-nos-install-option">Install NOS using ONIE NOS Install Option</h3>
 <p>As the switches boot up, select the ONIE option from the grub screen. From there select the "NOS Install" option. The install option will cause the switch to begin searching for installation media, this media is supplied by the control node.</p>
 
 
@@ -1438,7 +1545,7 @@ <h2 id="install-nos-using-onie-nos-install-option">Install NOS using ONIE NOS In
     <span class="md-icon" title="Last update">
       <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M21 13.1c-.1 0-.3.1-.4.2l-1 1 2.1 2.1 1-1c.2-.2.2-.6 0-.8l-1.3-1.3c-.1-.1-.2-.2-.4-.2m-1.9 1.8-6.1 6V23h2.1l6.1-6.1zM12.5 7v5.2l4 2.4-1 1L11 13V7zM11 21.9c-5.1-.5-9-4.8-9-9.9C2 6.5 6.5 2 12 2c5.3 0 9.6 4.1 10 9.3-.3-.1-.6-.2-1-.2s-.7.1-1 .2C19.6 7.2 16.2 4 12 4c-4.4 0-8 3.6-8 8 0 4.1 3.1 7.5 7.1 7.9l-.1.2z"/></svg>
     </span>
-    <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">November 25, 2024</span>
+    <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">December 19, 2024</span>
   </span>
 
     
diff --git a/dev/release-notes/index.html b/dev/release-notes/index.html
index 5e60dfc..da78c8b 100644
--- a/dev/release-notes/index.html
+++ b/dev/release-notes/index.html
@@ -1145,6 +1145,48 @@
     </label>
     <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
       
+        <li class="md-nav__item">
+  <a href="#2409" class="md-nav__link">
+    <span class="md-ellipsis">
+      24.09
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="24.09">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#device-support" class="md-nav__link">
+    <span class="md-ellipsis">
+      Device Support
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#fabric-lifecycle-management" class="md-nav__link">
+    <span class="md-ellipsis">
+      Fabric Lifecycle Management
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#software-versions" class="md-nav__link">
+    <span class="md-ellipsis">
+      Software versions
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
         <li class="md-nav__item">
   <a href="#beta-1" class="md-nav__link">
     <span class="md-ellipsis">
@@ -1156,7 +1198,7 @@
       <ul class="md-nav__list">
         
           <li class="md-nav__item">
-  <a href="#device-support" class="md-nav__link">
+  <a href="#device-support_1" class="md-nav__link">
     <span class="md-ellipsis">
       Device support
     </span>
@@ -1207,7 +1249,7 @@
       <ul class="md-nav__list">
         
           <li class="md-nav__item">
-  <a href="#device-support_1" class="md-nav__link">
+  <a href="#device-support_2" class="md-nav__link">
     <span class="md-ellipsis">
       Device Support
     </span>
@@ -1385,6 +1427,48 @@
     </label>
     <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
       
+        <li class="md-nav__item">
+  <a href="#2409" class="md-nav__link">
+    <span class="md-ellipsis">
+      24.09
+    </span>
+  </a>
+  
+    <nav class="md-nav" aria-label="24.09">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#device-support" class="md-nav__link">
+    <span class="md-ellipsis">
+      Device Support
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#fabric-lifecycle-management" class="md-nav__link">
+    <span class="md-ellipsis">
+      Fabric Lifecycle Management
+    </span>
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#software-versions" class="md-nav__link">
+    <span class="md-ellipsis">
+      Software versions
+    </span>
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
+</li>
+      
         <li class="md-nav__item">
   <a href="#beta-1" class="md-nav__link">
     <span class="md-ellipsis">
@@ -1396,7 +1480,7 @@
       <ul class="md-nav__list">
         
           <li class="md-nav__item">
-  <a href="#device-support" class="md-nav__link">
+  <a href="#device-support_1" class="md-nav__link">
     <span class="md-ellipsis">
       Device support
     </span>
@@ -1447,7 +1531,7 @@
       <ul class="md-nav__list">
         
           <li class="md-nav__item">
-  <a href="#device-support_1" class="md-nav__link">
+  <a href="#device-support_2" class="md-nav__link">
     <span class="md-ellipsis">
       Device Support
     </span>
@@ -1529,8 +1613,28 @@
 
 
 <h1 id="release-notes">Release notes</h1>
+<h2 id="2409">24.09</h2>
+<h3 id="device-support">Device Support</h3>
+<ul>
+<li>Dell Z9332 as a spine-only switch</li>
+</ul>
+<h3 id="fabric-lifecycle-management">Fabric Lifecycle Management</h3>
+<ul>
+<li>Installer ISO builder for zero-touch control node installation</li>
+<li>CLI for exporting Wiring Diagram</li>
+<li>CLI for exporting Fabricator configs</li>
+<li>Automated update mechanism from B1 release, including airgap support</li>
+</ul>
+<h3 id="software-versions">Software versions</h3>
+<ul>
+<li>fabricator/hhfab: v0.32.1</li>
+<li>fabric: v0.58.0</li>
+<li>broadcom sonic: 4.4.0</li>
+<li>flatcar: v4081.2.0</li>
+<li>k8s (k3s): v1.31.1-k3s1</li>
+</ul>
 <h2 id="beta-1">Beta-1</h2>
-<h3 id="device-support">Device support</h3>
+<h3 id="device-support_1">Device support</h3>
 <ul>
 <li>Celestica DS4000 as a spine</li>
 </ul>
@@ -1553,7 +1657,7 @@ <h2 id="api">API</h2>
 <li>Guaranteed backward compatibility moving forward</li>
 </ul>
 <h2 id="alpha-7">Alpha-7</h2>
-<h3 id="device-support_1">Device Support</h3>
+<h3 id="device-support_2">Device Support</h3>
 <p>New devices supported by the fabric:</p>
 <ul>
 <li>
@@ -1835,7 +1939,7 @@ <h4 id="collapsed-core-topology">Collapsed Core Topology</h4>
 <p>Two ToR/LEAF switches with MCLAG server connection.</p>
 <h3 id="server-multihoming">Server multihoming</h3>
 <p>MCLAG-only.</p>
-<h3 id="device-support_2">Device support</h3>
+<h3 id="device-support_3">Device support</h3>
 <h4 id="leafs">LEAFs</h4>
 <ul>
 <li>
@@ -1909,7 +2013,7 @@ <h3 id="scale">Scale</h3>
 <li>Max <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> loopbacks per switch: 500</li>
 <li>[ <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> loopback workarounds per switch are needed for local peering when both VPCs are attached to the switch or for external peering with <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> attached on the same switch that is peering with external ]</li>
 </ul>
-<h3 id="software-versions">Software versions</h3>
+<h3 id="software-versions_1">Software versions</h3>
 <ul>
 <li>Fabric: v0.23.0</li>
 <li>Das-boot: v0.11.4</li>
@@ -2063,7 +2167,7 @@ <h2 id="alpha-1">Alpha-1</h2>
     <span class="md-icon" title="Last update">
       <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M21 13.1c-.1 0-.3.1-.4.2l-1 1 2.1 2.1 1-1c.2-.2.2-.6 0-.8l-1.3-1.3c-.1-.1-.2-.2-.4-.2m-1.9 1.8-6.1 6V23h2.1l6.1-6.1zM12.5 7v5.2l4 2.4-1 1L11 13V7zM11 21.9c-5.1-.5-9-4.8-9-9.9C2 6.5 6.5 2 12 2c5.3 0 9.6 4.1 10 9.3-.3-.1-.6-.2-1-.2s-.7.1-1 .2C19.6 7.2 16.2 4 12 4c-4.4 0-8 3.6-8 8 0 4.1 3.1 7.5 7.1 7.9l-.1.2z"/></svg>
     </span>
-    <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">October 24, 2024</span>
+    <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">December 19, 2024</span>
   </span>
 
     
diff --git a/dev/search/search_index.json b/dev/search/search_index.json
index 07183c1..e7c097b 100644
--- a/dev/search/search_index.json
+++ b/dev/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Introduction","text":"<p>The Hedgehog Open Network Fabric is an open networking platform that brings the user experience enjoyed by so many in the public cloud to private environments. It comes without vendor lock-in.</p> <p>The Fabric is built around the concept of VPCs (Virtual Private Clouds), similar to public cloud offerings. It provides a multi-tenant API to define the user intent on network isolation and connectivity, which is automatically transformed into configuration for switches and software appliances.</p> <p>You can read more about its concepts and architecture in the documentation.</p> <p>You can find out how to download and try the Fabric on the self-hosted fully virtualized lab or on hardware.</p>"},{"location":"architecture/fabric/","title":"Hedgehog Network Fabric","text":"<p>The Hedgehog Open Network Fabric is an open-source network architecture that provides connectivity between virtual and physical workloads and provides a way to achieve network isolation between different groups of workloads using standard BGP EVPN and VXLAN technology. The fabric provides a standard Kubernetes interface to manage the elements in the physical network and provides a mechanism to configure virtual networks and define attachments to these virtual networks. The Hedgehog Fabric provides isolation between different groups of workloads by placing them in different virtual networks called VPC's. To achieve this, it defines different abstractions starting from the physical network where a set of <code>Connection</code> objects defines how a physical server on the network connects to a physical switch on the fabric.</p>"},{"location":"architecture/fabric/#underlay-network","title":"Underlay Network","text":"<p>The Hedgehog Fabric currently supports two underlay network topologies.</p>"},{"location":"architecture/fabric/#collapsed-core","title":"Collapsed Core","text":"<p>A collapsed core topology is just a pair of switches connected in a MCLAG configuration with no other network elements. All workloads attach to these two switches.</p> <p></p> <p>The leaves in this setup are configured to be in a MCLAG pair and servers can either be connected to both switches as a MCLAG port channel or as orphan ports connected to only one switch. Both the leaves peer to external networks using BGP and act as gateway for workloads attached to them. The configuration of the underlay in the collapsed core is very simple and is ideal for very small deployments.</p>"},{"location":"architecture/fabric/#spine-leaf","title":"Spine-Leaf","text":"<p>A spine-leaf topology is a standard Clos network with workloads attaching to leaf switches and the spines providing connectivity between different leaves.</p> <p></p> <p>This kind of topology is useful for bigger deployments and provides all the advantages of a typical Clos network. The underlay network is established using eBGP where each leaf has a separate ASN and peers will all spines in the network. RFC7938 was used as the reference for establishing the underlay network.</p>"},{"location":"architecture/fabric/#overlay-network","title":"Overlay Network","text":"<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. 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 VPC. The following subsections contain a high-level overview of how VPCs are implemented in the Hedgehog Fabric and its associated objects.</p>"},{"location":"architecture/fabric/#vpc","title":"VPC","text":"<p>The previous subsections have described what a VPC is, and how to attach workloads to a specific VPC. The following bullet points describe how VPCs are actually implemented in the network to ensure a private view the network.</p> <ul> <li>Each VPC is modeled as a VRF on each switch where there are VPC attachments defined for this VPC. 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   and configuring an EVPN instance in each VRF, a shared L3VNI is established across the entire fabric. All VRFs   participating in this VNI can freely communicate with each other without the need for a policy. A VLAN is allocated   for each VRF which functions as an IRB VLAN for the VRF.</li> <li>The VRF created on each switch corresponding to a VPC configures a BGP instance with EVPN to advertise its locally   attached subnets and import routes from its peered VPCs. The BGP instance in the tenant VRFs does not establish   neighbor relationships and is purely used to advertise locally attached routes into the VPC (all VRFs with the same   L3VNI) across leaves in the network.</li> <li>A VPC can have multiple subnets. Each subnet in the VPC is modeled as a VLAN on the switch. The VLAN is only locally   significant and a given subnet might have different VLANs on different leaves on the network. A globally significant   VNI is assigned to each subnet. This VNI is used to extend the subnet across different leaves in the network and   provides a view of single stretched L2 domain if the applications need it.</li> <li>The Hedgehog Fabric has a built-in DHCP server which will automatically assign IP addresses to each workload depending   on the VPC it belongs to. This is achieved by configuring a DHCP relay on each of the server facing VLANs. The DHCP   server is accessible through the underlay network and is shared by all VPCs in the fabric. The inbuilt DHCP server is   capable of identifying the source VPC of the request and assigning IP addresses from a pool allocated to the VPC at   creation.</li> <li>A VPC by default cannot communicate to anyone outside the VPC and specific peering rules are required to allow   communication to external networks or to other VPCs.</li> </ul>"},{"location":"architecture/fabric/#vpc-peering","title":"VPC Peering","text":"<p>To enable communication between 2 different VPCs, one needs to configure a VPC peering policy. The Hedgehog Fabric supports two different peering modes.</p> <ul> <li>Local Peering: A local peering directly imports routes from another VPC locally. This is achieved by a simple   import route from the peer VPC. In case there are no locally attached workloads to the peer VPC the fabric   automatically creates a stub VPC for peering and imports routes from it. This allows VPCs to peer with each other   without the need for a dedicated peering leaf. If a local peering is done for a pair of VPCs which have locally   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. 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 VPC'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   the peering switch advertise default routes into their specific VRFs identified by the L3VNI. All traffic that does   not belong to the VPCs is forwarded to the peering switch which has routes to the other VPCs and gets forwarded from   there. The bandwidth limitation that exists in the local peering solution is solved here as the bandwidth between the   two VPCs is determined by the fabric cross section bandwidth.</li> </ul>"},{"location":"architecture/overview/","title":"Overview","text":"<p>Under construction.</p>"},{"location":"concepts/overview/","title":"Concepts","text":""},{"location":"concepts/overview/#introduction","title":"Introduction","text":"<p>Hedgehog Open Network Fabric is built on top of Kubernetes and uses Kubernetes API to manage its resources. It means that all user-facing APIs are Kubernetes Custom Resources (CRDs), so you can use standard Kubernetes tools to manage Fabric resources.</p> <p>Hedgehog Fabric consists of the following components:</p> <ul> <li>Fabricator - special tool to install and configure Fabric, or to run virtual labs</li> <li>Control Node - one or more Kubernetes nodes in a single cluster running Fabric software:<ul> <li>Fabric Controller - main control plane component that manages Fabric resources</li> </ul> </li> <li>Fabric Kubectl plugin (Fabric CLI) - kubectl plugin to manage Fabric resources in an easy way</li> <li>Fabric Agent - runs on every switch and manages switch configuration</li> </ul>"},{"location":"concepts/overview/#fabric-api","title":"Fabric API","text":"<p>All infrastructure is represented as a set of Fabric resource (Kubernetes CRDs) and named Wiring Diagram. With this representation, Fabric defines switches, servers, control nodes, external systems and connections between them in a single place and then uses these definitions to deploy and manage the whole infrastructure. On top of the Wiring Diagram, Fabric provides a set of APIs to manage the VPCs and the connections between them and between VPCs and External systems.</p>"},{"location":"concepts/overview/#wiring-diagram-api","title":"Wiring Diagram API","text":"<p>Wiring Diagram consists of the following resources:</p> <ul> <li>\"Devices\": describe any device in the Fabric and can be of two types:<ul> <li>Switch: configuration of the switch, containing for example: port group speeds, port breakouts, switch IP/ASN</li> <li>Server: any physical server attached to the Fabric including Control Nodes</li> </ul> </li> <li>Connection: any logical connection for devices<ul> <li>usually it's a connection between two or more ports on two different devices</li> <li>for example: MCLAG Peer Link, Unbundled/MCLAG server connections, Fabric connection between spine and leaf</li> </ul> </li> <li>VLANNamespace -&gt; non-overlapping VLAN ranges for attaching servers</li> <li>IPv4Namespace -&gt; non-overlapping IPv4 ranges for VPC subnets</li> </ul>"},{"location":"concepts/overview/#user-facing-api","title":"User-facing API","text":"<ul> <li>VPC API<ul> <li>VPC: Virtual Private Cloud, similar to a public cloud VPC, provides an isolated private network for the   resources, with support for multiple subnets, each with user-defined VLANs and optional DHCP service</li> <li>VPCAttachment: represents a specific VPC subnet assignment to the Connection object which means exact server port to a VPC binding</li> <li>VPCPeering: enables VPC-to-VPC connectivity (could be Local where VPCs are used or Remote peering on the border/mixed leaves)</li> </ul> </li> <li>External API<ul> <li>External: definition of the \"external system\" to peer with (could be one or multiple devices such as edge/provider routers)</li> <li>ExternalAttachment: configuration for a specific switch (using Connection object) describing how it connects to an external system</li> <li>ExternalPeering: provides VPC with External connectivity by exposing specific VPC subnets to the external system and allowing inbound routes from it</li> </ul> </li> </ul>"},{"location":"concepts/overview/#fabricator","title":"Fabricator","text":"<p>Installer builder and VLAB.</p> <ul> <li>Installer builder based on a preset (currently: <code>vlab</code> for virtual and <code>lab</code> for physical)<ul> <li>Main input: Wiring Diagram</li> <li>All input artifacts coming from OCI registry</li> <li>Always full airgap (everything running from private registry)</li> <li>Flatcar Linux for Control Node, generated <code>ignition.json</code></li> <li>Automatic K3s installation and private registry setup</li> <li>All components and their dependencies running in Kubernetes</li> </ul> </li> <li>Integrated Virtual Lab (VLAB) management</li> <li>Future:<ul> <li>In-cluster (control) Operator to manage all components</li> <li>Upgrades handling for everything starting Control Node OS</li> <li>Installation progress, status and retries</li> <li>Disaster recovery and backups</li> </ul> </li> </ul>"},{"location":"concepts/overview/#fabric","title":"Fabric","text":"<p>Control plane and switch agent.</p> <ul> <li>Currently Fabric is basically a single controller manager running in Kubernetes<ul> <li>It includes controllers for different CRDs and needs</li> <li>For example, auto assigning VNIs to VPCs or generating the Agent configuration</li> <li>Additionally, it's running the admission webhook for Hedgehog's CRD APIs</li> </ul> </li> <li>The Agent is watching for the corresponding Agent CRD in Kubernetes API<ul> <li>It applies the changes and saves the new configuration locally</li> <li>It reports status and information back to the API</li> <li>It can perform reinstallation and reboot of SONiC</li> </ul> </li> </ul>"},{"location":"contribute/docs/","title":"Documentation","text":""},{"location":"contribute/docs/#getting-started","title":"Getting started","text":"<p>This documentation is done using MkDocs with multiple plugins enabled. It's based on the Markdown, you can find basic syntax overview here.</p> <p>In order to contribute to the documentation, you'll need to have Git and Docker installed on your machine as well as any editor of your choice, preferably supporting Markdown preview. You can run the preview server using following command:</p> <pre><code>just serve\n</code></pre> <p>Now you can open continuously updated preview of your edits in browser at http://127.0.0.1:8000. Pages will be automatically updated while you're editing.</p> <p>Additionally you can run</p> <pre><code>just build\n</code></pre> <p>to make sure that your changes will be built correctly and doesn't break documentation.</p>"},{"location":"contribute/docs/#workflow","title":"Workflow","text":"<p>If you want to quick edit any page in the documentation, you can press the <code>Edit this page</code> icon at the top right of the page. It'll open the page in the GitHub editor. You can edit it and create a pull request with your changes.</p> <p>Please, never push to the <code>master</code> or <code>release/*</code> branches directly. Always create a pull request and wait for the review.</p> <p>Each pull request will be automatically built and preview will be deployed. You can find the link to the preview in the comments in pull request.</p>"},{"location":"contribute/docs/#repository","title":"Repository","text":"<p>Documentation is organized in per-release branches:</p> <ul> <li><code>master</code> - ongoing development, not released yet, referenced as <code>dev</code> version in the documentation</li> <li><code>release/alpha-1</code>/<code>release/alpha-2</code> - alpha releases, referenced as <code>alpha-1</code>/<code>alpha-2</code> versions in the documentation, if patches released for alpha-1, they'll be merged into <code>release/alpha-1</code> branch</li> <li><code>release/v1.0</code> - first stable release, referenced as <code>v1.0</code> version in the documentation, if patches (e.g. <code>v1.0.1</code>) released for v1.0, they'll be merged into <code>release/v1.0</code> branch</li> </ul> <p>Latest release branch is referenced as <code>latest</code> version in the documentation and will be used by default when you open the documentation.</p>"},{"location":"contribute/docs/#file-layout","title":"File layout","text":"<p>All documentation files are located in <code>docs</code> directory. Each file is a Markdown file with <code>.md</code> extension. You can create subdirectories to organize your files. Each directory can have a <code>.pages</code> file that overrides the default navigation order and titles.</p> <p>For example, top-level <code>.pages</code> in this repository looks like this:</p> <pre><code>nav:\n  - index.md\n  - getting-started\n  - concepts\n  - Wiring Diagram: wiring\n  - Install &amp; Upgrade: install-upgrade\n  - User Guide: user-guide\n  - Reference: reference\n  - Troubleshooting: troubleshooting\n  - ...\n  - release-notes\n  - contribute\n</code></pre> <p>Where you can add pages by file name like <code>index.md</code> and page title will be taked from the file (first line with <code>#</code>). Additionally, you can reference the whole directory to created nested section in navigation. You can also add custom titles by using <code>:</code> separator like <code>Wiring Diagram: wiring</code> where <code>Wiring Diagram</code> is a title and <code>wiring</code> is a file/directory name.</p> <p>More details in the MkDocs Pages plugin.</p>"},{"location":"contribute/docs/#abbreviations","title":"Abbreviations","text":"<p>You can find abbreviations in <code>includes/abbreviations.md</code> file. You can add various abbreviations there and all usages of the defined words in the documentation will get a highlight.</p> <p>For example, we have following in <code>includes/abbreviations.md</code>:</p> <pre><code>*[HHFab]: Hedgehog Fabricator - a tool for building Hedgehog Fabric\n</code></pre> <p>It'll highlight all usages of <code>HHFab</code> in the documentation and show a tooltip with the definition like this: HHFab.</p>"},{"location":"contribute/docs/#markdown-extensions","title":"Markdown extensions","text":"<p>We're using MkDocs Material theme with multiple extensions enabled. You can find detailed reference here, but here you can find some of the most useful ones.</p> <p>To view code for examples, please, check the source code of this page.</p>"},{"location":"contribute/docs/#text-formatting","title":"Text formatting","text":"<p>Text can be deleted and replacement text added. This can also be combined into onea single operation. Highlighting is also possible and comments can be added inline.</p> <p>Formatting can also be applied to blocks by putting the opening and closing tags on separate lines and adding new lines between the tags and the content.</p> <p>Keyboard keys can be written like so:</p> <p>Ctrl+Alt+Del</p> <p>Amd inline icons/emojis can be added like this:</p> <pre><code>:fontawesome-regular-face-laugh-wink:\n:fontawesome-brands-twitter:{ .twitter }\n</code></pre> <p> </p>"},{"location":"contribute/docs/#admonitions","title":"Admonitions","text":"<p>Admonitions, also known as call-outs, are an excellent choice for including side content without significantly interrupting the document flow. Different types of admonitions are available, each with a unique icon and color. Details can be found here.</p> <p>Lorem ipsum</p> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa.</p>"},{"location":"contribute/docs/#code-blocks","title":"Code blocks","text":"<p>Details can be found here.</p> <p>Simple code block with line nums and highlighted lines:</p> bubble_sort.py<pre><code>def bubble_sort(items):\n    for i in range(len(items)):\n        for j in range(len(items) - 1 - i):\n            if items[j] &gt; items[j + 1]:\n                items[j], items[j + 1] = items[j + 1], items[j]\n</code></pre> <p>Code annotations:</p> <pre><code>theme:\n  features:\n    - content.code.annotate # (1)\n</code></pre> <ol> <li> I'm a code annotation! I can contain <code>code</code>, formatted     text, images, ... basically anything that can be written in Markdown.</li> </ol>"},{"location":"contribute/docs/#tabs","title":"Tabs","text":"<p>You can use Tabs to better organize content.</p> CC++ <pre><code>#include &lt;stdio.h&gt;\n\nint main(void) {\n  printf(\"Hello world!\\n\");\n  return 0;\n}\n</code></pre> <pre><code>#include &lt;iostream&gt;\n\nint main(void) {\n  std::cout &lt;&lt; \"Hello world!\" &lt;&lt; std::endl;\n  return 0;\n}\n</code></pre>"},{"location":"contribute/docs/#tables","title":"Tables","text":"Method Description <code>GET</code>      Fetch resource <code>PUT</code>  Update resource <code>DELETE</code>      Delete resource"},{"location":"contribute/docs/#diagrams","title":"Diagrams","text":"<p>You can directly include Mermaid diagrams in your Markdown files. Details can be found here.</p> <pre><code>graph LR\n  A[Start] --&gt; B{Error?};\n  B --&gt;|Yes| C[Hmm...];\n  C --&gt; D[Debug];\n  D --&gt; B;\n  B ----&gt;|No| E[Yay!];</code></pre> <pre><code>sequenceDiagram\n  autonumber\n  Alice-&gt;&gt;John: Hello John, how are you?\n  loop Healthcheck\n      John-&gt;&gt;John: Fight against hypochondria\n  end\n  Note right of John: Rational thoughts!\n  John--&gt;&gt;Alice: Great!\n  John-&gt;&gt;Bob: How about you?\n  Bob--&gt;&gt;John: Jolly good!</code></pre>"},{"location":"contribute/overview/","title":"Overview","text":"<p>Under construction.</p>"},{"location":"faq/overview/","title":"Frequently Asked Questions (FAQ)","text":""},{"location":"faq/overview/#what-is-the-hedgehog-fabric","title":"What is the Hedgehog Fabric?","text":"<p>The Hedgehog Fabric is a topology of routers arranged in a spine-leaf architecture. A spine-leaf architecture is a type of Clos network topology. In a spine-leaf architecture, the leaves are usually placed in racks and connected directly to the servers, whereas spines are connected only to leaves. In a spine-leaf architecture, the fundamental unit of connection is a layer 3 route.</p> <p>The Hedgehog Fabric is managed via Kubernetes objects and custom resource definitions.</p>"},{"location":"faq/overview/#what-are-the-advantages-of-a-spine-leaf-architecture","title":"What are the advantages of a spine-leaf architecture?","text":"<p>A spine-leaf architecture is designed to facilitate traffic that is passing between servers inside of a data center. By contrast, other architectures like core-access-aggregation facilitate traffic moving in and out of the data center. A spine-leaf architecture provides multiple paths between nodes which allows for router maintenance and resilience in the case of failures. The spine-leaf architecture allows for multiple points of egress via border leaf nodes. In a spine-leaf architecture the unit of connection is a layer 3 route. There are robust tools, queueing algorithms and hardware available to manage network traffic at layer 3. To manage the distribution of routes to switches inside the fabric a protocol such as BGP, OSPF, or IS-IS is used. </p>"},{"location":"faq/overview/#spine-leaf-architecture-diagram","title":"Spine Leaf Architecture Diagram","text":"<p>The following diagram contains Leaf and Spine routers. Servers inside of a virtual private cloud can be attached to any leaf. To allow the servers to communicate, routes are applied to leaf nodes. The traffic passing from leaf 1 to leaf 2 can travel via any spine: the leaf uses ECMP to decide which spine to use. EVPN ensures that servers inside of a VPC are reachable at layer 2 regardless of which leaf they are attached to in the Fabric. </p> <pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n    S3([Spine 3])\n    L1([Leaf 1])\n    L2([Leaf 2])\n    L3([Leaf 3])\n    L4([Leaf 4])\n    WS1[[Worload Servers]]\n    WS2[[Worload Servers]]\n    WS3[[Worload Servers]]\n    WS4[[Worload Servers]]\n\n    S1 &amp; S2 &amp; S3 ---- L1 &amp; L2 &amp; L3 &amp; L4 \n    L1 ---- WS1\n    L2 ---- WS2\n    L3 ---- WS3\n    L4 ---- WS4\n</code></pre>"},{"location":"faq/overview/#core-access-aggregation-diagram","title":"Core Access Aggregation Diagram","text":"<p>In the diagram below, the Access switches are isolated or managed by layer-2 constructs like ACLs, bridging, and VLANs. The Aggregation routers are where layer-2 traffic is promoted to layer 3. The core routers handle layer-3 traffic only. Often some form of Spanning Tree Protocol is used to avoid loops in the layer-2 domain. Loops would cripple the network as layer 2 often relies on Broadcast/Flooding for discovery. While there are multiple paths out from the workload servers to the core they are often not passing traffic due to the Spanning Tree Protocol, these disable links are shown as dotted lines.</p> <pre><code>graph TD\n    CG1((Core Router 1))\n    CG2((Core Router 2))\n    AG1([Aggregation 1])\n    AG2([Aggregation 2])\n    AG3([Aggregation 3])\n    A1[Access 1]\n    A2[Access 2]\n    A3[Access 3]\n    WS1[[Worload Servers]]\n    WS2[[Worload Servers]]\n    WS3[[Worload Servers]]\n\n    CG1 ---- AG1 &amp; AG2 &amp; AG3\n    CG2 ---- AG1 &amp; AG2 &amp; AG3\n    AG1 ---- A1 \n    AG2 ---- A2 \n    AG3 ---- A3 \n    AG1 -..- A2 &amp; A3\n    AG2 -..- A1 &amp; A3\n    AG3 -..- A1 &amp; A2\n    A1 ---- WS1\n    A2 ---- WS2\n    A3 ---- WS3\n</code></pre>"},{"location":"faq/overview/#what-does-it-mean-to-manage-my-network-with-kubernetes","title":"What does it mean to manage my network with Kubernetes?","text":"<p>A common way to manage a network is to proceed manually via the command-line interface of the equipment, or with the hardware vendor tools. Managing a small number of switches and routers this way is workable, but cumbersome, and it only gets more painful when the network grows. Managing switches and servers with Kubernetes is similar to managing pods and applications with Kubernetes: it provides assistance for deployment, scaling, and management of the network appliances.</p> <p>For example, if the administrator of a Kubernetes cluster wants to create a new Nginx pod, they write down the YAML file describing the pod name, the container image, any ports that the pod needs exposed, and what namespace to run the pod in. After the YAML file is created, a simple <code>kubectl apply -f nginx.yaml</code> is all that the administrator needs to run in order for the pod to be scheduled. </p> <p>With the Hedgehog Fabric, the same principles apply to managing network resources. Administrators create a YAML file to configure a VPC. The YAML file describes the IP address range for the private cloud, for example the <code>192.168.0.0/16</code> space. It also describes any VLANs that the private cloud needs. After the desired options are in the file, administrators can push the configuration to the switch with a mere <code>kubectl apply -f vpc1.yaml</code>, and within a few seconds the switch configuration is live.</p>"},{"location":"faq/overview/#what-is-a-virtual-private-cloud-vpc","title":"What is a Virtual Private Cloud (VPC)?","text":"<p>A VPC provides layer 3 logical isolation inside of a network. To isolate the servers, a VRF is used. A VRF allows for multiple routing tables to exist at the same time on a switch. Each VPC is isolated from the others because there is simply no route between them.</p>"},{"location":"getting-started/download/","title":"Download","text":"<p>The main entry point for the software is the Hedgehog Fabricator CLI named <code>hhfab</code>. It is a command-line tool that allows to build installer for the Hedgehog Fabric, upgrade the existing installation, or run the Virtual LAB.</p>"},{"location":"getting-started/download/#getting-access","title":"Getting access","text":"<p>Prior to General Availability, access to the full software is limited and requires Design Partner Agreement. Please submit a ticket with the request using Hedgehog Support Portal.</p> <p>After that you will be provided with the credentials to access the software on GitHub Package. In order to use the software, log in to the registry using the following command:</p> <pre><code>docker login ghcr.io --username provided_user_name --password provided_token_string\n</code></pre>"},{"location":"getting-started/download/#downloading-hhfab","title":"Downloading hhfab","text":"<p>Currently <code>hhfab</code> is supported on Linux x86/arm64 (tested on Ubuntu 22.04) and MacOS x86/arm64 for building installers/upgraders. It may work on Windows WSL2 (with Ubuntu), but it's not tested. For running VLAB only Linux x86 is currently supported.</p> <p>All software is published into the OCI registry GitHub Package including binaries, container images, or Helm charts. Download the latest stable <code>hhfab</code> binary from the GitHub Package using the following command, it requires ORAS to be installed (see below):</p> <pre><code>curl -fsSL https://i.hhdev.io/hhfab | bash\n</code></pre> <p>Or download a specific version (e.g. beta-1) using the following command:</p> <pre><code>curl -fsSL https://i.hhdev.io/hhfab | VERSION=beta-1 bash\n</code></pre> <p>Use the <code>VERSION</code> environment variable to specify the version of the software to download. By default, the latest stable release is downloaded. You can pick a specific release series (e.g. <code>alpha-2</code>) or a specific release.</p>"},{"location":"getting-started/download/#installing-oras","title":"Installing ORAS","text":"<p>The download script requires ORAS to be installed. ORAS is used to download the binary from the OCI registry and can be installed using following command:</p> <pre><code>curl -fsSL https://i.hhdev.io/oras | bash\n</code></pre>"},{"location":"getting-started/download/#next-steps","title":"Next steps","text":"<ul> <li>Concepts</li> <li>Virtual LAB</li> <li>Installation</li> <li>User guide</li> </ul>"},{"location":"install-upgrade/build-wiring/","title":"Build Wiring Diagram","text":"<p>Under construction.</p>"},{"location":"install-upgrade/build-wiring/#overview","title":"Overview","text":"<p>A wiring diagram is a YAML file that is a digital representation of your network. You can find more YAML level details in the User Guide section switch features and port naming and the api. It's mandatory for all switches to reference a <code>SwitchProfile</code> in the <code>spec.profile</code> of the <code>Switch</code> object. Only port naming defined by switch profiles could be used in the wiring diagram, NOS (or any other) port names aren't supported.</p> <p>In the meantime, to have a look at working wiring diagram for Hedgehog Fabric, run the sample generator that produces working wiring diagrams:</p> <pre><code>ubuntu@sl-dev:~$ hhfab sample -h\n\nNAME:\n   hhfab sample - generate sample wiring diagram\n\nUSAGE:\n   hhfab sample command [command options]\n\nCOMMANDS:\n   spine-leaf, sl      generate sample spine-leaf wiring diagram\n   collapsed-core, cc  generate sample collapsed-core wiring diagram\n   help, h             Shows a list of commands or help for one command\n\nOPTIONS:\n   --help, -h  show help\n</code></pre> <p>Or you can generate a wiring diagram for a VLAB environment with flags to customize number of switches, links, servers, etc.:</p> <pre><code>ubuntu@sl-dev:~$ hhfab vlab gen --help\nNAME:\n   hhfab vlab generate - generate VLAB wiring diagram\n\nUSAGE:\n   hhfab vlab generate [command options]\n\nOPTIONS:\n   --bundled-servers value      number of bundled servers to generate for switches (only for one of the second switch in the redundancy group or orphan switch) (default: 1)\n   --eslag-leaf-groups value    eslag leaf groups (comma separated list of number of ESLAG switches in each group, should be 2-4 per group, e.g. 2,4,2 for 3 groups with 2, 4 and 2 switches)\n   --eslag-servers value        number of ESLAG servers to generate for ESLAG switches (default: 2)\n   --fabric-links-count value   number of fabric links if fabric mode is spine-leaf (default: 0)\n   --help, -h                   show help\n   --mclag-leafs-count value    number of mclag leafs (should be even) (default: 0)\n   --mclag-peer-links value     number of mclag peer links for each mclag leaf (default: 0)\n   --mclag-servers value        number of MCLAG servers to generate for MCLAG switches (default: 2)\n   --mclag-session-links value  number of mclag session links for each mclag leaf (default: 0)\n   --no-switches                do not generate any switches (default: false)\n   --orphan-leafs-count value   number of orphan leafs (default: 0)\n   --spines-count value         number of spines if fabric mode is spine-leaf (default: 0)\n   --unbundled-servers value    number of unbundled servers to generate for switches (only for one of the first switch in the redundancy group or orphan switch) (default: 1)\n   --vpc-loopbacks value        number of vpc loopbacks for each switch (default: 0)\n</code></pre>"},{"location":"install-upgrade/build-wiring/#sample-switch-configuration","title":"Sample Switch Configuration","text":"<pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Switch\nmetadata:\n  name: ds3000-02\nspec:\n  boot:\n    serial: ABC123XYZ\n  role: server-leaf\n  description: leaf-2\n  profile: celestica-ds3000\n  portBreakouts:\n    E1/1: 4x10G\n    E1/2: 4x10G\n    E1/17: 4x25G\n    E1/18: 4x25G\n    E1/32: 4x25G\n  redundancy:\n    group: mclag-1\n    type: mclag\n</code></pre>"},{"location":"install-upgrade/build-wiring/#design-discussion","title":"Design Discussion","text":"<p>This section is meant to help the reader understand how to assemble the primitives presented by the Fabric API into a functional fabric.</p>"},{"location":"install-upgrade/build-wiring/#vpc","title":"VPC","text":"<p>A VPC allows for isolation at layer 3. This is the main building block for users when creating their architecture. Hosts inside of a VPC belong to the same broadcast domain and can communicate with each other, if desired a single VPC can be configured with multiple broadcast domains. The hosts inside of a VPC will likely need to connect to other VPCs or the outside world. To communicate between two VPC a peering will need to be created. A VPC can be a logical separation of workloads. By separating these workloads additional controls are available. The logical separation doesn't have to be the traditional database, web, and compute layers it could be development teams who need isolation, it could be tenants inside of an office building, or any separation that allows for better control of the network. Once your VPCs are decided, the rest of the fabric will come together. With the VPCs decided traffic can be prioritized, security can be put into place, and the wiring can begin. The fabric allows for the VPC to span more than one switch, which provides great flexibility.</p> <pre><code>graph TD\n    L1([Leaf 1])\n    L2([Leaf 2])\n    S1[\"Server 1\n      10.7.71.1\"]\n    S2[\"Server 2\n      172.16.2.31\"]\n    S3[\"Server 3\n       192.168.18.85\"]\n\n    L1 &lt;--&gt; S1\n    L1 &lt;--&gt; S2\n    L2 &lt;--&gt; S3\n\n    subgraph VPC 1\n    S1\n    S2\n    S3\n    end</code></pre>"},{"location":"install-upgrade/build-wiring/#connection","title":"Connection","text":"<p>A connection represents the physical wires in your data center. They connect switches to other switches or switches to servers.</p>"},{"location":"install-upgrade/build-wiring/#server-connections","title":"Server Connections","text":"<p>A server connection is a connection used to connect servers to the fabric. The fabric will configure the server-facing port according to the type of the connection (MLAG, Bundle, etc). The configuration of the actual server needs to be done by the server administrator. The server port names are not validated by the fabric and used as metadata to identify the connection. A server connection can be one of:</p> <ul> <li>Unbundled - A single cable connecting switch to server.</li> <li>Bundled - Two or more cables going to a single switch, a LAG or similar.</li> <li>MCLAG -  Two cables going to two different switches, also called dual homing. The switches will need a fabric link between them.</li> <li>ESLAG - Two to four cables going to different switches, also called multi-homing. If four links are used there will need to be four switches connected to a single server with four NIC ports.</li> </ul> <pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n    L1([Leaf 1])\n    L2([Leaf 2])\n    L3([Leaf 3])\n    L4([Leaf 4])\n    L5([Leaf 5])\n    L6([Leaf 6])\n    L7([Leaf 7])\n\n    TS1[Server1]\n    TS2[Server2]\n    TS3[Server3]\n    TS4[Server4]\n\n    S1 &amp; S2 ---- L1 &amp; L2 &amp; L3 &amp; L4 &amp; L5 &amp; L6 &amp; L7\n    L1 &lt;-- Bundled --&gt; TS1\n    L1 &lt;-- Bundled --&gt; TS1\n    L1 &lt;-- Unbundled --&gt; TS2\n    L2 &lt;-- MCLAG --&gt; TS3\n    L3 &lt;-- MCLAG --&gt; TS3\n    L4 &lt;-- ESLAG --&gt; TS4\n    L5 &lt;-- ESLAG --&gt; TS4\n    L6 &lt;-- ESLAG --&gt; TS4\n    L7 &lt;-- ESLAG --&gt; TS4\n\n    subgraph VPC 1\n    TS1\n    TS2\n    TS3\n    TS4\n    end\n\n    subgraph MCLAG\n    L2\n    L3\n    end\n\n    subgraph ESLAG\n    L3\n    L4\n    L5\n    L6\n    L7\n    end\n</code></pre>"},{"location":"install-upgrade/build-wiring/#fabric-connections","title":"Fabric Connections","text":"<p>Fabric connections serve as connections between switches, they form the fabric of the network.</p>"},{"location":"install-upgrade/build-wiring/#vpc-peering","title":"VPC Peering","text":"<p>VPCs need VPC Peerings to talk to each other. VPC Peerings come in two varieties: local and remote.</p> <pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n    L1([Leaf 1])\n    L2([Leaf 2])\n    TS1[Server1]\n    TS2[Server2]\n    TS3[Server3]\n    TS4[Server4]\n\n    S1 &amp; S2 &lt;--&gt; L1 &amp; L2\n    L1 &lt;--&gt; TS1 &amp; TS2\n    L2 &lt;--&gt; TS3 &amp; TS4\n\n\n    subgraph VPC 1\n    TS1\n    TS2\n    end\n\n    subgraph VPC 2\n    TS3\n    TS4\n    end</code></pre>"},{"location":"install-upgrade/build-wiring/#local-vpc-peering","title":"Local VPC Peering","text":"<p>When there is no dedicated border/peering switch available in the fabric we can use local VPC peering. This kind of peering tries sends traffic between the two VPC's on the switch where either of the VPC's has workloads attached. Due to limitation in the Sonic network operating system this kind of peering bandwidth is limited to the number of VPC loopbacks you have selected while initializing the fabric. Traffic between the VPCs will use the loopback interface, the bandwidth of this connection will be equal to the bandwidth of port used in the loopback.</p> <p><pre><code>graph TD\n\n    L1([Leaf 1])\n    S1[Server1]\n    S2[Server2]\n    S3[Server3]\n    S4[Server4]\n\n    L1 &lt;-.2,loopback.-&gt; L1;\n    L1 &lt;-.3.-&gt; S1;\n    L1 &lt;--&gt; S2 &amp; S4;\n    L1 &lt;-.1.-&gt; S3;\n\n    subgraph VPC 1\n    S1\n    S2\n    end\n\n    subgraph VPC 2\n    S3\n    S4\n    end</code></pre> The dotted line in the diagram shows the traffic flow for local peering. The traffic originates in VPC 2, travels to the switch, travels out the first loopback port, into the second loopback port, and finally out the port destined for VPC 1.</p>"},{"location":"install-upgrade/build-wiring/#remote-vpc-peering","title":"Remote VPC Peering","text":"<p>Remote Peering is used when you need a high bandwidth connection between the VPCs, you will dedicate a switch to the peering traffic. This is either done on the border leaf or on a switch where either of the VPC's are not present. This kind of peering allows peer traffic between different VPC's at line rate and is only limited by fabric bandwidth. Remote peering introduces a few additional hops in the traffic and may cause a small increase in latency.</p> <p><pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n    L1([Leaf 1])\n    L2([Leaf 2])\n    L3([Leaf 3])\n    TS1[Server1]\n    TS2[Server2]\n    TS3[Server3]\n    TS4[Server4]\n\n    S1 &lt;-.5.-&gt; L1;\n    S1 &lt;-.2.-&gt; L2;\n    S1 &lt;-.3,4.-&gt; L3;\n    S2 &lt;--&gt; L1;\n    S2 &lt;--&gt; L2;\n    S2 &lt;--&gt; L3;\n    L1 &lt;-.6.-&gt; TS1;\n    L1 &lt;--&gt; TS2;\n    L2 &lt;--&gt; TS3;\n    L2 &lt;-.1.-&gt; TS4;\n\n\n    subgraph VPC 1\n    TS1\n    TS2\n    end\n\n    subgraph VPC 2\n    TS3\n    TS4\n    end</code></pre> The dotted line in the diagram shows the traffic flow for remote peering. The traffic could take a different path because of ECMP. It is important to note that Leaf 3 cannot have any servers from VPC 1 or VPC 2 on it, but it can have a  different VPC attached to it.</p>"},{"location":"install-upgrade/build-wiring/#vpc-loopback","title":"VPC Loopback","text":"<p>A VPC loopback is a physical cable with both ends plugged into the same switch, suggested but not required to be the adjacent ports. This loopback allows two different VPCs to communicate with each other. This is due to a Broadcom limitation.</p>"},{"location":"install-upgrade/config/","title":"Fabric Configuration","text":""},{"location":"install-upgrade/config/#overview","title":"Overview","text":"<p>The <code>fab.yaml</code> file is the configuration file for the fabric. It supplies the configuration of the users, their credentials, logging, telemetry, and other non wiring related settings. The <code>fab.yaml</code> file is composed of multiple YAML documents inside of a single file. Per the YAML spec 3 hyphens (<code>---</code>) on a single line separate the end of one document from the beginning of the next. There are two YAML documents in the <code>fab.yaml</code> file. For more information about how to use <code>hhfab init</code>, run <code>hhfab init --help</code>.</p>"},{"location":"install-upgrade/config/#typical-hhfab-workflows","title":"Typical HHFAB workflows","text":""},{"location":"install-upgrade/config/#hhfab-for-vlab","title":"HHFAB for VLAB","text":"<p>For a VLAB user, the typical workflow with hhfab is:</p> <ol> <li><code>hhfab init --dev</code></li> <li><code>hhfab vlab gen</code></li> <li><code>hhfab vlab up</code></li> </ol> <p>The above workflow will get a user up and running with a spine-leaf VLAB.</p>"},{"location":"install-upgrade/config/#hhfab-for-physical-machines","title":"HHFAB for Physical Machines","text":"<p>It's possible to start from scratch:</p> <ol> <li><code>hhfab init</code> (see different flags to cusomize initial configuration)</li> <li>Adjust the <code>fab.yaml</code> file to your needs</li> <li><code>hhfab validate</code></li> <li><code>hhfab build</code></li> </ol> <p>Or import existing config and wiring files:</p> <ol> <li><code>hhfab init -c fab.yaml -w wiring-file.yaml -w extra-wiring-file.yaml</code></li> <li><code>hhfab validate</code></li> <li><code>hhfab build</code></li> </ol> <p>After the above workflow a user will have a .img file suitable for installing the control node, then bringing up the switches which comprise the fabric.</p>"},{"location":"install-upgrade/config/#fabyaml","title":"Fab.yaml","text":""},{"location":"install-upgrade/config/#configure-control-node-and-switch-users","title":"Configure control node and switch users","text":"<p>Configuring control node and switch users is done either passing <code>--default-password-hash</code> to <code>hhfab init</code> or editing the resulting <code>fab.yaml</code> file emitted by <code>hhfab init</code>. You can specify users to be configured on the control node(s) and switches in the following format:</p> <pre><code>spec:\n    config:\n      control:\n        defaultUser: # user 'core' on all control nodes\n          password: \"hashhashhashhashhash\" # password hash\n          authorizedKeys:\n            - \"ssh-ed25519 SecREKeyJumblE\"\n\n        fabric:\n          mode: spine-leaf # \"spine-leaf\" or \"collapsed-core\"\n\n          defaultSwitchUsers:\n            admin: # at least one user with name 'admin' and role 'admin'\n              role: admin\n              #password: \"$5$8nAYPGcl4...\" # password hash\n              #authorizedKeys: # optional SSH authorized keys\n              #  - \"ssh-ed25519 AAAAC3Nza...\"\n            op: # optional read-only user\n              role: operator\n              #password: \"$5$8nAYPGcl4...\" # password hash\n              #authorizedKeys: # optional SSH authorized keys\n              #  - \"ssh-ed25519 AAAAC3Nza...\"\n</code></pre> <p>Control node(s) user is always named <code>core</code>.</p> <p>The role of the user,<code>operator</code> is read-only access to <code>sonic-cli</code> command on the switches. In order to avoid conflicts, do not use the following usernames: <code>operator</code>,<code>hhagent</code>,<code>netops</code>.</p>"},{"location":"install-upgrade/config/#ntp-and-dhcp","title":"NTP and DHCP","text":"<p>The control node uses public ntp servers from cloudflare and google by default. The control node runs a dhcp server on the management network. See the example file.</p>"},{"location":"install-upgrade/config/#control-node","title":"Control Node","text":"<p>The control node is the host that manages all the switches, runs k3s, and serves images. This is the YAML document configure the control node: <pre><code>apiVersion: fabricator.githedgehog.com/v1beta1\nkind: ControlNode\nmetadata:\n  name: control-1\n  namespace: fab\nspec:\n  bootstrap:\n   disk: \"/dev/sda\" # disk to install OS on, e.g. \"sda\" or \"nvme0n1\"\n  external:\n    interface: enp2s0 # interface for external\n    ip: dhcp # IP address for external interface\n  management:\n    interface: enp2s1 # interface for management\n\n# Currently only one ControlNode is supported\n</code></pre> The management interface is for the control node to manage the fabric switches, not end-user management of the control node. For end-user management of the control node specify the external interface name.</p>"},{"location":"install-upgrade/config/#forward-switch-metrics-and-logs","title":"Forward switch metrics and logs","text":"<p>There is an option to enable Grafana Alloy on all switches to forward metrics and logs to the configured targets using Prometheus Remote-Write API and Loki API. If those APIs are available from Control Node(s), but not from the switches, it's possible to enable HTTP Proxy on Control Node(s) that will be used by Grafana Alloy running on the switches to access the configured targets. It could be done by passing <code>--control-proxy=true</code> to <code>hhfab init</code>.</p> <p>Metrics includes port speeds, counters, errors, operational status, transceivers, fans, power supplies, temperature sensors, BGP neighbors, LLDP neighbors, and more. Logs include agent logs.</p> <p>Configuring the exporters and targets is currently only possible by editing the <code>fab.yaml</code> configuration file. An example configuration is provided below:</p> <pre><code>spec:\n  config:\n      ...\n      defaultAlloyConfig:\n        agentScrapeIntervalSeconds: 120\n        unixScrapeIntervalSeconds: 120\n        unixExporterEnabled: true\n        lokiTargets:\n          grafana_cloud: # target name, multiple targets can be configured\n              basicAuth: # optional\n                  password: \"&lt;password&gt;\"\n                  username: \"&lt;username&gt;\"\n              labels: # labels to be added to all logs\n                  env: env-1\n              url: https://logs-prod-021.grafana.net/loki/api/v1/push\n              useControlProxy: true # if the Loki API is not available from the switches directly, use the Control Node as a proxy\n        prometheusTargets:\n          grafana_cloud: # target name, multiple targets can be configured\n              basicAuth: # optional\n                  password: \"&lt;password&gt;\"\n                  username: \"&lt;username&gt;\"\n              labels: # labels to be added to all metrics\n                  env: env-1\n              sendIntervalSeconds: 120\n              url: https://prometheus-prod-36-prod-us-west-0.grafana.net/api/prom/push\n              useControlProxy: true # if the Loki API is not available from the switches directly, use the Control Node as a proxy\n              unixExporterCollectors: # list of node-exporter collectors to enable, https://grafana.com/docs/alloy/latest/reference/components/prometheus.exporter.unix/#collectors-list\n                  - cpu\n                  - filesystem\n                  - loadavg\n                  - meminfo\n              collectSyslogEnabled: true # collect /var/log/syslog on switches and forward to the lokiTargets\n</code></pre> <p>For additional options, see the <code>AlloyConfig</code> struct in Fabric repo.</p>"},{"location":"install-upgrade/config/#complete-example-file","title":"Complete Example File","text":"<pre><code>apiVersion: fabricator.githedgehog.com/v1beta1\nkind: Fabricator\nmetadata:\n  name: default\n  namespace: fab\nspec:\n  config:\n    control:\n      tlsSAN: # IPs and DNS names to access API\n        - \"customer.site.io\"\n\n      ntpServers:\n      - time.cloudflare.com\n      - time1.google.com\n\n      defaultUser: # user 'core' on all control nodes\n        password: \"hash...\" # password hash\n        authorizedKeys:\n          - \"ssh-ed25519 hash...\"\n\n    fabric:\n      mode: spine-leaf # \"spine-leaf\" or \"collapsed-core\"\n      includeONIE: true\n      defaultSwitchUsers:\n        admin: # at least one user with name 'admin' and role 'admin'\n          role: admin\n          password: \"hash...\" # password hash\n          authorizedKeys:\n            - \"ssh-ed25519 hash...\"\n        op: # optional read-only user\n          role: operator\n          password: \"hash...\" # password hash\n          authorizedKeys:\n            - \"ssh-ed25519 hash...\"\n\n      defaultAlloyConfig:\n        agentScrapeIntervalSeconds: 120\n        unixScrapeIntervalSeconds: 120\n        unixExporterEnabled: true\n        collectSyslogEnabled: true\n        lokiTargets:\n          lab:\n            url: http://url.io:3100/loki/api/v1/push\n            useControlProxy: true\n            labels:\n              descriptive: name\n        prometheusTargets:\n          lab:\n            url: http://url.io:9100/api/v1/push\n            useControlProxy: true\n            labels:\n              descriptive: name\n            sendIntervalSeconds: 120\n\n---\napiVersion: fabricator.githedgehog.com/v1beta1\nkind: ControlNode\nmetadata:\n  name: control-1\n  namespace: fab\nspec:\n  bootstrap:\n    disk: \"/dev/sda\" # disk to install OS on, e.g. \"sda\" or \"nvme0n1\"\n  external:\n    interface: eno2 # interface for external\n    ip: dhcp # IP address for external interface\n  management:\n    interface: eno1\n\n# Currently only one ControlNode is supported\n</code></pre>"},{"location":"install-upgrade/install/","title":"Install Fabric","text":""},{"location":"install-upgrade/install/#prerequisites","title":"Prerequisites","text":"<ul> <li>A machine with access to the Internet to use Fabricator and build installer with at least 8 GB RAM and 25 GB of disk space</li> <li>An 16 GB USB flash drive, if you are not using virtual media</li> <li>Have a machine to function as the Fabric Control Node. System Requirements as well as IPMI access to it to install   the OS.</li> <li>A management switch with at least 1 10GbE port is recommended</li> <li>Enough Supported Switches for your Fabric</li> </ul>"},{"location":"install-upgrade/install/#overview-of-install-process","title":"Overview of Install Process","text":"<p>This section is dedicated to the Hedgehog Fabric installation on bare-metal control node(s) and switches, their preparation and configuration. To install the VLAB see VLAB Overview.</p> <p>Download and install <code>hhfab</code> following instructions from the Download section.</p> <p>The main steps to install Fabric are:</p> <ol> <li>Install <code>hhfab</code> on the machines with access to the Internet<ol> <li>Prepare Wiring Diagram</li> <li>Select Fabric Configuration</li> <li>Build Control Node configuration and installer</li> </ol> </li> <li>Install Control Node<ol> <li>Insert USB with control-os image into Fabric Control Node</li> <li>Boot the node off the USB to initiate the installation</li> </ol> </li> <li>Prepare Management Network<ol> <li>Connect management switch to Fabric control node</li> <li>Connect 1GbE Management port of switches to management switch</li> </ol> </li> <li>Prepare supported switches<ol> <li>Ensure switch serial numbers and / or first management interface MAC addresses are recorded in wiring diagram</li> <li>Boot them into ONIE Install Mode to have them automatically provisioned</li> </ol> </li> </ol>"},{"location":"install-upgrade/install/#build-control-node-configuration-and-installer","title":"Build Control Node configuration and Installer","text":"<p>Hedgehog has created a command line utility, called <code>hhfab</code>, that helps generate the wiring diagram and fabric configuration, validate the supplied configurations, and generate an installation image (.img or .iso) suitable  for writing to a USB flash drive or mounting via IPMI virtual media. The first <code>hhfab</code> command to run is <code>hhfab init</code>. This will generate the main configuration file, <code>fab.yaml</code>. <code>fab.yaml</code> is  responsible for almost every configuration of the fabric with the exception of the wiring. Each  command and subcommand have usage messages, simply supply the <code>-h</code> flag to your command or sub  command to see the available options. For example <code>hhfab vlab -h</code> and <code>hhfab vlab gen -h</code>.</p>"},{"location":"install-upgrade/install/#hhfab-commands-to-make-a-bootable-image","title":"HHFAB commands to make a bootable image","text":"<ol> <li><code>hhfab init --wiring wiring-lab.yaml</code></li> <li>The <code>init</code> command generates a <code>fab.yaml</code> file, edit the <code>fab.yaml</code> file for your needs<ol> <li>ensure the correct boot disk (e.g. <code>/dev/sda</code>) and control node NIC names are supplied</li> </ol> </li> <li><code>hhfab validate</code></li> <li><code>hhfab build --mode iso</code><ol> <li>An ISO is best suited to use with IPMI based virtual media. If desired an IMG file suitable for writing to a USB drive, can be created by passing the <code>--mode usb</code> option. ISO is the default.</li> </ol> </li> </ol> <p>The installer for the fabric is generated in <code>$CWD/result/</code>. This installation image is named <code>control-1-install-usb.iso</code> and is 7.5 GB in size. Once the image is created, you can write it to a USB drive, or mount it via virtual media.</p>"},{"location":"install-upgrade/install/#write-usb-image-to-disk","title":"Write USB Image to Disk","text":"<p>This will erase data on the USB disk.</p>"},{"location":"install-upgrade/install/#steps-for-linux","title":"Steps for Linux","text":"<ol> <li>Insert the USB to your machine</li> <li>Identify the path to your USB stick, for example: <code>/dev/sdc</code></li> <li>Issue the command to write the image to the USB drive<ul> <li><code>sudo dd if=control-1-install-usb.img of=/dev/sdc bs=4k status=progress</code></li> </ul> </li> </ol>"},{"location":"install-upgrade/install/#steps-for-macos","title":"Steps for MacOS","text":"<ol> <li>Plug the drive into the computer</li> <li>Open the terminal</li> <li>Identify the drive using <code>diskutil list</code></li> <li>Unmount the disk <code>diskutil unmount disk5</code>, the disk is specific to your environment</li> <li>Write the image to the disk: <code>sudo dd if=./control-1-install-usb.img of=/dev/disk5 bs=4k status=progress</code></li> </ol> <p>There are utilities that assist this process such as etcher.</p>"},{"location":"install-upgrade/install/#install-control-node","title":"Install Control Node","text":"<p>This control node should be given a static IP address. Either a lease or statically assigned.</p> <ol> <li> <p>Configure the server to use UEFI boot without secure boot</p> </li> <li> <p>Attach the image to the server either by inserting via USB, or attaching via virtual media</p> </li> <li> <p>Select boot off of the attached media, the installation process is automated</p> </li> <li> <p>Once the control node has booted, it logs in automatically and begins the installation process</p> <ol> <li>Optionally use <code>journalctl -f -u flatcar-install.service</code> to monitor progress</li> </ol> </li> <li> <p>Once the installation is complete, the system automatically reboots.</p> </li> <li> <p>After the system has shutdown but before the boot up process reaches the operating system, remove the USB image from the system. Removal during the UEFI boot screen is acceptable.</p> </li> <li> <p>Upon booting into the freshly installed system, the fabric installation will automatically begin</p> <ol> <li>If the insecure <code>--dev</code> flag was passed to <code>hhfab init</code> the password for the <code>core</code> user is <code>HHFab.Admin!</code>, the switches have two users created <code>admin</code> and <code>op</code>. <code>admin</code> has administrator privileges and password <code>HHFab.Admin!</code>, whereas the <code>op</code> user is a read-only, non-sudo user with password <code>HHFab.Op!</code>.</li> <li>Optionally this can be monitored with <code>journalctl -f -u fabric-install.service</code></li> </ol> </li> <li> <p>The install is complete when the log emits \"Control Node installation complete\". Additionally, the systemctl status will show <code>inactive (dead)</code> indicating that the executable has finished.</p> </li> </ol>"},{"location":"install-upgrade/install/#configure-management-network","title":"Configure Management Network","text":"<p>The control node is dual-homed: it connects to two different networks, which are called <code>management</code> and <code>external</code>, respectively, in the <code>fab.yaml</code> file. The <code>management</code> network is for controlling the switches that comprise the fabric. It can be a simple broadcast domain with layer 2 connectivity. The management network is not accessible to machines or devices not associated with the fabric; it is a private, exclusive network. The control node connects to the management network via a 10 GbE interface. It runs a DHCP server, as well as a small HTTP server.</p> <p>The <code>external</code> network allows the user to access the control node via their local IT network. It provides SSH access to the host operating system on the control node.</p>"},{"location":"install-upgrade/install/#fabric-manages-switches","title":"Fabric Manages Switches","text":"<p>Now that the install has finished, you can start interacting with the Fabric using <code>kubectl</code>, <code>kubectl fabric</code> and <code>k9s</code>, all pre-installed as part of the Control Node installer.</p> <p>At this stage, the fabric hands out DHCP addresses to the switches via the management network. Optionally, you can monitor this process by going through the following steps: - enter <code>k9s</code> at the command prompt - use the arrow keys to select the pod named <code>fabric-boot</code> - the logs of the pod will be displayed showing the DHCP lease process - use the switches screen of <code>k9s</code> to see the heartbeat column to verify the connection between switch and controller.     - to see the switches type <code>:switches</code> (like a vim command) into <code>k9s</code></p>"},{"location":"install-upgrade/requirements/","title":"System Requirements","text":""},{"location":"install-upgrade/requirements/#out-of-band-management-network","title":"Out of Band Management Network","text":"<p>In order to provision and manage the switches that comprise the fabric, an out of band switch must also be installed. This network is to be used exclusively by the control node and the fabric switches, no other access is permitted. This switch (or switches) is not managed by the fabric. It is recommended that this switch have at least a 10GbE port and that port connect to the control node.</p>"},{"location":"install-upgrade/requirements/#control-node","title":"Control Node","text":"<ul> <li>Fast SSDs for system/root is mandatory for Control Nodes<ul> <li>NVMe SSDs are recommended</li> <li>DRAM-less NAND SSDs are not supported (e.g. Crucial BX500)</li> </ul> </li> <li>10 GbE port for connection to management network is recommended</li> <li>Minimal (non-HA) setup is a single Control Node</li> <li>(Future) Full (HA) setup is at least 3 Control Nodes</li> <li>(Future) Extra nodes could be used for things like Logging, Monitoring, Alerting stack, and more</li> </ul> <p>In internal testing Hedgehog uses a server with the following specifications:</p> <ul> <li>CPU - AMD EPYC 4344P </li> <li>Memory - 32 GiB DDR5 ECC 4800MT/s</li> <li>Storage - PCIe Gen 4 NVMe M.2 400GB</li> <li>Network - AOC-STG-i4S Intel X710-BM1 controller</li> <li>Motherboard - H13SAE-MF</li> </ul>"},{"location":"install-upgrade/requirements/#non-ha-minimal-setup-1-control-node","title":"Non-HA (minimal) setup - 1 Control Node","text":"<ul> <li>Control Node runs non-HA Kubernetes Control Plane installation with non-HA Hedgehog Fabric Control Plane on top of it</li> <li>Not recommended for more then 10 devices participating in the Hedgehog Fabric or production deployments</li> </ul> Minimal Recommended CPU 6 8 RAM 16 GB 32 GB Disk 150 GB 250 GB"},{"location":"install-upgrade/requirements/#future-ha-setup-3-control-nodes-per-node","title":"(Future) HA setup - 3+ Control Nodes (per node)","text":"<ul> <li>Each Control Node runs part of the HA Kubernetes Control Plane installation with Hedgehog Fabric Control Plane on top   of it in HA mode as well</li> <li>Recommended for all cases where more than 10 devices participating in the Hedgehog Fabric</li> </ul> Minimal Recommended CPU 6 8 RAM 16 GB 32 GB Disk 150 GB 250 GB"},{"location":"install-upgrade/requirements/#reference-control-node-configuration","title":"Reference Control Node Configuration","text":"<ul> <li>AMD EPYC 4344P (8C/16T, 3.8 GHz, 32 MB L3, 65W, single socket)</li> <li>32 GB DDR5-4800 ECC UDIMM (2 x 16 GB)</li> <li>Micron 7450 MAX 400GB NVMe</li> </ul>"},{"location":"install-upgrade/requirements/#device-participating-in-the-hedgehog-fabric-eg-switch","title":"Device participating in the Hedgehog Fabric (e.g. switch)","text":"<ul> <li>(Future) Each participating device is part of the Kubernetes cluster, so it runs Kubernetes kubelet</li> <li>Additionally, it runs the Hedgehog Fabric Agent that controls devices configuration</li> </ul> <p>Following resources should be available on a device to run in the Hedgehog Fabric (after other software such as SONiC usage):</p> Minimal Recommended CPU 1 2 RAM 1 GB 1.5 GB Disk 5 GB 10 GB"},{"location":"install-upgrade/supported-devices/","title":"Supported Devices","text":"<p>You can find detailed information about devices in the Switch Profiles Catalog and in the User Guide switch features and port naming.</p>"},{"location":"install-upgrade/supported-devices/#spine","title":"Spine","text":"<ul> <li>Celestica DS3000</li> <li>Celestica DS4000</li> <li>Dell S5232F-ON</li> <li>Dell Z9332F-ON</li> <li>Edgecore DCS204 (AS7726-32X)</li> <li>Edgecore DCS501 (AS7712-32X-EC)</li> <li>Supermicro SSE-C4632SB</li> </ul>"},{"location":"install-upgrade/supported-devices/#leaf","title":"Leaf","text":"<p>(could be used for collapsed-core)</p> <ul> <li>Celestica DS3000</li> <li>Dell S5232F-ON</li> <li>Dell S5248F-ON</li> <li>Edgecore DCS203 (AS7326-56X)</li> <li>Edgecore DCS204 (AS7726-32X)</li> <li>Edgecore EPS203 (AS4630-54NPE)</li> <li>Supermicro SSE-C4632SB</li> </ul>"},{"location":"install-upgrade/upgrade/","title":"Upgrading from Alpha-7 to Beta-1","text":""},{"location":"install-upgrade/upgrade/#control-node","title":"Control Node","text":"<p>Ensure the hardware that is to be used for the control node meets the system requirements. The upgrade process is destructive of the host, so ensure all data needed is removed from the selected server before the upgrade is started.</p>"},{"location":"install-upgrade/upgrade/#management-network","title":"Management Network","text":"<p>Beta-1 uses the RJ-45 management ports of the switches instead of front panel ports. A simple management network will need to be in place and cabled before the install of Beta-1. The control node will run a DHCP server on this network and must be the sole DHCP server. Do not co-mingle other services or equipment on this network, it is for the exclusive use of the control node and switches.</p>"},{"location":"install-upgrade/upgrade/#install-switch-vendor-onie","title":"Install Switch Vendor ONIE","text":"<p>Beta-1 uses the switch vendor ONIE for installation of the NOS. The latest vendor provided version of ONIE is recommended to be installed. Hedgehog ONIE must not be used.</p>"},{"location":"install-upgrade/upgrade/#changes-to-the-wiring-diagram","title":"Changes to the Wiring Diagram","text":"<ul> <li>All API versions changed from <code>v1alpha2</code> to <code>v1beta1</code></li> <li><code>Server[control=true]</code> object type was removed and replaced with <code>ControlNode</code> object in the <code>fabricator.githedgehog.com/v1beta1</code> API (.spec.control field removed), <code>Server</code> object only describes workload server now</li> <li>All initial configuration is mainly still available using the <code>hhfab init</code> flags but now configurable in the <code>fab.yaml</code> file it creates and available in the runtime in the <code>Fabricator</code> object in the <code>fabricator.githedgehog.com/v1beta1</code> API</li> <li><code>Connection[type=management]</code> object removed, relevant information is now present on the <code>ControlNode</code> object in the form of the management interface and its config, switches are always connected using management port</li> <li><code>.spec.location</code> remove from <code>Switch</code> object</li> <li><code>.spec.boot</code> added to <code>Switch</code> object with <code>mac</code> and <code>serial</code> fields, at least one of them is required to identify switch for installation</li> </ul>"},{"location":"install-upgrade/upgrade/#install-the-control-node","title":"Install The Control Node","text":"<p>Follow the instructions for installing the Beta-1 Fabric on a control node.</p>"},{"location":"install-upgrade/upgrade/#install-nos-using-onie-nos-install-option","title":"Install NOS using ONIE NOS Install Option","text":"<p>As the switches boot up, select the ONIE option from the grub screen. From there select the \"NOS Install\" option. The install option will cause the switch to begin searching for installation media, this media is supplied by the control node.</p>"},{"location":"reference/api/","title":"API Reference","text":""},{"location":"reference/api/#packages","title":"Packages","text":"<ul> <li>agent.githedgehog.com/v1beta1</li> <li>dhcp.githedgehog.com/v1beta1</li> <li>vpc.githedgehog.com/v1beta1</li> <li>wiring.githedgehog.com/v1beta1</li> </ul>"},{"location":"reference/api/#agentgithedgehogcomv1beta1","title":"agent.githedgehog.com/v1beta1","text":"<p>Package v1beta1 contains API Schema definitions for the agent v1beta1 API group. This is the internal API group for the switch and control node agents. Not intended to be modified by the user.</p>"},{"location":"reference/api/#resource-types","title":"Resource Types","text":"<ul> <li>Agent</li> </ul>"},{"location":"reference/api/#adminstatus","title":"AdminStatus","text":"<p>Underlying type: string</p> <p>Appears in: - SwitchStateInterface</p> Field Description `` <code>up</code> <code>down</code> <code>testing</code>"},{"location":"reference/api/#agent","title":"Agent","text":"<p>Agent is an internal API object used by the controller to pass all relevant information to the agent running on a specific switch in order to fully configure it and manage its lifecycle. It is not intended to be used directly by users. Spec of the object isn't user-editable, it is managed by the controller. Status of the object is updated by the agent and is used by the controller to track the state of the agent and the switch it is running on. Name of the Agent object is the same as the name of the switch it is running on and it's created in the same namespace as the Switch object.</p> Field Description Default Validation <code>apiVersion</code> string <code>agent.githedgehog.com/v1beta1</code> <code>kind</code> string <code>Agent</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>status</code> AgentStatus Status is the observed state of the Agent"},{"location":"reference/api/#agentstatus","title":"AgentStatus","text":"<p>AgentStatus defines the observed state of the agent running on a specific switch and includes information about the switch itself as well as the state of the agent and applied configuration.</p> <p>Appears in: - Agent</p> Field Description Default Validation <code>version</code> string Current running agent version <code>installID</code> string ID of the agent installation, used to track NOS re-installs <code>runID</code> string ID of the agent run, used to track NOS reboots <code>lastHeartbeat</code> Time Time of the last heartbeat from the agent <code>lastAttemptTime</code> Time Time of the last attempt to apply configuration <code>lastAttemptGen</code> integer Generation of the last attempt to apply configuration <code>lastAppliedTime</code> Time Time of the last successful configuration application <code>lastAppliedGen</code> integer Generation of the last successful configuration application <code>state</code> SwitchState Detailed switch state updated with each heartbeat <code>conditions</code> Condition array Conditions of the agent, includes readiness marker for use with kubectl wait"},{"location":"reference/api/#bgpmessages","title":"BGPMessages","text":"<p>Appears in: - SwitchStateBGPNeighbor</p> Field Description Default Validation <code>received</code> BGPMessagesCounters <code>sent</code> BGPMessagesCounters"},{"location":"reference/api/#bgpmessagescounters","title":"BGPMessagesCounters","text":"<p>Appears in: - BGPMessages</p> Field Description Default Validation <code>capability</code> integer <code>keepalive</code> integer <code>notification</code> integer <code>open</code> integer <code>routeRefresh</code> integer <code>update</code> integer"},{"location":"reference/api/#bgpneighborsessionstate","title":"BGPNeighborSessionState","text":"<p>Underlying type: string</p> <p>Appears in: - SwitchStateBGPNeighbor</p> Field Description `` <code>idle</code> <code>connect</code> <code>active</code> <code>openSent</code> <code>openConfirm</code> <code>established</code>"},{"location":"reference/api/#bgppeertype","title":"BGPPeerType","text":"<p>Underlying type: string</p> <p>Appears in: - SwitchStateBGPNeighbor</p> Field Description `` <code>internal</code> <code>external</code>"},{"location":"reference/api/#operstatus","title":"OperStatus","text":"<p>Underlying type: string</p> <p>Appears in: - SwitchStateInterface</p> Field Description `` <code>up</code> <code>down</code> <code>testing</code> <code>unknown</code> <code>dormant</code> <code>notPresent</code> <code>lowerLayerDown</code>"},{"location":"reference/api/#switchstate","title":"SwitchState","text":"<p>Appears in: - AgentStatus</p> Field Description Default Validation <code>nos</code> SwitchStateNOS Information about the switch and NOS <code>interfaces</code> object (keys:string, values:SwitchStateInterface) Switch interfaces state (incl. physical, management and port channels) <code>breakouts</code> object (keys:string, values:SwitchStateBreakout) Breakout ports state (port -&gt; breakout state) <code>bgpNeighbors</code> object (keys:string, values:map[string]SwitchStateBGPNeighbor) State of all BGP neighbors (VRF -&gt; neighbor address -&gt; state) <code>platform</code> SwitchStatePlatform State of the switch platform (fans, PSUs, sensors) <code>criticalResources</code> SwitchStateCRM State of the critical resources (ACLs, routes, etc.)"},{"location":"reference/api/#switchstatebgpneighbor","title":"SwitchStateBGPNeighbor","text":"<p>Appears in: - SwitchState</p> Field Description Default Validation <code>connectionsDropped</code> integer <code>enabled</code> boolean <code>establishedTransitions</code> integer <code>lastEstablished</code> Time <code>lastRead</code> Time <code>lastResetReason</code> string <code>lastResetTime</code> Time <code>lastWrite</code> Time <code>localAS</code> integer <code>messages</code> BGPMessages <code>peerAS</code> integer <code>peerGroup</code> string <code>peerPort</code> integer <code>peerType</code> BGPPeerType <code>remoteRouterID</code> string <code>sessionState</code> BGPNeighborSessionState <code>shutdownMessage</code> string <code>prefixes</code> object (keys:string, values:SwitchStateBGPNeighborPrefixes)"},{"location":"reference/api/#switchstatebgpneighborprefixes","title":"SwitchStateBGPNeighborPrefixes","text":"<p>Appears in: - SwitchStateBGPNeighbor</p> Field Description Default Validation <code>received</code> integer <code>receivedPrePolicy</code> integer <code>sent</code> integer"},{"location":"reference/api/#switchstatebreakout","title":"SwitchStateBreakout","text":"<p>Appears in: - SwitchState</p> Field Description Default Validation <code>mode</code> string <code>nosMembers</code> string array <code>status</code> string"},{"location":"reference/api/#switchstatecrm","title":"SwitchStateCRM","text":"<p>Appears in: - SwitchState</p> Field Description Default Validation <code>aclStats</code> SwitchStateCRMACLStats <code>stats</code> SwitchStateCRMStats"},{"location":"reference/api/#switchstatecrmacldetails","title":"SwitchStateCRMACLDetails","text":"<p>Appears in: - SwitchStateCRMACLInfo</p> Field Description Default Validation <code>groupsAvailable</code> integer <code>groupsUsed</code> integer <code>tablesAvailable</code> integer <code>tablesUsed</code> integer"},{"location":"reference/api/#switchstatecrmaclinfo","title":"SwitchStateCRMACLInfo","text":"<p>Appears in: - SwitchStateCRMACLStats</p> Field Description Default Validation <code>lag</code> SwitchStateCRMACLDetails <code>port</code> SwitchStateCRMACLDetails <code>rif</code> SwitchStateCRMACLDetails <code>switch</code> SwitchStateCRMACLDetails <code>vlan</code> SwitchStateCRMACLDetails"},{"location":"reference/api/#switchstatecrmaclstats","title":"SwitchStateCRMACLStats","text":"<p>Appears in: - SwitchStateCRM</p> Field Description Default Validation <code>egress</code> SwitchStateCRMACLInfo <code>ingress</code> SwitchStateCRMACLInfo"},{"location":"reference/api/#switchstatecrmstats","title":"SwitchStateCRMStats","text":"<p>Appears in: - SwitchStateCRM</p> Field Description Default Validation <code>dnatEntriesAvailable</code> integer <code>dnatEntriesUsed</code> integer <code>fdbEntriesAvailable</code> integer <code>fdbEntriesUsed</code> integer <code>ipmcEntriesAvailable</code> integer <code>ipmcEntriesUsed</code> integer <code>ipv4NeighborsAvailable</code> integer <code>ipv4NeighborsUsed</code> integer <code>ipv4NexthopsAvailable</code> integer <code>ipv4NexthopsUsed</code> integer <code>ipv4RoutesAvailable</code> integer <code>ipv4RoutesUsed</code> integer <code>ipv6NeighborsAvailable</code> integer <code>ipv6NeighborsUsed</code> integer <code>ipv6NexthopsAvailable</code> integer <code>ipv6NexthopsUsed</code> integer <code>ipv6RoutesAvailable</code> integer <code>ipv6RoutesUsed</code> integer <code>nexthopGroupMembersAvailable</code> integer <code>nexthopGroupMembersUsed</code> integer <code>nexthopGroupsAvailable</code> integer <code>nexthopGroupsUsed</code> integer <code>snatEntriesAvailable</code> integer <code>snatEntriesUsed</code> integer"},{"location":"reference/api/#switchstateinterface","title":"SwitchStateInterface","text":"<p>Appears in: - SwitchState</p> Field Description Default Validation <code>enabled</code> boolean <code>adminStatus</code> AdminStatus <code>operStatus</code> OperStatus <code>mac</code> string <code>lastChanged</code> Time <code>speed</code> string <code>counters</code> SwitchStateInterfaceCounters <code>transceiver</code> SwitchStateTransceiver <code>lldpNeighbors</code> SwitchStateLLDPNeighbor array"},{"location":"reference/api/#switchstateinterfacecounters","title":"SwitchStateInterfaceCounters","text":"<p>Appears in: - SwitchStateInterface</p> Field Description Default Validation <code>inBitsPerSecond</code> float <code>inDiscards</code> integer <code>inErrors</code> integer <code>inPktsPerSecond</code> float <code>inUtilization</code> integer <code>lastClear</code> Time <code>outBitsPerSecond</code> float <code>outDiscards</code> integer <code>outErrors</code> integer <code>outPktsPerSecond</code> float <code>outUtilization</code> integer"},{"location":"reference/api/#switchstatelldpneighbor","title":"SwitchStateLLDPNeighbor","text":"<p>Appears in: - SwitchStateInterface</p> Field Description Default Validation <code>chassisID</code> string <code>systemName</code> string <code>systemDescription</code> string <code>portID</code> string <code>portDescription</code> string <code>manufacturer</code> string <code>model</code> string <code>serialNumber</code> string"},{"location":"reference/api/#switchstatenos","title":"SwitchStateNOS","text":"<p>SwitchStateNOS contains information about the switch and NOS received from the switch itself by the agent</p> <p>Appears in: - SwitchState</p> Field Description Default Validation <code>asicVersion</code> string ASIC name, such as \"broadcom\" or \"vs\" <code>buildCommit</code> string NOS build commit <code>buildDate</code> string NOS build date <code>builtBy</code> string NOS build user <code>configDbVersion</code> string NOS config DB version, such as \"version_4_2_1\" <code>distributionVersion</code> string Distribution version, such as \"Debian 10.13\" <code>hardwareVersion</code> string Hardware version, such as \"X01\" <code>hwskuVersion</code> string Hwsku version, such as \"DellEMC-S5248f-P-25G-DPB\" <code>kernelVersion</code> string Kernel version, such as \"5.10.0-21-amd64\" <code>mfgName</code> string Manufacturer name, such as \"Dell EMC\" <code>platformName</code> string Platform name, such as \"x86_64-dellemc_s5248f_c3538-r0\" <code>productDescription</code> string NOS product description, such as \"Enterprise SONiC Distribution by Broadcom - Enterprise Base package\" <code>productVersion</code> string NOS product version, empty for Broadcom SONiC <code>serialNumber</code> string Switch serial number <code>softwareVersion</code> string NOS software version, such as \"4.2.0-Enterprise_Base\" <code>uptime</code> string Switch uptime, such as \"21:21:27 up 1 day, 23:26, 0 users, load average: 1.92, 1.99, 2.00 \""},{"location":"reference/api/#switchstateplatform","title":"SwitchStatePlatform","text":"<p>Appears in: - SwitchState</p> Field Description Default Validation <code>fans</code> object (keys:string, values:SwitchStatePlatformFan) <code>psus</code> object (keys:string, values:SwitchStatePlatformPSU) <code>temperature</code> object (keys:string, values:SwitchStatePlatformTemperature)"},{"location":"reference/api/#switchstateplatformfan","title":"SwitchStatePlatformFan","text":"<p>Appears in: - SwitchStatePlatform</p> Field Description Default Validation <code>direction</code> string <code>speed</code> float <code>presence</code> boolean <code>status</code> boolean"},{"location":"reference/api/#switchstateplatformpsu","title":"SwitchStatePlatformPSU","text":"<p>Appears in: - SwitchStatePlatform</p> Field Description Default Validation <code>inputCurrent</code> float <code>inputPower</code> float <code>inputVoltage</code> float <code>outputCurrent</code> float <code>outputPower</code> float <code>outputVoltage</code> float <code>presence</code> boolean <code>status</code> boolean"},{"location":"reference/api/#switchstateplatformtemperature","title":"SwitchStatePlatformTemperature","text":"<p>Appears in: - SwitchStatePlatform</p> Field Description Default Validation <code>temperature</code> float <code>alarms</code> string <code>highThreshold</code> float <code>criticalHighThreshold</code> float <code>lowThreshold</code> float <code>criticalLowThreshold</code> float"},{"location":"reference/api/#switchstatetransceiver","title":"SwitchStateTransceiver","text":"<p>Appears in: - SwitchStateInterface</p> Field Description Default Validation <code>description</code> string <code>cableClass</code> string <code>formFactor</code> string <code>connectorType</code> string <code>present</code> string <code>cableLength</code> float <code>operStatus</code> string <code>temperature</code> float <code>voltage</code> float <code>serialNumber</code> string <code>vendor</code> string <code>vendorPart</code> string <code>vendorOUI</code> string <code>vendorRev</code> string"},{"location":"reference/api/#dhcpgithedgehogcomv1beta1","title":"dhcp.githedgehog.com/v1beta1","text":"<p>Package v1beta1 contains API Schema definitions for the dhcp v1beta1 API group. It is the primary internal API group for the intended Hedgehog DHCP server configuration and storing leases as well as making them available to the end user through API. Not intended to be modified by the user.</p>"},{"location":"reference/api/#resource-types_1","title":"Resource Types","text":"<ul> <li>DHCPSubnet</li> </ul>"},{"location":"reference/api/#dhcpallocated","title":"DHCPAllocated","text":"<p>DHCPAllocated is a single allocated IP with expiry time and hostname from DHCP requests, it's effectively a DHCP lease</p> <p>Appears in: - DHCPSubnetStatus</p> Field Description Default Validation <code>ip</code> string Allocated IP address <code>expiry</code> Time Expiry time of the lease <code>hostname</code> string Hostname from DHCP request"},{"location":"reference/api/#dhcpsubnet","title":"DHCPSubnet","text":"<p>DHCPSubnet is the configuration (spec) for the Hedgehog DHCP server and storage for the leases (status). It's primary internal API group, but it makes allocated IPs / leases information available to the end user through API. Not intended to be modified by the user.</p> Field Description Default Validation <code>apiVersion</code> string <code>dhcp.githedgehog.com/v1beta1</code> <code>kind</code> string <code>DHCPSubnet</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> DHCPSubnetSpec Spec is the desired state of the DHCPSubnet <code>status</code> DHCPSubnetStatus Status is the observed state of the DHCPSubnet"},{"location":"reference/api/#dhcpsubnetspec","title":"DHCPSubnetSpec","text":"<p>DHCPSubnetSpec defines the desired state of DHCPSubnet</p> <p>Appears in: - DHCPSubnet</p> Field Description Default Validation <code>subnet</code> string Full VPC subnet name (including VPC name), such as \"vpc-0/default\" <code>cidrBlock</code> string CIDR block to use for VPC subnet, such as \"10.10.10.0/24\" <code>gateway</code> string Gateway, such as 10.10.10.1 <code>startIP</code> string Start IP from the CIDRBlock to allocate IPs, such as 10.10.10.10 <code>endIP</code> string End IP from the CIDRBlock to allocate IPs, such as 10.10.10.99 <code>vrf</code> string VRF name to identify specific VPC (will be added to DHCP packets by DHCP relay in suboption 151), such as \"VrfVvpc-1\" as it's named on switch <code>circuitID</code> string VLAN ID to identify specific subnet within the VPC, such as \"Vlan1000\" as it's named on switch <code>pxeURL</code> string PXEURL (optional) to identify the pxe server to use to boot hosts connected to this segment such as http://10.10.10.99/bootfilename or tftp://10.10.10.99/bootfilename, http query strings are not supported <code>dnsServers</code> string array DNSservers (optional) to configure Domain Name Servers for this particular segment such as: 10.10.10.1, 10.10.10.2 <code>timeServers</code> string array TimeServers (optional) NTP server addresses to configure for time servers for this particular segment such as: 10.10.10.1, 10.10.10.2 <code>interfaceMTU</code> integer InterfaceMTU (optional) is the MTU setting that the dhcp server will send to the clients. It is dependent on the client to honor this option. <code>defaultURL</code> string DefaultURL (optional) is the option 114 \"default-url\" to be sent to the clients"},{"location":"reference/api/#dhcpsubnetstatus","title":"DHCPSubnetStatus","text":"<p>DHCPSubnetStatus defines the observed state of DHCPSubnet</p> <p>Appears in: - DHCPSubnet</p> Field Description Default Validation <code>allocated</code> object (keys:string, values:DHCPAllocated) Allocated is a map of allocated IPs with expiry time and hostname from DHCP requests"},{"location":"reference/api/#vpcgithedgehogcomv1beta1","title":"vpc.githedgehog.com/v1beta1","text":"<p>Package v1beta1 contains API Schema definitions for the vpc v1beta1 API group. It is public API group for the VPCs and Externals APIs. Intended to be used by the user.</p>"},{"location":"reference/api/#resource-types_2","title":"Resource Types","text":"<ul> <li>External</li> <li>ExternalAttachment</li> <li>ExternalPeering</li> <li>IPv4Namespace</li> <li>VPC</li> <li>VPCAttachment</li> <li>VPCPeering</li> </ul>"},{"location":"reference/api/#external","title":"External","text":"<p>External object represents an external system connected to the Fabric and available to the specific IPv4Namespace. Users can do external peering with the external system by specifying the name of the External Object without need to worry about the details of how external system is attached to the Fabric.</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>External</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> ExternalSpec Spec is the desired state of the External <code>status</code> ExternalStatus Status is the observed state of the External"},{"location":"reference/api/#externalattachment","title":"ExternalAttachment","text":"<p>ExternalAttachment is a definition of how specific switch is connected with external system (External object). Effectively it represents BGP peering between the switch and external system including all needed configuration.</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>ExternalAttachment</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> ExternalAttachmentSpec Spec is the desired state of the ExternalAttachment <code>status</code> ExternalAttachmentStatus Status is the observed state of the ExternalAttachment"},{"location":"reference/api/#externalattachmentneighbor","title":"ExternalAttachmentNeighbor","text":"<p>ExternalAttachmentNeighbor defines the BGP neighbor configuration for the external attachment</p> <p>Appears in: - ExternalAttachmentSpec</p> Field Description Default Validation <code>asn</code> integer ASN is the ASN of the BGP neighbor <code>ip</code> string IP is the IP address of the BGP neighbor to peer with"},{"location":"reference/api/#externalattachmentspec","title":"ExternalAttachmentSpec","text":"<p>ExternalAttachmentSpec defines the desired state of ExternalAttachment</p> <p>Appears in: - ExternalAttachment</p> Field Description Default Validation <code>external</code> string External is the name of the External object this attachment belongs to <code>connection</code> string Connection is the name of the Connection object this attachment belongs to (essentially the name of the switch/port) <code>switch</code> ExternalAttachmentSwitch Switch is the switch port configuration for the external attachment <code>neighbor</code> ExternalAttachmentNeighbor Neighbor is the BGP neighbor configuration for the external attachment"},{"location":"reference/api/#externalattachmentstatus","title":"ExternalAttachmentStatus","text":"<p>ExternalAttachmentStatus defines the observed state of ExternalAttachment</p> <p>Appears in: - ExternalAttachment</p>"},{"location":"reference/api/#externalattachmentswitch","title":"ExternalAttachmentSwitch","text":"<p>ExternalAttachmentSwitch defines the switch port configuration for the external attachment</p> <p>Appears in: - ExternalAttachmentSpec</p> Field Description Default Validation <code>vlan</code> integer VLAN (optional) is the VLAN ID used for the subinterface on a switch port specified in the connection, set to 0 if no VLAN is used <code>ip</code> string IP is the IP address of the subinterface on a switch port specified in the connection"},{"location":"reference/api/#externalpeering","title":"ExternalPeering","text":"<p>ExternalPeering is the Schema for the externalpeerings API</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>ExternalPeering</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> ExternalPeeringSpec Spec is the desired state of the ExternalPeering <code>status</code> ExternalPeeringStatus Status is the observed state of the ExternalPeering"},{"location":"reference/api/#externalpeeringspec","title":"ExternalPeeringSpec","text":"<p>ExternalPeeringSpec defines the desired state of ExternalPeering</p> <p>Appears in: - ExternalPeering</p> Field Description Default Validation <code>permit</code> ExternalPeeringSpecPermit Permit defines the peering policy - which VPC and External to peer with and which subnets/prefixes to permit"},{"location":"reference/api/#externalpeeringspecexternal","title":"ExternalPeeringSpecExternal","text":"<p>ExternalPeeringSpecExternal defines the External-side of the configuration to peer with</p> <p>Appears in: - ExternalPeeringSpecPermit</p> Field Description Default Validation <code>name</code> string Name is the name of the External to peer with <code>prefixes</code> ExternalPeeringSpecPrefix array Prefixes is the list of prefixes to permit from the External to the VPC"},{"location":"reference/api/#externalpeeringspecpermit","title":"ExternalPeeringSpecPermit","text":"<p>ExternalPeeringSpecPermit defines the peering policy - which VPC and External to peer with and which subnets/prefixes to permit</p> <p>Appears in: - ExternalPeeringSpec</p> Field Description Default Validation <code>vpc</code> ExternalPeeringSpecVPC VPC is the VPC-side of the configuration to peer with <code>external</code> ExternalPeeringSpecExternal External is the External-side of the configuration to peer with"},{"location":"reference/api/#externalpeeringspecprefix","title":"ExternalPeeringSpecPrefix","text":"<p>ExternalPeeringSpecPrefix defines the prefix to permit from the External to the VPC</p> <p>Appears in: - ExternalPeeringSpecExternal</p> Field Description Default Validation <code>prefix</code> string Prefix is the subnet to permit from the External to the VPC, e.g. 0.0.0.0/0 for any route including default route.It matches any prefix length less than or equal to 32 effectively permitting all prefixes within the specified one."},{"location":"reference/api/#externalpeeringspecvpc","title":"ExternalPeeringSpecVPC","text":"<p>ExternalPeeringSpecVPC defines the VPC-side of the configuration to peer with</p> <p>Appears in: - ExternalPeeringSpecPermit</p> Field Description Default Validation <code>name</code> string Name is the name of the VPC to peer with <code>subnets</code> string array Subnets is the list of subnets to advertise from VPC to the External"},{"location":"reference/api/#externalpeeringstatus","title":"ExternalPeeringStatus","text":"<p>ExternalPeeringStatus defines the observed state of ExternalPeering</p> <p>Appears in: - ExternalPeering</p>"},{"location":"reference/api/#externalspec","title":"ExternalSpec","text":"<p>ExternalSpec describes IPv4 namespace External belongs to and inbound/outbound communities which are used to filter routes from/to the external system.</p> <p>Appears in: - External</p> Field Description Default Validation <code>ipv4Namespace</code> string IPv4Namespace is the name of the IPv4Namespace this External belongs to <code>inboundCommunity</code> string InboundCommunity is the inbound community to filter routes from the external system (e.g. 65102:5000) <code>outboundCommunity</code> string OutboundCommunity is theoutbound community that all outbound routes will be stamped with (e.g. 50000:50001)"},{"location":"reference/api/#externalstatus","title":"ExternalStatus","text":"<p>ExternalStatus defines the observed state of External</p> <p>Appears in: - External</p>"},{"location":"reference/api/#ipv4namespace","title":"IPv4Namespace","text":"<p>IPv4Namespace represents a namespace for VPC subnets allocation. All VPC subnets within a single IPv4Namespace are non-overlapping. Users can create multiple IPv4Namespaces to allocate same VPC subnets.</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>IPv4Namespace</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> IPv4NamespaceSpec Spec is the desired state of the IPv4Namespace <code>status</code> IPv4NamespaceStatus Status is the observed state of the IPv4Namespace"},{"location":"reference/api/#ipv4namespacespec","title":"IPv4NamespaceSpec","text":"<p>IPv4NamespaceSpec defines the desired state of IPv4Namespace</p> <p>Appears in: - IPv4Namespace</p> Field Description Default Validation <code>subnets</code> string array Subnets is the list of subnets to allocate VPC subnets from, couldn't overlap between each other and with Fabric reserved subnets MaxItems: 20 MinItems: 1"},{"location":"reference/api/#ipv4namespacestatus","title":"IPv4NamespaceStatus","text":"<p>IPv4NamespaceStatus defines the observed state of IPv4Namespace</p> <p>Appears in: - IPv4Namespace</p>"},{"location":"reference/api/#vpc","title":"VPC","text":"<p>VPC is 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.</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>VPC</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> VPCSpec Spec is the desired state of the VPC <code>status</code> VPCStatus Status is the observed state of the VPC"},{"location":"reference/api/#vpcattachment","title":"VPCAttachment","text":"<p>VPCAttachment is the Schema for the vpcattachments API</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>VPCAttachment</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> VPCAttachmentSpec Spec is the desired state of the VPCAttachment <code>status</code> VPCAttachmentStatus Status is the observed state of the VPCAttachment"},{"location":"reference/api/#vpcattachmentspec","title":"VPCAttachmentSpec","text":"<p>VPCAttachmentSpec defines the desired state of VPCAttachment</p> <p>Appears in: - VPCAttachment</p> Field Description Default Validation <code>subnet</code> string Subnet is the full name of the VPC subnet to attach to, such as \"vpc-1/default\" <code>connection</code> string Connection is the name of the connection to attach to the VPC <code>nativeVLAN</code> boolean NativeVLAN is the flag to indicate if the native VLAN should be used for attaching the VPC subnet"},{"location":"reference/api/#vpcattachmentstatus","title":"VPCAttachmentStatus","text":"<p>VPCAttachmentStatus defines the observed state of VPCAttachment</p> <p>Appears in: - VPCAttachment</p>"},{"location":"reference/api/#vpcdhcp","title":"VPCDHCP","text":"<p>VPCDHCP defines the on-demand DHCP configuration for the subnet</p> <p>Appears in: - VPCSubnet</p> Field Description Default Validation <code>relay</code> string Relay is the DHCP relay IP address, if specified, DHCP server will be disabled <code>enable</code> boolean Enable enables DHCP server for the subnet <code>range</code> VPCDHCPRange Range (optional) is the DHCP range for the subnet if DHCP server is enabled <code>options</code> VPCDHCPOptions Options (optional) is the DHCP options for the subnet if DHCP server is enabled"},{"location":"reference/api/#vpcdhcpoptions","title":"VPCDHCPOptions","text":"<p>VPCDHCPOptions defines the DHCP options for the subnet if DHCP server is enabled</p> <p>Appears in: - VPCDHCP</p> Field Description Default Validation <code>pxeURL</code> string PXEURL (optional) to identify the pxe server to use to boot hosts connected to this segment such as http://10.10.10.99/bootfilename or tftp://10.10.10.99/bootfilename, http query strings are not supported <code>dnsServers</code> string array DNSservers (optional) to configure Domain Name Servers for this particular segment such as: 10.10.10.1, 10.10.10.2 Optional: {}  <code>timeServers</code> string array TimeServers (optional) NTP server addresses to configure for time servers for this particular segment such as: 10.10.10.1, 10.10.10.2 Optional: {}  <code>interfaceMTU</code> integer InterfaceMTU (optional) is the MTU setting that the dhcp server will send to the clients. It is dependent on the client to honor this option."},{"location":"reference/api/#vpcdhcprange","title":"VPCDHCPRange","text":"<p>VPCDHCPRange defines the DHCP range for the subnet if DHCP server is enabled</p> <p>Appears in: - VPCDHCP</p> Field Description Default Validation <code>start</code> string Start is the start IP address of the DHCP range <code>end</code> string End is the end IP address of the DHCP range"},{"location":"reference/api/#vpcpeer","title":"VPCPeer","text":"<p>Appears in: - VPCPeeringSpec</p> Field Description Default Validation <code>subnets</code> string array Subnets is the list of subnets to advertise from current VPC to the peer VPC MaxItems: 10 MinItems: 1"},{"location":"reference/api/#vpcpeering","title":"VPCPeering","text":"<p>VPCPeering represents a peering between two VPCs with corresponding filtering rules. Minimal example of the VPC peering showing vpc-1 to vpc-2 peering with all subnets allowed:</p> <pre><code>spec:\n  permit:\n  - vpc-1: {}\n    vpc-2: {}\n</code></pre> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>VPCPeering</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> VPCPeeringSpec Spec is the desired state of the VPCPeering <code>status</code> VPCPeeringStatus Status is the observed state of the VPCPeering"},{"location":"reference/api/#vpcpeeringspec","title":"VPCPeeringSpec","text":"<p>VPCPeeringSpec defines the desired state of VPCPeering</p> <p>Appears in: - VPCPeering</p> Field Description Default Validation <code>remote</code> string <code>permit</code> map[string]VPCPeer array Permit defines a list of the peering policies - which VPC subnets will have access to the peer VPC subnets. MaxItems: 10 MinItems: 1"},{"location":"reference/api/#vpcpeeringstatus","title":"VPCPeeringStatus","text":"<p>VPCPeeringStatus defines the observed state of VPCPeering</p> <p>Appears in: - VPCPeering</p>"},{"location":"reference/api/#vpcspec","title":"VPCSpec","text":"<p>VPCSpec defines the desired state of VPC. At least one subnet is required.</p> <p>Appears in: - VPC</p> Field Description Default Validation <code>subnets</code> object (keys:string, values:VPCSubnet) Subnets is the list of VPC subnets to configure <code>ipv4Namespace</code> string IPv4Namespace is the name of the IPv4Namespace this VPC belongs to (if not specified, \"default\" is used) <code>vlanNamespace</code> string VLANNamespace is the name of the VLANNamespace this VPC belongs to (if not specified, \"default\" is used) <code>defaultIsolated</code> boolean DefaultIsolated sets default behavior for isolated mode for the subnets (disabled by default) <code>defaultRestricted</code> boolean DefaultRestricted sets default behavior for restricted mode for the subnets (disabled by default) <code>permit</code> string array array Permit defines a list of the access policies between the subnets within the VPC - each policy is a list of subnets that have access to each other.It's applied on top of the subnet isolation flag and if subnet isn't isolated it's not required to have it in a permit list while if vpc is markedas isolated it's required to have it in a permit list to have access to other subnets. <code>staticRoutes</code> VPCStaticRoute array StaticRoutes is the list of additional static routes for the VPC"},{"location":"reference/api/#vpcstaticroute","title":"VPCStaticRoute","text":"<p>VPCStaticRoute defines the static route for the VPC</p> <p>Appears in: - VPCSpec</p> Field Description Default Validation <code>prefix</code> string Prefix for the static route (mandatory), e.g. 10.42.0.0/24 <code>nextHops</code> string array NextHops for the static route (at least one is required), e.g. 10.99.0.0"},{"location":"reference/api/#vpcstatus","title":"VPCStatus","text":"<p>VPCStatus defines the observed state of VPC</p> <p>Appears in: - VPC</p>"},{"location":"reference/api/#vpcsubnet","title":"VPCSubnet","text":"<p>VPCSubnet defines the VPC subnet configuration</p> <p>Appears in: - VPCSpec</p> Field Description Default Validation <code>subnet</code> string Subnet is the subnet CIDR block, such as \"10.0.0.0/24\", should belong to the IPv4Namespace and be unique within the namespace <code>gateway</code> string Gateway (optional) for the subnet, if not specified, the first IP (e.g. 10.0.0.1) in the subnet is used as the gateway <code>dhcp</code> VPCDHCP DHCP is the on-demand DHCP configuration for the subnet <code>vlan</code> integer VLAN is the VLAN ID for the subnet, should belong to the VLANNamespace and be unique within the namespace <code>isolated</code> boolean Isolated is the flag to enable isolated mode for the subnet which means no access to and from the other subnets within the VPC <code>restricted</code> boolean Restricted is the flag to enable restricted mode for the subnet which means no access between hosts within the subnet itself"},{"location":"reference/api/#wiringgithedgehogcomv1beta1","title":"wiring.githedgehog.com/v1beta1","text":"<p>Package v1beta1 contains API Schema definitions for the wiring v1beta1 API group. It is public API group mainly for the underlay definition including Switches, Server, wiring between them and etc. Intended to be used by the user.</p>"},{"location":"reference/api/#resource-types_3","title":"Resource Types","text":"<ul> <li>Connection</li> <li>Server</li> <li>Switch</li> <li>SwitchGroup</li> <li>SwitchProfile</li> <li>VLANNamespace</li> </ul>"},{"location":"reference/api/#baseportname","title":"BasePortName","text":"<p>BasePortName defines the full name of the switch port</p> <p>Appears in: - ConnExternalLink - ConnFabricLinkSwitch - ConnStaticExternalLinkSwitch - ServerToSwitchLink - SwitchToSwitchLink</p> Field Description Default Validation <code>port</code> string Port defines the full name of the switch port in the format of \"device/port\", such as \"spine-1/Ethernet1\".SONiC port name is used as a port name and switch name should be same as the name of the Switch object."},{"location":"reference/api/#connbundled","title":"ConnBundled","text":"<p>ConnBundled defines the bundled connection (port channel, single server to a single switch with multiple links)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>links</code> ServerToSwitchLink array Links is the list of server-to-switch links <code>mtu</code> integer MTU is the MTU to be configured on the switch port or port channel"},{"location":"reference/api/#conneslag","title":"ConnESLAG","text":"<p>ConnESLAG defines the ESLAG connection (port channel, single server to 2-4 switches with multiple links)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>links</code> ServerToSwitchLink array Links is the list of server-to-switch links MinItems: 2  <code>mtu</code> integer MTU is the MTU to be configured on the switch port or port channel <code>fallback</code> boolean Fallback is the optional flag that used to indicate one of the links in LACP port channel to be used as a fallback link"},{"location":"reference/api/#connexternal","title":"ConnExternal","text":"<p>ConnExternal defines the external connection (single switch to a single external device with a single link)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>link</code> ConnExternalLink Link is the external connection link"},{"location":"reference/api/#connexternallink","title":"ConnExternalLink","text":"<p>ConnExternalLink defines the external connection link</p> <p>Appears in: - ConnExternal</p> Field Description Default Validation <code>switch</code> BasePortName"},{"location":"reference/api/#connfabric","title":"ConnFabric","text":"<p>ConnFabric defines the fabric connection (single spine to a single leaf with at least one link)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>links</code> FabricLink array Links is the list of spine-to-leaf links MinItems: 1"},{"location":"reference/api/#connfabriclinkswitch","title":"ConnFabricLinkSwitch","text":"<p>ConnFabricLinkSwitch defines the switch side of the fabric link</p> <p>Appears in: - FabricLink</p> Field Description Default Validation <code>port</code> string Port defines the full name of the switch port in the format of \"device/port\", such as \"spine-1/Ethernet1\".SONiC port name is used as a port name and switch name should be same as the name of the Switch object. <code>ip</code> string IP is the IP address of the switch side of the fabric link (switch port configuration) Pattern: <code>^((25[0-5]\\|(2[0-4]\\|1\\d\\|[1-9]\\|)\\d)\\.?\\b)\\{4\\}/([1-2]?[0-9]\\|3[0-2])$</code>"},{"location":"reference/api/#connmclag","title":"ConnMCLAG","text":"<p>ConnMCLAG defines the MCLAG connection (port channel, single server to pair of switches with multiple links)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>links</code> ServerToSwitchLink array Links is the list of server-to-switch links MinItems: 2  <code>mtu</code> integer MTU is the MTU to be configured on the switch port or port channel <code>fallback</code> boolean Fallback is the optional flag that used to indicate one of the links in LACP port channel to be used as a fallback link"},{"location":"reference/api/#connmclagdomain","title":"ConnMCLAGDomain","text":"<p>ConnMCLAGDomain defines the MCLAG domain connection which makes two switches into a single logical switch or redundancy group and allows to use MCLAG connections to connect servers in a multi-homed way.</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>peerLinks</code> SwitchToSwitchLink array PeerLinks is the list of peer links between the switches, used to pass server traffic between switch MinItems: 1  <code>sessionLinks</code> SwitchToSwitchLink array SessionLinks is the list of session links between the switches, used only to pass MCLAG control plane and BGPtraffic between switches MinItems: 1"},{"location":"reference/api/#connstaticexternal","title":"ConnStaticExternal","text":"<p>ConnStaticExternal defines the static external connection (single switch to a single external device with a single link)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>link</code> ConnStaticExternalLink Link is the static external connection link <code>withinVPC</code> string WithinVPC is the optional VPC name to provision the static external connection within the VPC VRF instead of default one to make resource available to the specific VPC"},{"location":"reference/api/#connstaticexternallink","title":"ConnStaticExternalLink","text":"<p>ConnStaticExternalLink defines the static external connection link</p> <p>Appears in: - ConnStaticExternal</p> Field Description Default Validation <code>switch</code> ConnStaticExternalLinkSwitch Switch is the switch side of the static external connection link"},{"location":"reference/api/#connstaticexternallinkswitch","title":"ConnStaticExternalLinkSwitch","text":"<p>ConnStaticExternalLinkSwitch defines the switch side of the static external connection link</p> <p>Appears in: - ConnStaticExternalLink</p> Field Description Default Validation <code>port</code> string Port defines the full name of the switch port in the format of \"device/port\", such as \"spine-1/Ethernet1\".SONiC port name is used as a port name and switch name should be same as the name of the Switch object. <code>ip</code> string IP is the IP address of the switch side of the static external connection link (switch port configuration) Pattern: <code>^((25[0-5]\\|(2[0-4]\\|1\\d\\|[1-9]\\|)\\d)\\.?\\b)\\{4\\}/([1-2]?[0-9]\\|3[0-2])$</code> <code>nextHop</code> string NextHop is the next hop IP address for static routes that will be created for the subnets Pattern: <code>^((25[0-5]\\|(2[0-4]\\|1\\d\\|[1-9]\\|)\\d)\\.?\\b)\\{4\\}$</code> <code>subnets</code> string array Subnets is the list of subnets that will get static routes using the specified next hop <code>vlan</code> integer VLAN is the optional VLAN ID to be configured on the switch port"},{"location":"reference/api/#connunbundled","title":"ConnUnbundled","text":"<p>ConnUnbundled defines the unbundled connection (no port channel, single server to a single switch with a single link)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>link</code> ServerToSwitchLink Link is the server-to-switch link <code>mtu</code> integer MTU is the MTU to be configured on the switch port or port channel"},{"location":"reference/api/#connvpcloopback","title":"ConnVPCLoopback","text":"<p>ConnVPCLoopback defines the VPC loopback connection (multiple port pairs on a single switch) that enables automated workaround named \"VPC Loopback\" that allow to avoid switch hardware limitations and traffic going through CPU in some cases</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>links</code> SwitchToSwitchLink array Links is the list of VPC loopback links MinItems: 1"},{"location":"reference/api/#connection","title":"Connection","text":"<p>Connection object represents a logical and physical connections between any devices in the Fabric (Switch, Server and External objects). It's needed to define all physical and logical connections between the devices in the Wiring Diagram. Connection type is defined by the top-level field in the ConnectionSpec. Exactly one of them could be used in a single Connection object.</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>Connection</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> ConnectionSpec Spec is the desired state of the Connection <code>status</code> ConnectionStatus Status is the observed state of the Connection"},{"location":"reference/api/#connectionspec","title":"ConnectionSpec","text":"<p>ConnectionSpec defines the desired state of Connection</p> <p>Appears in: - Connection</p> Field Description Default Validation <code>unbundled</code> ConnUnbundled Unbundled defines the unbundled connection (no port channel, single server to a single switch with a single link) <code>bundled</code> ConnBundled Bundled defines the bundled connection (port channel, single server to a single switch with multiple links) <code>mclag</code> ConnMCLAG MCLAG defines the MCLAG connection (port channel, single server to pair of switches with multiple links) <code>eslag</code> ConnESLAG ESLAG defines the ESLAG connection (port channel, single server to 2-4 switches with multiple links) <code>mclagDomain</code> ConnMCLAGDomain MCLAGDomain defines the MCLAG domain connection which makes two switches into a single logical switch for server multi-homing <code>fabric</code> ConnFabric Fabric defines the fabric connection (single spine to a single leaf with at least one link) <code>vpcLoopback</code> ConnVPCLoopback VPCLoopback defines the VPC loopback connection (multiple port pairs on a single switch) for automated workaround <code>external</code> ConnExternal External defines the external connection (single switch to a single external device with a single link) <code>staticExternal</code> ConnStaticExternal StaticExternal defines the static external connection (single switch to a single external device with a single link)"},{"location":"reference/api/#connectionstatus","title":"ConnectionStatus","text":"<p>ConnectionStatus defines the observed state of Connection</p> <p>Appears in: - Connection</p>"},{"location":"reference/api/#fabriclink","title":"FabricLink","text":"<p>FabricLink defines the fabric connection link</p> <p>Appears in: - ConnFabric</p> Field Description Default Validation <code>spine</code> ConnFabricLinkSwitch Spine is the spine side of the fabric link <code>leaf</code> ConnFabricLinkSwitch Leaf is the leaf side of the fabric link"},{"location":"reference/api/#server","title":"Server","text":"<p>Server is the Schema for the servers API</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>Server</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> ServerSpec Spec is desired state of the server <code>status</code> ServerStatus Status is the observed state of the server"},{"location":"reference/api/#serverfacingconnectionconfig","title":"ServerFacingConnectionConfig","text":"<p>ServerFacingConnectionConfig defines any server-facing connection (unbundled, bundled, mclag, etc.) configuration</p> <p>Appears in: - ConnBundled - ConnESLAG - ConnMCLAG - ConnUnbundled</p> Field Description Default Validation <code>mtu</code> integer MTU is the MTU to be configured on the switch port or port channel"},{"location":"reference/api/#serverspec","title":"ServerSpec","text":"<p>ServerSpec defines the desired state of Server</p> <p>Appears in: - Server</p> Field Description Default Validation <code>description</code> string Description is a description of the server <code>profile</code> string Profile is the profile of the server, name of the ServerProfile object to be used for this server, currently not used by the Fabric"},{"location":"reference/api/#serverstatus","title":"ServerStatus","text":"<p>ServerStatus defines the observed state of Server</p> <p>Appears in: - Server</p>"},{"location":"reference/api/#servertoswitchlink","title":"ServerToSwitchLink","text":"<p>ServerToSwitchLink defines the server-to-switch link</p> <p>Appears in: - ConnBundled - ConnESLAG - ConnMCLAG - ConnUnbundled</p> Field Description Default Validation <code>server</code> BasePortName Server is the server side of the connection <code>switch</code> BasePortName Switch is the switch side of the connection"},{"location":"reference/api/#switch","title":"Switch","text":"<p>Switch is the Schema for the switches API</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>Switch</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> SwitchSpec Spec is desired state of the switch <code>status</code> SwitchStatus Status is the observed state of the switch"},{"location":"reference/api/#switchboot","title":"SwitchBoot","text":"<p>Appears in: - SwitchSpec</p> Field Description Default Validation <code>serial</code> string Identify switch by serial number <code>mac</code> string Identify switch by MAC address of the management port"},{"location":"reference/api/#switchgroup","title":"SwitchGroup","text":"<p>SwitchGroup is the marker API object to group switches together, switch can belong to multiple groups</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>SwitchGroup</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> SwitchGroupSpec Spec is the desired state of the SwitchGroup <code>status</code> SwitchGroupStatus Status is the observed state of the SwitchGroup"},{"location":"reference/api/#switchgroupspec","title":"SwitchGroupSpec","text":"<p>SwitchGroupSpec defines the desired state of SwitchGroup</p> <p>Appears in: - SwitchGroup</p>"},{"location":"reference/api/#switchgroupstatus","title":"SwitchGroupStatus","text":"<p>SwitchGroupStatus defines the observed state of SwitchGroup</p> <p>Appears in: - SwitchGroup</p>"},{"location":"reference/api/#switchprofile","title":"SwitchProfile","text":"<p>SwitchProfile represents switch capabilities and configuration</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>SwitchProfile</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> SwitchProfileSpec <code>status</code> SwitchProfileStatus"},{"location":"reference/api/#switchprofileconfig","title":"SwitchProfileConfig","text":"<p>Defines switch-specific configuration options</p> <p>Appears in: - SwitchProfileSpec</p> Field Description Default Validation <code>maxPathsEBGP</code> integer MaxPathsIBGP defines the maximum number of IBGP paths to be configured"},{"location":"reference/api/#switchprofilefeatures","title":"SwitchProfileFeatures","text":"<p>Defines features supported by a specific switch which is later used for roles and Fabric API features usage validation</p> <p>Appears in: - SwitchProfileSpec</p> Field Description Default Validation <code>subinterfaces</code> boolean Subinterfaces defines if switch supports subinterfaces <code>vxlan</code> boolean VXLAN defines if switch supports VXLANs <code>acls</code> boolean ACLs defines if switch supports ACLs"},{"location":"reference/api/#switchprofileport","title":"SwitchProfilePort","text":"<p>Defines a switch port configuration Only one of Profile or Group can be set</p> <p>Appears in: - SwitchProfileSpec</p> Field Description Default Validation <code>nos</code> string NOSName defines how port is named in the NOS <code>baseNOSName</code> string BaseNOSName defines the base NOS name that could be used together with the profile to generate the actual NOS name (e.g. breakouts) <code>label</code> string Label defines the physical port label you can see on the actual switch <code>group</code> string If port isn't directly manageable, group defines the group it belongs to, exclusive with profile <code>profile</code> string If port is directly configurable, profile defines the profile it belongs to, exclusive with group <code>management</code> boolean Management defines if port is a management port, it's a special case and it can't have a group or profile <code>oniePortName</code> string OniePortName defines the ONIE port name for management ports only"},{"location":"reference/api/#switchprofileportgroup","title":"SwitchProfilePortGroup","text":"<p>Defines a switch port group configuration</p> <p>Appears in: - SwitchProfileSpec</p> Field Description Default Validation <code>nos</code> string NOSName defines how group is named in the NOS <code>profile</code> string Profile defines the possible configuration profile for the group, could only have speed profile"},{"location":"reference/api/#switchprofileportprofile","title":"SwitchProfilePortProfile","text":"<p>Defines a switch port profile configuration</p> <p>Appears in: - SwitchProfileSpec</p> Field Description Default Validation <code>speed</code> SwitchProfilePortProfileSpeed Speed defines the speed configuration for the profile, exclusive with breakout <code>breakout</code> SwitchProfilePortProfileBreakout Breakout defines the breakout configuration for the profile, exclusive with speed <code>autoNegAllowed</code> boolean AutoNegAllowed defines if configuring auto-negotiation is allowed for the port <code>autoNegDefault</code> boolean AutoNegDefault defines the default auto-negotiation state for the port"},{"location":"reference/api/#switchprofileportprofilebreakout","title":"SwitchProfilePortProfileBreakout","text":"<p>Defines a switch port profile breakout configuration</p> <p>Appears in: - SwitchProfilePortProfile</p> Field Description Default Validation <code>default</code> string Default defines the default breakout mode for the profile <code>supported</code> object (keys:string, values:SwitchProfilePortProfileBreakoutMode) Supported defines the supported breakout modes for the profile with the NOS name offsets"},{"location":"reference/api/#switchprofileportprofilebreakoutmode","title":"SwitchProfilePortProfileBreakoutMode","text":"<p>Defines a switch port profile breakout mode configuration</p> <p>Appears in: - SwitchProfilePortProfileBreakout</p> Field Description Default Validation <code>offsets</code> string array Offsets defines the breakout NOS port name offset from the port NOS Name for each breakout mode"},{"location":"reference/api/#switchprofileportprofilespeed","title":"SwitchProfilePortProfileSpeed","text":"<p>Defines a switch port profile speed configuration</p> <p>Appears in: - SwitchProfilePortProfile</p> Field Description Default Validation <code>default</code> string Default defines the default speed for the profile <code>supported</code> string array Supported defines the supported speeds for the profile"},{"location":"reference/api/#switchprofilespec","title":"SwitchProfileSpec","text":"<p>SwitchProfileSpec defines the desired state of SwitchProfile</p> <p>Appears in: - SwitchProfile</p> Field Description Default Validation <code>displayName</code> string DisplayName defines the human-readable name of the switch <code>otherNames</code> string array OtherNames defines alternative names for the switch <code>features</code> SwitchProfileFeatures Features defines the features supported by the switch <code>config</code> SwitchProfileConfig Config defines the switch-specific configuration options <code>ports</code> object (keys:string, values:SwitchProfilePort) Ports defines the switch port configuration <code>portGroups</code> object (keys:string, values:SwitchProfilePortGroup) PortGroups defines the switch port group configuration <code>portProfiles</code> object (keys:string, values:SwitchProfilePortProfile) PortProfiles defines the switch port profile configuration <code>nosType</code> NOSType NOSType defines the NOS type to be used for the switch <code>platform</code> string Platform is what expected to be request by ONIE and displayed in the NOS"},{"location":"reference/api/#switchprofilestatus","title":"SwitchProfileStatus","text":"<p>SwitchProfileStatus defines the observed state of SwitchProfile</p> <p>Appears in: - SwitchProfile</p>"},{"location":"reference/api/#switchredundancy","title":"SwitchRedundancy","text":"<p>SwitchRedundancy is the switch redundancy configuration which includes name of the redundancy group switch belongs to and its type, used both for MCLAG and ESLAG connections. It defines how redundancy will be configured and handled on the switch as well as which connection types will be available. If not specified, switch will not be part of any redundancy group. If name isn't empty, type must be specified as well and name should be the same as one of the SwitchGroup objects.</p> <p>Appears in: - SwitchSpec</p> Field Description Default Validation <code>group</code> string Group is the name of the redundancy group switch belongs to <code>type</code> RedundancyType Type is the type of the redundancy group, could be mclag or eslag"},{"location":"reference/api/#switchrole","title":"SwitchRole","text":"<p>Underlying type: string</p> <p>SwitchRole is the role of the switch, could be spine, server-leaf or border-leaf or mixed-leaf</p> <p>Validation: - Enum: [spine server-leaf border-leaf mixed-leaf virtual-edge]</p> <p>Appears in: - SwitchSpec</p> Field Description <code>spine</code> <code>server-leaf</code> <code>border-leaf</code> <code>mixed-leaf</code> <code>virtual-edge</code>"},{"location":"reference/api/#switchspec","title":"SwitchSpec","text":"<p>SwitchSpec defines the desired state of Switch</p> <p>Appears in: - Switch</p> Field Description Default Validation <code>role</code> SwitchRole Role is the role of the switch, could be spine, server-leaf or border-leaf or mixed-leaf Enum: [spine server-leaf border-leaf mixed-leaf virtual-edge] Required: {}  <code>description</code> string Description is a description of the switch <code>profile</code> string Profile is the profile of the switch, name of the SwitchProfile object to be used for this switch, currently not used by the Fabric <code>groups</code> string array Groups is a list of switch groups the switch belongs to <code>redundancy</code> SwitchRedundancy Redundancy is the switch redundancy configuration including name of the redundancy group switch belongs to and its type, used both for MCLAG and ESLAG connections <code>vlanNamespaces</code> string array VLANNamespaces is a list of VLAN namespaces the switch is part of, their VLAN ranges could not overlap <code>asn</code> integer ASN is the ASN of the switch <code>ip</code> string IP is the IP of the switch that could be used to access it from other switches and control nodes in the Fabric <code>vtepIP</code> string VTEPIP is the VTEP IP of the switch <code>protocolIP</code> string ProtocolIP is used as BGP Router ID for switch configuration <code>portGroupSpeeds</code> object (keys:string, values:string) PortGroupSpeeds is a map of port group speeds, key is the port group name, value is the speed, such as '\"2\": 10G' <code>portSpeeds</code> object (keys:string, values:string) PortSpeeds is a map of port speeds, key is the port name, value is the speed <code>portBreakouts</code> object (keys:string, values:string) PortBreakouts is a map of port breakouts, key is the port name, value is the breakout configuration, such as \"1/55: 4x25G\" <code>portAutoNegs</code> object (keys:string, values:boolean) PortAutoNegs is a map of port auto negotiation, key is the port name, value is true or false <code>boot</code> SwitchBoot Boot is the boot/provisioning information of the switch"},{"location":"reference/api/#switchstatus","title":"SwitchStatus","text":"<p>SwitchStatus defines the observed state of Switch</p> <p>Appears in: - Switch</p>"},{"location":"reference/api/#switchtoswitchlink","title":"SwitchToSwitchLink","text":"<p>SwitchToSwitchLink defines the switch-to-switch link</p> <p>Appears in: - ConnMCLAGDomain - ConnVPCLoopback</p> Field Description Default Validation <code>switch1</code> BasePortName Switch1 is the first switch side of the connection <code>switch2</code> BasePortName Switch2 is the second switch side of the connection"},{"location":"reference/api/#vlannamespace","title":"VLANNamespace","text":"<p>VLANNamespace is the Schema for the vlannamespaces API</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>VLANNamespace</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> VLANNamespaceSpec Spec is the desired state of the VLANNamespace <code>status</code> VLANNamespaceStatus Status is the observed state of the VLANNamespace"},{"location":"reference/api/#vlannamespacespec","title":"VLANNamespaceSpec","text":"<p>VLANNamespaceSpec defines the desired state of VLANNamespace</p> <p>Appears in: - VLANNamespace</p> Field Description Default Validation <code>ranges</code> VLANRange array Ranges is a list of VLAN ranges to be used in this namespace, couldn't overlap between each other and with Fabric reserved VLAN ranges MaxItems: 20 MinItems: 1"},{"location":"reference/api/#vlannamespacestatus","title":"VLANNamespaceStatus","text":"<p>VLANNamespaceStatus defines the observed state of VLANNamespace</p> <p>Appears in: - VLANNamespace</p>"},{"location":"reference/cli/","title":"Fabric CLI","text":"<p>Under construction.</p> <p>Currently Fabric CLI is represented by a kubectl plugin <code>kubectl-fabric</code> automatically installed on the Control Node. It is a wrapper around <code>kubectl</code> and Kubernetes client which allows to manage Fabric resources in a more convenient way. Fabric CLI only provides a subset of the functionality available via Fabric API and is focused on simplifying objects creation and some manipulation with the already existing objects while main get/list/update operations are expected to be done using <code>kubectl</code>.</p> <pre><code>core@control-1 ~ $ kubectl fabric\nNAME:\n   kubectl fabric - Hedgehog Fabric API kubectl plugin\n\nUSAGE:\n   kubectl fabric [global options] command [command options]\n\nVERSION:\n   v0.53.1\n\nCOMMANDS:\n   vpc               VPC commands\n   switch, sw        Switch commands\n   connection, conn  Connection commands\n   switchgroup, sg   SwitchGroup commands\n   external, ext     External commands\n   inspect, i        Inspect Fabric API Objects and Primitives\n   help, h           Shows a list of commands or help for one command\n\nGLOBAL OPTIONS:\n   --verbose, -v  verbose output (includes debug) (default: true)\n   --help, -h     show help\n   --version, -V  print the version\n</code></pre>"},{"location":"reference/cli/#vpc","title":"VPC","text":"<p>Create VPC named <code>vpc-1</code> with subnet <code>10.0.1.0/24</code> and VLAN <code>1001</code> with DHCP enabled and DHCP range starting from <code>10.0.1.10</code> (optional):</p> <pre><code>core@control-1 ~ $ kubectl fabric vpc create --name vpc-1 --subnet 10.0.1.0/24 --vlan 1001 --dhcp --dhcp-start 10.0.1.10\n</code></pre> <p>Attach previously created VPC to the server <code>server-01</code> (which is connected to the Fabric using the <code>server-01--mclag--leaf-01--leaf-02</code> Connection):</p> <pre><code>core@control-1 ~ $ kubectl fabric vpc attach --vpc-subnet vpc-1/default --connection server-01--mclag--leaf-01--leaf-02\n</code></pre> <p>To peer VPC with another VPC (e.g. <code>vpc-2</code>) use the following command:</p> <pre><code>core@control-1 ~ $ kubectl fabric vpc peer --vpc vpc-1 --vpc vpc-2\n</code></pre>"},{"location":"reference/profiles/","title":"Switch Profiles Catalog","text":"<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>"},{"location":"reference/profiles/#celestica-ds3000","title":"Celestica DS3000","text":"<p>Profile Name (to use in switch.spec.profile): celestica-ds3000</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/2 2 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/3 3 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/4 4 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/5 5 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/6 6 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/7 7 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/8 8 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/9 9 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/10 10 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/11 11 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/12 12 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/13 13 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/14 14 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/15 15 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/16 16 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/17 17 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/18 18 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/19 19 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/20 20 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/21 21 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/22 22 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/23 23 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/24 24 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/25 25 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/26 26 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/27 27 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/28 28 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/29 29 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/30 30 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/31 31 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/32 32 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/33 33 Direct 10G 1G, 10G"},{"location":"reference/profiles/#celestica-ds4000","title":"Celestica DS4000","text":"<p>Profile Name (to use in switch.spec.profile): celestica-ds4000</p> <p>Supported features:</p> <ul> <li>Subinterfaces: false</li> <li>VXLAN: false</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/2 2 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/3 3 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/4 4 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/5 5 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/6 6 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/7 7 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/8 8 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/9 9 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/10 10 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/11 11 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/12 12 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/13 13 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/14 14 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/15 15 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/16 16 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/17 17 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/18 18 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/19 19 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/20 20 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/21 21 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/22 22 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/23 23 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/24 24 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/25 25 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/26 26 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/27 27 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/28 28 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/29 29 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/30 30 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/31 31 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/32 32 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/33 33 Direct 10G 1G, 10G"},{"location":"reference/profiles/#dell-s5232f-on","title":"Dell S5232F-ON","text":"<p>Profile Name (to use in switch.spec.profile): dell-s5232f-on</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/2 2 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/3 3 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/4 4 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/5 5 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/6 6 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/7 7 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/8 8 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/9 9 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/10 10 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/11 11 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/12 12 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/13 13 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/14 14 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/15 15 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/16 16 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/17 17 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/18 18 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/19 19 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/20 20 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/21 21 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/22 22 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/23 23 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/24 24 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/25 25 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/26 26 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/27 27 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/28 28 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/29 29 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/30 30 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/31 31 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/32 32 Direct 100G 40G, 100G E1/33 33 Direct 10G 1G, 10G E1/34 34 Direct 10G 1G, 10G"},{"location":"reference/profiles/#dell-s5248f-on","title":"Dell S5248F-ON","text":"<p>Profile Name (to use in switch.spec.profile): dell-s5248f-on</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Port Group 1 25G 10G, 25G E1/2 2 Port Group 1 25G 10G, 25G E1/3 3 Port Group 1 25G 10G, 25G E1/4 4 Port Group 1 25G 10G, 25G E1/5 5 Port Group 2 25G 10G, 25G E1/6 6 Port Group 2 25G 10G, 25G E1/7 7 Port Group 2 25G 10G, 25G E1/8 8 Port Group 2 25G 10G, 25G E1/9 9 Port Group 3 25G 10G, 25G E1/10 10 Port Group 3 25G 10G, 25G E1/11 11 Port Group 3 25G 10G, 25G E1/12 12 Port Group 3 25G 10G, 25G E1/13 13 Port Group 4 25G 10G, 25G E1/14 14 Port Group 4 25G 10G, 25G E1/15 15 Port Group 4 25G 10G, 25G E1/16 16 Port Group 4 25G 10G, 25G E1/17 17 Port Group 5 25G 10G, 25G E1/18 18 Port Group 5 25G 10G, 25G E1/19 19 Port Group 5 25G 10G, 25G E1/20 20 Port Group 5 25G 10G, 25G E1/21 21 Port Group 6 25G 10G, 25G E1/22 22 Port Group 6 25G 10G, 25G E1/23 23 Port Group 6 25G 10G, 25G E1/24 24 Port Group 6 25G 10G, 25G E1/25 25 Port Group 7 25G 10G, 25G E1/26 26 Port Group 7 25G 10G, 25G E1/27 27 Port Group 7 25G 10G, 25G E1/28 28 Port Group 7 25G 10G, 25G E1/29 29 Port Group 8 25G 10G, 25G E1/30 30 Port Group 8 25G 10G, 25G E1/31 31 Port Group 8 25G 10G, 25G E1/32 32 Port Group 8 25G 10G, 25G E1/33 33 Port Group 9 25G 10G, 25G E1/34 34 Port Group 9 25G 10G, 25G E1/35 35 Port Group 9 25G 10G, 25G E1/36 36 Port Group 9 25G 10G, 25G E1/37 37 Port Group 10 25G 10G, 25G E1/38 38 Port Group 10 25G 10G, 25G E1/39 39 Port Group 10 25G 10G, 25G E1/40 40 Port Group 10 25G 10G, 25G E1/41 41 Port Group 11 25G 10G, 25G E1/42 42 Port Group 11 25G 10G, 25G E1/43 43 Port Group 11 25G 10G, 25G E1/44 44 Port Group 11 25G 10G, 25G E1/45 45 Port Group 12 25G 10G, 25G E1/46 46 Port Group 12 25G 10G, 25G E1/47 47 Port Group 12 25G 10G, 25G E1/48 48 Port Group 12 25G 10G, 25G E1/49 49 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/50 50 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/51 51 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/52 52 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/53 53 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/54 54 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/55 55 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/56 56 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G"},{"location":"reference/profiles/#dell-z9332f-on","title":"Dell Z9332F-ON","text":"<p>Profile Name (to use in switch.spec.profile): dell-z9332f-on</p> <p>Supported features:</p> <ul> <li>Subinterfaces: false</li> <li>VXLAN: false</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/2 2 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/3 3 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/4 4 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/5 5 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/6 6 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/7 7 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/8 8 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/9 9 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/10 10 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/11 11 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/12 12 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/13 13 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/14 14 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/15 15 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/16 16 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/17 17 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/18 18 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/19 19 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/20 20 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/21 21 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/22 22 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/23 23 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/24 24 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/25 25 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/26 26 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/27 27 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/28 28 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/29 29 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/30 30 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/31 31 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/32 32 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/33 M1 Direct 10G 1G, 10G E1/34 M2 Direct 10G 1G, 10G"},{"location":"reference/profiles/#edgecore-dcs203","title":"Edgecore DCS203","text":"<p>Profile Name (to use in switch.spec.profile): edgecore-dcs203</p> <p>Other names: Edgecore AS7326-56X</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Port Group 1 25G 10G, 25G E1/2 2 Port Group 1 25G 10G, 25G E1/3 3 Port Group 1 25G 10G, 25G E1/4 4 Port Group 1 25G 10G, 25G E1/5 5 Port Group 1 25G 10G, 25G E1/6 6 Port Group 1 25G 10G, 25G E1/7 7 Port Group 1 25G 10G, 25G E1/8 8 Port Group 1 25G 10G, 25G E1/9 9 Port Group 1 25G 10G, 25G E1/10 10 Port Group 1 25G 10G, 25G E1/11 11 Port Group 1 25G 10G, 25G E1/12 12 Port Group 1 25G 10G, 25G E1/13 13 Port Group 2 25G 10G, 25G E1/14 14 Port Group 2 25G 10G, 25G E1/15 15 Port Group 2 25G 10G, 25G E1/16 16 Port Group 2 25G 10G, 25G E1/17 17 Port Group 2 25G 10G, 25G E1/18 18 Port Group 2 25G 10G, 25G E1/19 19 Port Group 2 25G 10G, 25G E1/20 20 Port Group 2 25G 10G, 25G E1/21 21 Port Group 2 25G 10G, 25G E1/22 22 Port Group 2 25G 10G, 25G E1/23 23 Port Group 2 25G 10G, 25G E1/24 24 Port Group 2 25G 10G, 25G E1/25 25 Port Group 3 25G 10G, 25G E1/26 26 Port Group 3 25G 10G, 25G E1/27 27 Port Group 3 25G 10G, 25G E1/28 28 Port Group 3 25G 10G, 25G E1/29 29 Port Group 3 25G 10G, 25G E1/30 30 Port Group 3 25G 10G, 25G E1/31 31 Port Group 3 25G 10G, 25G E1/32 32 Port Group 3 25G 10G, 25G E1/33 33 Port Group 3 25G 10G, 25G E1/34 34 Port Group 3 25G 10G, 25G E1/35 35 Port Group 3 25G 10G, 25G E1/36 36 Port Group 3 25G 10G, 25G E1/37 37 Port Group 4 25G 10G, 25G E1/38 38 Port Group 4 25G 10G, 25G E1/39 39 Port Group 4 25G 10G, 25G E1/40 40 Port Group 4 25G 10G, 25G E1/41 41 Port Group 4 25G 10G, 25G E1/42 42 Port Group 4 25G 10G, 25G E1/43 43 Port Group 4 25G 10G, 25G E1/44 44 Port Group 4 25G 10G, 25G E1/45 45 Port Group 4 25G 10G, 25G E1/46 46 Port Group 4 25G 10G, 25G E1/47 47 Port Group 4 25G 10G, 25G E1/48 48 Port Group 4 25G 10G, 25G E1/49 49 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/50 50 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/51 51 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/52 52 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/53 53 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/54 54 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/55 55 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/56 56 Direct 100G 40G, 100G E1/57 57 Direct 10G 1G, 10G E1/58 58 Direct 10G 1G, 10G"},{"location":"reference/profiles/#edgecore-dcs204","title":"Edgecore DCS204","text":"<p>Profile Name (to use in switch.spec.profile): edgecore-dcs204</p> <p>Other names: Edgecore AS7726-32X</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/2 2 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/3 3 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/4 4 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/5 5 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/6 6 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/7 7 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/8 8 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/9 9 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/10 10 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/11 11 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/12 12 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/13 13 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/14 14 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/15 15 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/16 16 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/17 17 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/18 18 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/19 19 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/20 20 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/21 21 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/22 22 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/23 23 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/24 24 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/25 25 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/26 26 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/27 27 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/28 28 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/29 29 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/30 30 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/31 31 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/32 32 Direct 100G 40G, 100G E1/33 33 Direct 10G 1G, 10G E1/34 34 Direct 10G 1G, 10G"},{"location":"reference/profiles/#edgecore-dcs501","title":"Edgecore DCS501","text":"<p>Profile Name (to use in switch.spec.profile): edgecore-dcs501</p> <p>Other names: Edgecore AS7712-32X</p> <p>Supported features:</p> <ul> <li>Subinterfaces: false</li> <li>VXLAN: false</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/2 2 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/3 3 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/4 4 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/5 5 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/6 6 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/7 7 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/8 8 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/9 9 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/10 10 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/11 11 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/12 12 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/13 13 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/14 14 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/15 15 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/16 16 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/17 17 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/18 18 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/19 19 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/20 20 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/21 21 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/22 22 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/23 23 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/24 24 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/25 25 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/26 26 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/27 27 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/28 28 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/29 29 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/30 30 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/31 31 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/32 32 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G"},{"location":"reference/profiles/#edgecore-eps203","title":"Edgecore EPS203","text":"<p>Profile Name (to use in switch.spec.profile): edgecore-eps203</p> <p>Other names: Edgecore AS4630-54NPE</p> <p>Supported features:</p> <ul> <li>Subinterfaces: false</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/2 2 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/3 3 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/4 4 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/5 5 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/6 6 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/7 7 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/8 8 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/9 9 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/10 10 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/11 11 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/12 12 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/13 13 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/14 14 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/15 15 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/16 16 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/17 17 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/18 18 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/19 19 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/20 20 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/21 21 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/22 22 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/23 23 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/24 24 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/25 25 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/26 26 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/27 27 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/28 28 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/29 29 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/30 30 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/31 31 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/32 32 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/33 33 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/34 34 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/35 35 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/36 36 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/37 37 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/38 38 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/39 39 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/40 40 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/41 41 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/42 42 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/43 43 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/44 44 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/45 45 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/46 46 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/47 47 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/48 48 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/49 49 Direct 25G 1G, 10G, 25G E1/50 50 Direct 25G 1G, 10G, 25G E1/51 51 Direct 25G 1G, 10G, 25G E1/52 52 Direct 25G 1G, 10G, 25G E1/53 53 Direct 100G 40G, 100G E1/54 54 Direct 100G 40G, 100G"},{"location":"reference/profiles/#supermicro-sse-c4632sb","title":"Supermicro SSE-C4632SB","text":"<p>Profile Name (to use in switch.spec.profile): supermicro-sse-c4632sb</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/2 2 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/3 3 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/4 4 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/5 5 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/6 6 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/7 7 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/8 8 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/9 9 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/10 10 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/11 11 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/12 12 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/13 13 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/14 14 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/15 15 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/16 16 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/17 17 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/18 18 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/19 19 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/20 20 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/21 21 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/22 22 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/23 23 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/24 24 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/25 25 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/26 26 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/27 27 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/28 28 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/29 29 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/30 30 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/31 31 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/32 32 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/33 33 Direct 10G 1G, 10G"},{"location":"reference/profiles/#virtual-switch","title":"Virtual Switch","text":"<p>Profile Name (to use in switch.spec.profile): vs</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: false</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Port Group 1 25G 10G, 25G E1/2 2 Port Group 1 25G 10G, 25G E1/3 3 Port Group 1 25G 10G, 25G E1/4 4 Port Group 1 25G 10G, 25G E1/5 5 Port Group 2 25G 10G, 25G E1/6 6 Port Group 2 25G 10G, 25G E1/7 7 Port Group 2 25G 10G, 25G E1/8 8 Port Group 2 25G 10G, 25G E1/9 9 Port Group 3 25G 10G, 25G E1/10 10 Port Group 3 25G 10G, 25G E1/11 11 Port Group 3 25G 10G, 25G E1/12 12 Port Group 3 25G 10G, 25G E1/13 13 Port Group 4 25G 10G, 25G E1/14 14 Port Group 4 25G 10G, 25G E1/15 15 Port Group 4 25G 10G, 25G E1/16 16 Port Group 4 25G 10G, 25G E1/17 17 Port Group 5 25G 10G, 25G E1/18 18 Port Group 5 25G 10G, 25G E1/19 19 Port Group 5 25G 10G, 25G E1/20 20 Port Group 5 25G 10G, 25G E1/21 21 Port Group 6 25G 10G, 25G E1/22 22 Port Group 6 25G 10G, 25G E1/23 23 Port Group 6 25G 10G, 25G E1/24 24 Port Group 6 25G 10G, 25G E1/25 25 Port Group 7 25G 10G, 25G E1/26 26 Port Group 7 25G 10G, 25G E1/27 27 Port Group 7 25G 10G, 25G E1/28 28 Port Group 7 25G 10G, 25G E1/29 29 Port Group 8 25G 10G, 25G E1/30 30 Port Group 8 25G 10G, 25G E1/31 31 Port Group 8 25G 10G, 25G E1/32 32 Port Group 8 25G 10G, 25G E1/33 33 Port Group 9 25G 10G, 25G E1/34 34 Port Group 9 25G 10G, 25G E1/35 35 Port Group 9 25G 10G, 25G E1/36 36 Port Group 9 25G 10G, 25G E1/37 37 Port Group 10 25G 10G, 25G E1/38 38 Port Group 10 25G 10G, 25G E1/39 39 Port Group 10 25G 10G, 25G E1/40 40 Port Group 10 25G 10G, 25G E1/41 41 Port Group 11 25G 10G, 25G E1/42 42 Port Group 11 25G 10G, 25G E1/43 43 Port Group 11 25G 10G, 25G E1/44 44 Port Group 11 25G 10G, 25G E1/45 45 Port Group 12 25G 10G, 25G E1/46 46 Port Group 12 25G 10G, 25G E1/47 47 Port Group 12 25G 10G, 25G E1/48 48 Port Group 12 25G 10G, 25G E1/49 49 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/50 50 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/51 51 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/52 52 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/53 53 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/54 54 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/55 55 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/56 56 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G"},{"location":"release-notes/","title":"Release notes","text":""},{"location":"release-notes/#beta-1","title":"Beta-1","text":""},{"location":"release-notes/#device-support","title":"Device support","text":"<ul> <li>Celestica DS4000 as a spine</li> </ul>"},{"location":"release-notes/#sonic","title":"SONiC","text":"<ul> <li>Broadcom SONiC 4.4.0 support</li> </ul>"},{"location":"release-notes/#fabric-provisioning-management","title":"Fabric provisioning, management","text":"<ul> <li>Out-of-band management network connectivity</li> <li>Deprecated support for in-band management network connectivity, chain boot, and front-panel boot until further notice</li> <li>Automatic zero touch switch provisioning [ ZTP ] is based on the serial number or the first management interface MAC address</li> <li>Full support for airgap installations and upgrades by default</li> <li>Self-contained USB image generation for control node installation</li> <li>Automated in-place upgrades for control node(s) moving forward</li> </ul>"},{"location":"release-notes/#api","title":"API","text":"<ul> <li>API version v1beta1</li> <li>Guaranteed backward compatibility moving forward</li> </ul>"},{"location":"release-notes/#alpha-7","title":"Alpha-7","text":""},{"location":"release-notes/#device-support_1","title":"Device Support","text":"<p>New devices supported by the fabric:</p> <ul> <li> <p>Clos Spine</p> <ul> <li>Celestica DS3000</li> <li>Edgecore AS7712-32X-EC</li> <li>Supermicro SSE-C4632SB</li> </ul> </li> <li> <p>Clos Leaf</p> <ul> <li>Celestica DS3000</li> <li>Supermicro SSE-C4632SB</li> </ul> </li> <li> <p>Collapsed Core ToR</p> <ul> <li>Celestica DS3000</li> <li>Supermicro SSE-C4632SB</li> </ul> </li> </ul>"},{"location":"release-notes/#switchprofiles","title":"SwitchProfiles","text":"<ul> <li>Metadata describing switch capabilities, feature capacities, and resource naming mapping.</li> <li>Switch Profiles are used for providing normalized name/id mapping, validation and internal resource management.</li> <li>Switch Profiles are Mandatory. Each switch model must have a corresponding switch profile to be supported by the fabric.</li> <li>Each switch defined in the wiring diagram should be pointing to the switch profile document.</li> <li>Detailed overview</li> <li>Catalog of switch profiles</li> </ul>"},{"location":"release-notes/#new-universal-port-naming-scheme","title":"New Universal Port Naming Scheme","text":"<ul> <li><code>E&lt;asic&gt;/&lt;port&gt;/&lt;breakout&gt;</code> or <code>M&lt;port&gt;</code></li> <li>Enabled via switch profiles</li> </ul>"},{"location":"release-notes/#improved-per-switch-modelplatform-validation","title":"Improved per switch-model/platform validation","text":"<ul> <li>Enabled via switch profiles</li> </ul>"},{"location":"release-notes/#vpc","title":"VPC","text":"<ul> <li>It\u2019s now possible to explicitly specify a gateway to use in VPC subnets</li> <li>StaticExternal now supports default routes</li> </ul>"},{"location":"release-notes/#inspection-cli","title":"Inspection CLI","text":"<p>CLI commands are intended to navigate fabric configuration and state and allow introspection of the dependencies and cross-domain checking:</p> <ul> <li>Fabric (overall control nodes and switches overview incl. status, serials, etc.)</li> <li>Switch (status, used ports, counters, etc.)</li> <li>Switch sort (connection if used in one, counters, VPC and External attachments, etc.)</li> <li>Server (connection if used in one, VPC attachments, etc.)</li> <li>Connection (incl. VPC and External attachments, Loobpback Workaround usage, etc.)</li> <li>VPC/VPCSubnet (incl. where is it attached and what's reachable from it)</li> <li>IP Address (incl. IPv4Namespace, VPCSubnet and DHCPLease or External/StaticExternal usage)</li> <li>MAC Address (incl. switch ports and DHCP leases)</li> <li>Access between pair of IPs, Server names or VPCSubnets (everything except external IPs will be translated to VPCSubnets)</li> </ul>"},{"location":"release-notes/#observability","title":"Observability","text":"<ul> <li>Example Grafana Dashboards added to the docs</li> <li>Syslog (<code>/var/log/syslog</code>) is now could be collected from all switches and forwarded to Loki targets</li> </ul>"},{"location":"release-notes/#bug-fixes","title":"Bug Fixes","text":"<ul> <li>Fixed: Restricted subnet isn't accessible from other subnets of the same VPC</li> </ul>"},{"location":"release-notes/#alpha-6","title":"Alpha-6","text":""},{"location":"release-notes/#observability_1","title":"Observability","text":""},{"location":"release-notes/#telemetry-prometheus-exporter","title":"Telemetry - Prometheus Exporter","text":"<ul> <li> <p>Hedgehog Fabric Control Plane Agents on switches function as Prometheus Exporters</p> </li> <li> <p>Telemetry data provided by Broadcom SONiC is now supported:</p> <ul> <li>port and interface status and counters</li> <li>transceiver state</li> <li>environmental information (temperature, fans, psu, etc.)</li> <li>BGP state and counters</li> </ul> </li> <li> <p>Export to Prometheus using Prometheus Remote-Write API or any API-compatible platform</p> </li> </ul>"},{"location":"release-notes/#logging","title":"Logging","text":"<ul> <li> <p>Grafana Alloy is supported as a certified logging agent that is installed and managed by the Fabric</p> </li> <li> <p>Data collected</p> <ul> <li>Agent logs</li> <li>Agent, switch, and host-level metrics</li> </ul> </li> <li> <p>Export to API-compliant platforms and products such as Prometheus, Loki, Grafana Cloud, or any LGTM stack</p> </li> </ul>"},{"location":"release-notes/#agent-status-api-enhancements","title":"Agent Status API Enhancements","text":"<ul> <li>Ports status and counters</li> <li>Port breakout status and counters</li> <li>Transceiver status and counters</li> <li>Environmental and platform information</li> <li>LLDP neighbors</li> </ul>"},{"location":"release-notes/#networking-enhancements","title":"Networking enhancements","text":"<ul> <li>Multiple direct control links per switch are now supported</li> <li>Custom static routes could be installed into VPC using API</li> <li>ExternalAttachment could be configured without VLAN now</li> </ul>"},{"location":"release-notes/#other-improvements","title":"Other improvements","text":"<ul> <li>PXE boot with HTTP</li> <li>The <code>hhfab</code> and <code>hhfctl</code> (kubectl plugin) are now published for Linux/MacOS amd64/arm64</li> <li>Switch users can now be configured as part of installation preparation  (username, password hash, role, and public   keys)</li> </ul>"},{"location":"release-notes/#bugs-fixed","title":"Bugs fixed","text":"<ul> <li>DHCP service assigning IP multiple times if restarted in between</li> <li>Remote peering was configured as a local</li> </ul>"},{"location":"release-notes/#alpha-5","title":"Alpha-5","text":""},{"location":"release-notes/#open-source","title":"Open Source","text":"<ul> <li>Apache License 2.0</li> <li>The main repos are public:<ul> <li>Fabric</li> <li>Fabricator</li> <li>Das-boot</li> <li>Toolbox</li> <li>Docs</li> </ul> </li> <li>Items not open-sourced:<ul> <li>HONIE with front panel booting support</li> </ul> </li> </ul>"},{"location":"release-notes/#dhcppxe-boot-support-for-multi-homed-connections","title":"DHCP/PXE boot support for multi-homed connections","text":"<ul> <li>PXE URL support for on-demand DHCP service</li> <li>LACP link (MCLAG and ESLAG) fallback allows support of one of the links without the use of a host-level bond</li> </ul>"},{"location":"release-notes/#improvements","title":"Improvements","text":"<ul> <li>Native VLAN support for server-facing connections</li> <li>Extended wiring validation at hhfab init/build time</li> <li>External peering failover in case of using remote peering on the same switches as external connectivity</li> </ul>"},{"location":"release-notes/#alpha-4","title":"Alpha-4","text":""},{"location":"release-notes/#documentation","title":"Documentation","text":"<ul> <li>Fabric API reference</li> </ul>"},{"location":"release-notes/#host-connectivity-dual-homing-improvements","title":"Host connectivity dual homing improvements","text":"<ul> <li>ESI for VXLAN-based BGP EVPN</li> <li>Support in Fabric and VLAB</li> <li>Host connectivity Redundancy Groups</li> <li>Groups LEAF switches to provide multi-homed connectivity to the Fabric</li> <li>2-4 switches per group</li> <li>Support for MCLAG and ESLAG (EVPN MH / ESI)</li> <li>A single redundancy group can only support multi-homing of one type (ESLAG or MCLAG)</li> <li>Multiple types of redundancy groups can be used in the fabric simultaneously</li> </ul>"},{"location":"release-notes/#improved-vpc-security-policy-better-zero-trust","title":"Improved VPC security policy - better Zero Trust","text":"<ul> <li>Inter-VPC<ul> <li>Allow inter-VPC and external peering with per subnet control</li> </ul> </li> <li>Intra-VPC intra-subnet policies<ul> <li>Isolated Subnets<ul> <li>subnets isolated by default from other subnets in the VPC</li> <li>require a user-defined explicitly permit list to allow communications to other subnets within the VPC</li> <li>can be set on individual subnets within VPC or per entire VPC - off by default</li> <li>Inter-VPC and external peering configurations are not affected and work the same as before</li> </ul> </li> <li>Restricted Subnets<ul> <li>Hosts within a subnet have no mutual reachability</li> <li>Hosts within a subnet can be reached by members of other subnets or peered VPCs as specified by the policy</li> <li>Inter-VPC and external peering configurations are not affected and work the same as before</li> </ul> </li> <li>Permit Lists<ul> <li>Intra-VPC Permit Lists govern connectivity between subnets within the VPC for isolated subnets</li> <li>Inter-VPC Permit Lists govern which subnets of one VPC have access to some subnets of the other VPC for finer-grained control of inter-VPC and external peering</li> </ul> </li> </ul> </li> </ul>"},{"location":"release-notes/#static-external-connection","title":"Static External Connection","text":"<ul> <li>Allows access between hosts within the VPC and devices attached to a switch with user-defined static routes</li> </ul>"},{"location":"release-notes/#internal-improvements","title":"Internal Improvements","text":"<ul> <li>A new, more reliable automated ID allocation system</li> <li>Extra validation of object lifecycle (e.g., object-in-use removal validation)</li> </ul>"},{"location":"release-notes/#known-issues","title":"Known Issues","text":"<ul> <li>External Peering Failover<ul> <li>Conditions: ExternalPeering is specified for the VPC, and the same VPC has Border Leaf VPCPeering</li> <li>Issue: Detaching ExternalPeering may cause VPCPeering on the Border Leaf group to stop working</li> <li>Workaround: VPCPeering on the Border Leaf group should be recreated</li> </ul> </li> </ul>"},{"location":"release-notes/#alpha-3","title":"Alpha-3","text":""},{"location":"release-notes/#sonic-support","title":"SONiC support","text":"<ul> <li>Broadcom Enterprise SONiC 4.2.0 (previously 4.1.1)</li> </ul>"},{"location":"release-notes/#multiple-ipv4-namespaces","title":"Multiple IPv4 namespaces","text":"<ul> <li>Support for multiple overlapping IPv4 addresses in the Fabric</li> <li>Integrated with on-demand DHCP Service (see below)</li> <li>All IPv4 addresses within a given VPC must be unique</li> <li>Only VPCs with non-overlapping IPv4 subnets can peer within the Fabric</li> <li>An external NAT device is required for peering of VPCs with overlapping subnets</li> </ul>"},{"location":"release-notes/#hedgehog-fabric-dhcp-and-ipam-service","title":"Hedgehog Fabric DHCP and IPAM Service","text":"<ul> <li>Custom DHCP server executing in the controllers</li> <li>Multiple IPv4 namespaces with overlapping subnets</li> <li>Multiple VLAN namespaces with overlapping VLAN ranges</li> <li>DHCP leases exposed through the Fabric API</li> <li>Available for VLAB as well as the Fabric</li> </ul>"},{"location":"release-notes/#hedgehog-fabric-ntp-service","title":"Hedgehog Fabric NTP Service","text":"<ul> <li>Custom NTP servers at the controller</li> <li>Switches automatically configured to use control node as NTP server</li> <li>NTP servers can be configured to sync to external time/NTP server</li> </ul>"},{"location":"release-notes/#staticexternal-connections","title":"StaticExternal connections","text":"<ul> <li>Directly connect external infrastructure services (such as NTP, DHCP, DNS) to the Fabric</li> <li>No BGP is required, just automatically configured  static routes</li> </ul>"},{"location":"release-notes/#dhcp-relay-to-3rd-party-dhcp-service","title":"DHCP Relay to 3rd party DHCP service","text":"<p>Support for 3rd party DHCP server (DHCP Relay config) through the API</p>"},{"location":"release-notes/#alpha-2","title":"Alpha-2","text":""},{"location":"release-notes/#controller","title":"Controller","text":"<p>A single controller. No controller redundancy.</p>"},{"location":"release-notes/#controller-connectivity","title":"Controller connectivity","text":"<p>For CLOS/LEAF-SPINE fabrics, it is recommended that the controller connects to one or more leaf switches in the fabric on front-facing data ports. Connection to two or more leaf switches is recommended for redundancy and performance. No port break-out functionality is supported for controller connectivity.</p> <p>Spine controller connectivity is not supported.</p> <p>For Collapsed Core topology, the controller can connect on front-facing data ports, as described above, or on management ports. Note that every switch in the collapsed core topology must be connected to the controller.</p> <p>Management port connectivity can also be supported for CLOS/LEAF-SPINE topology but requires all switches connected to the controllers via management ports. No chain booting is possible for this configuration.</p>"},{"location":"release-notes/#controller-requirements","title":"Controller requirements","text":"<ul> <li>One  1 gig+ port per to connect to each controller attached switch</li> <li>One+ 1 gig+ ports connecting to the external management network.</li> <li>4 Cores, 12GB RAM, 100GB SSD.</li> </ul>"},{"location":"release-notes/#chain-booting","title":"Chain booting","text":"<p>Switches not directly connecting to the controllers can chain boot via the data network.</p>"},{"location":"release-notes/#topology-support","title":"Topology support","text":"<p>CLOS/LEAF-SPINE and Collapsed Core topologies are supported.</p>"},{"location":"release-notes/#leaf-roles-for-clos-topology","title":"LEAF Roles for CLOS topology","text":"<p>server leaf, border leaf, and mixed leaf modes are supported.</p>"},{"location":"release-notes/#collapsed-core-topology","title":"Collapsed Core Topology","text":"<p>Two ToR/LEAF switches with MCLAG server connection.</p>"},{"location":"release-notes/#server-multihoming","title":"Server multihoming","text":"<p>MCLAG-only.</p>"},{"location":"release-notes/#device-support_2","title":"Device support","text":""},{"location":"release-notes/#leafs","title":"LEAFs","text":"<ul> <li> <p>DELL:</p> <ul> <li>S5248F-ON</li> <li>S5232F-ON</li> </ul> </li> <li> <p>Edge-Core:</p> <ul> <li>DCS204 (AS7726-32X)</li> <li>DCS203 (AS7326-56X)</li> <li>EPS203 (AS4630-54NPE)</li> </ul> </li> </ul>"},{"location":"release-notes/#spines","title":"SPINEs","text":"<ul> <li>DELL:<ul> <li>S5232F-ON</li> </ul> </li> <li>Edge-Core:<ul> <li>DCS204 (AS7726-32X)</li> </ul> </li> </ul>"},{"location":"release-notes/#underlay-configuration","title":"Underlay configuration:","text":"<p>Port speed, port group speed, port breakouts are configurable through the API</p>"},{"location":"release-notes/#vpc-overlay-implementation","title":"VPC (overlay) Implementation","text":"<p>VXLAN-based BGP eVPN.</p>"},{"location":"release-notes/#multi-subnet-vpcs","title":"Multi-subnet VPCs","text":"<p>A VPC consists of subnets, each with a user-specified VLAN for external host/server connectivity.</p>"},{"location":"release-notes/#multiple-ip-address-namespaces","title":"Multiple IP address namespaces","text":"<p>Multiple IP address namespaces are supported per fabric. Each VPC belongs to the corresponding IPv4 namespace. There are no subnet overlaps within a single IPv4 namespace. IP address namespaces can mutually overlap.</p>"},{"location":"release-notes/#vlan-namespace","title":"VLAN Namespace","text":"<p>VLAN Namespaces guarantee the uniqueness of VLANs for a set of participating devices. Each switch belongs to a list of VLAN namespaces with non-overlapping VLAN ranges. Each VPC belongs to the VLAN namespace. There are no VLAN overlaps within a single VLAN namespace.</p> <p>This feature is useful when multiple VM-management domains (like separate VMware clusters connect to the fabric).</p>"},{"location":"release-notes/#switch-groups","title":"Switch Groups","text":"<p>Each switch belongs to a list of switch groups used for identifying redundancy groups for things like external connectivity.</p>"},{"location":"release-notes/#mutual-vpc-peering","title":"Mutual VPC Peering","text":"<p>VPC peering is supported and possible between a pair of VPCs that belong to the same IPv4 and VLAN namespaces.</p>"},{"location":"release-notes/#external-vpc-peering","title":"External VPC Peering","text":"<p>VPC peering provides the means of peering with external networking devices (edge routers, firewalls, or data center interconnects). VPC egress/ingress is pinned to a specific group of the border or mixed leaf switches. Multiple \u201cexternal systems\u201d with multiple devices/links in each of them are supported.</p> <p>The user controls what subnets/prefixes to import and export from/to the external system.</p> <p>No NAT function is supported for external peering.</p>"},{"location":"release-notes/#host-connectivity","title":"Host connectivity","text":"<p>Servers can be attached as Unbundled, Bundled (LAG) and MCLAG</p>"},{"location":"release-notes/#dhcp-service","title":"DHCP Service","text":"<p>VPC is provided with an optional DHCP service with simple IPAM</p>"},{"location":"release-notes/#local-vpc-peering-loopbacks","title":"Local VPC peering loopbacks","text":"<p>To enable local inter-vpc peering that allows routing of traffic between VPCs, local loopbacks are required to overcome silicon limitations.</p>"},{"location":"release-notes/#scale","title":"Scale","text":"<ul> <li>Maximum fabric size: 20 LEAF/ToR switches.</li> <li>Routes per switch: 64k</li> <li>[ silicon platform limitation in Trident 3; limits to number of endpoints in the fabric  ]</li> <li>Total VPCs per switch: up to 1000</li> <li>[ Including VPCs attached at the given switch and VPCs peered with ]</li> <li>Total VPCs per VLAN namespace: up to 3000</li> <li>[ assuming 1 subnet per VPC ]</li> <li>Total VPCs per fabric:  unlimited</li> <li>[ if using multiple VLAN namespaces ]</li> <li>VPC subnets per switch: up to 3000</li> <li>VPC subnets per VLAN namespace up to 3000</li> <li>Subnets per VPC: up to 20</li> <li>[ just a validation; the current design allows up to 100, but it could be increased even more in the future ]</li> <li>VPC Slots per remote peering @ switch: 2</li> <li>Max VPC loopbacks per switch: 500</li> <li>[ VPC loopback workarounds per switch are needed for local peering when both VPCs are attached to the switch or for external peering with VPC attached on the same switch that is peering with external ]</li> </ul>"},{"location":"release-notes/#software-versions","title":"Software versions","text":"<ul> <li>Fabric: v0.23.0</li> <li>Das-boot: v0.11.4</li> <li>Fabricator: v0.8.0</li> <li>K3s: v1.27.4-k3s1</li> <li>Zot: v1.4.3</li> <li>SONiC</li> <li>Broadcom Enterprise Base 4.1.1</li> <li>Broadcom Enterprise Campus 4.1.1</li> </ul>"},{"location":"release-notes/#known-limitations","title":"Known Limitations","text":"<ul> <li>MTU setting inflexibility:</li> <li>Fabric MTU is 9100 and not configurable right now (A3 planned)</li> <li>Server-facing MTU is 9136 and not configurable right now (A3+)</li> <li>no support for Access VLANs for attaching servers (A3 planned)</li> <li>VPC peering is enabled on all subnets of the participating VPCs. No subnet selection for peering. (A3 planned)</li> <li>peering with external is only possible with a VLAN (by design)</li> <li>If you have VPCs with remote peering on a switch group, you can't attach those VPCs on that switch group (by definition of remote peering)</li> <li>if a group of VPCs has remote peering on a switch group, any other VPC that will peer with those VPCs remotely will need to use the same switch group (by design)</li> <li>if VPC peers with external, it can only be remotely peered with on the same switches that have a connection to that external (by design)</li> <li>the server-facing connection object is immutable as it\u2019s very easy to get into a deadlock, re-create to change it (A3+)</li> </ul>"},{"location":"release-notes/#alpha-1","title":"Alpha-1","text":"<ul> <li> <p>Controller:</p> <ul> <li>A single controller connecting to each switch management port. No redundancy.</li> </ul> </li> <li> <p>Controller requirements:</p> <ul> <li>One 1 gig port per switch</li> <li>One+ 1 gig+ ports connecting to the external management network.</li> <li>4 Cores, 12GB RAM, 100GB SSD.</li> </ul> </li> <li> <p>Seeder:</p> <ul> <li>Seeder and Controller functions co-resident on the control node. Switch booting and ZTP on management ports directly connected to the controller.</li> </ul> </li> <li> <p>HHFab - the fabricator:</p> <ul> <li>An operational tool to generate, initiate, and maintain the fabric software appliance.  Allows fabrication of the environment-specific image with all of the required underlay and security configuration baked in.</li> </ul> </li> <li> <p>DHCP Service:</p> <ul> <li>A simple DHCP server for assigning IP addresses to hosts connecting to the fabric, optimized for use with VPC overlay.</li> </ul> </li> <li> <p>Topology:</p> <ul> <li>Support for a Collapsed Core topology with 2 switch nodes.</li> </ul> </li> <li> <p>Underlay:</p> <ul> <li>A simple single-VRF network with a BGP control plane.  IPv4 support only.</li> </ul> </li> <li> <p>External connectivity:</p> <ul> <li>An edge router must be connected to selected ports of one or both switches.  IPv4 support only.</li> </ul> </li> <li> <p>Dual-homing:</p> <ul> <li>L2 Dual homing with MCLAG is implemented to connect servers, storage, and other devices in the data center.  NIC bonding and LACP configuration at the host are required.</li> </ul> </li> <li> <p>VPC overlay implementation:</p> <ul> <li>VPC is implemented as a set of ACLs within the underlay VRF. External connectivity to the VRF is performed via internally managed VLANs.  IPv4 support only.</li> </ul> </li> <li> <p>VPC Peering:</p> <ul> <li>VPC peering is performed via ACLs with no fine-grained control.</li> </ul> </li> <li> <p>NAT</p> <ul> <li>DNAT + SNAT are supported per VPC. SNAT and DNAT can't be enabled per VPC simultaneously.</li> </ul> </li> <li> <p>Hardware support:</p> <ul> <li>Please see the supported hardware list.</li> </ul> </li> <li> <p>Virtual Lab:</p> <ul> <li>A simulation of the two-node Collapsed Core Topology as a virtual environment. Designed for use as a network simulation, a configuration scratchpad, or a training/demonstration tool.  Minimum requirements: 8 cores, 24GB RAM, 100GB SSD</li> </ul> </li> <li> <p>Limitations:</p> <ul> <li>40 VPCs max</li> <li>50 VPC peerings</li> <li>[ 768 ACL entry platform limitation from Broadcom ]</li> </ul> </li> <li> <p>Software versions:</p> <ul> <li>Fabricator: v0.5.2</li> <li>Fabric: v0.18.6</li> <li>Das-boot: v0.8.2</li> <li>K3s: v1.27.4-k3s1</li> <li>Zot: v1.4.3</li> <li>SONiC: Broadcom Enterprise Base 4.1.1</li> </ul> </li> </ul>"},{"location":"troubleshooting/overview/","title":"Troubleshooting","text":"<p>Under construction.</p>"},{"location":"user-guide/connections/","title":"Connections","text":"<p><code>Connection</code> objects represent logical and physical connections between the devices in the Fabric (<code>Switch</code>, <code>Server</code> and <code>External</code> objects) and are needed to define all the connections in the Wiring Diagram.</p> <p>All connections reference switch or server ports. Only port names defined by switch profiles can be used in the wiring diagram for the switches. NOS (or any other) port names aren't supported. Currently, server ports aren't validated by the Fabric API other than for uniqueness. See the Switch Profiles and Port Naming section for more details.</p> <p>There are several types of connections.</p>"},{"location":"user-guide/connections/#workload-server-connections","title":"Workload server connections","text":"<p>Server connections are used to connect workload servers to switches.</p>"},{"location":"user-guide/connections/#unbundled","title":"Unbundled","text":"<p>Unbundled server connections are used to connect servers to a single switch using a single port.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: server-4--unbundled--s5248-02\n  namespace: default\nspec:\n  unbundled:\n    link: # Defines a single link between a server and a switch\n      server:\n        port: server-4/enp2s1\n      switch:\n        port: s5248-02/Ethernet3\n</code></pre>"},{"location":"user-guide/connections/#bundled","title":"Bundled","text":"<p>Bundled server connections are used to connect servers to a single switch using multiple ports (port channel, LAG).</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: server-3--bundled--s5248-01\n  namespace: default\nspec:\n  bundled:\n    links: # Defines multiple links between a single server and a single switch\n    - server:\n        port: server-3/enp2s1\n      switch:\n        port: s5248-01/Ethernet3\n    - server:\n        port: server-3/enp2s2\n      switch:\n        port: s5248-01/Ethernet4\n</code></pre>"},{"location":"user-guide/connections/#mclag","title":"MCLAG","text":"<p>MCLAG server connections are used to connect servers to a pair of switches using multiple ports (Dual-homing). Switches should be configured as an MCLAG pair which requires them to be in a single redundancy group of type <code>mclag</code> and a Connection with type <code>mclag-domain</code> between them. MCLAG switches should also have the same <code>spec.ASN</code> and <code>spec.VTEPIP</code>.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: server-1--mclag--s5248-01--s5248-02\n  namespace: default\nspec:\n  mclag:\n    links: # Defines multiple links between a single server and a pair of switches\n    - server:\n        port: server-1/enp2s1\n      switch:\n        port: s5248-01/Ethernet1\n    - server:\n        port: server-1/enp2s2\n      switch:\n        port: s5248-02/Ethernet1\n</code></pre>"},{"location":"user-guide/connections/#eslag","title":"ESLAG","text":"<p>ESLAG server connections are used to connect servers to the 2-4 switches using multiple ports (Multi-homing). Switches should belong to the same redundancy group with type <code>eslag</code>, but contrary to the MCLAG case, no other configuration is required.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: server-1--eslag--s5248-01--s5248-02\n  namespace: default\nspec:\n  eslag:\n    links: # Defines multiple links between a single server and a 2-4 switches\n    - server:\n        port: server-1/enp2s1\n      switch:\n        port: s5248-01/Ethernet1\n    - server:\n        port: server-1/enp2s2\n      switch:\n        port: s5248-02/Ethernet1\n</code></pre>"},{"location":"user-guide/connections/#switch-connections-fabric-facing","title":"Switch connections (fabric-facing)","text":"<p>Switch connections are used to connect switches to each other and provide any needed \"service\" connectivity to implement the Fabric features.</p>"},{"location":"user-guide/connections/#fabric","title":"Fabric","text":"<p>A Fabric Connection is used between a specific pair of spine and leaf switches, representing all of the wires between them.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: s5232-01--fabric--s5248-01\n  namespace: default\nspec:\n  fabric:\n    links: # Defines multiple links between a spine-leaf pair of switches with IP addresses\n    - leaf:\n        ip: 172.30.30.1/31\n        port: s5248-01/Ethernet48\n      spine:\n        ip: 172.30.30.0/31\n        port: s5232-01/Ethernet0\n    - leaf:\n        ip: 172.30.30.3/31\n        port: s5248-01/Ethernet56\n      spine:\n        ip: 172.30.30.2/31\n        port: s5232-01/Ethernet4\n</code></pre>"},{"location":"user-guide/connections/#mclag-domain","title":"MCLAG-Domain","text":"<p>MCLAG-Domain connections define a pair of MCLAG switches with Session and Peer link between them. Switches should be configured as an MCLAG, pair which requires them to be in a single redundancy group of type <code>mclag</code> and Connection with type <code>mclag-domain</code> between them. MCLAG switches should also have the same <code>spec.ASN</code> and <code>spec.VTEPIP</code>.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: s5248-01--mclag-domain--s5248-02\n  namespace: default\nspec:\n  mclagDomain:\n    peerLinks: # Defines multiple links between a pair of MCLAG switches for Peer link\n    - switch1:\n        port: s5248-01/Ethernet72\n      switch2:\n        port: s5248-02/Ethernet72\n    - switch1:\n        port: s5248-01/Ethernet73\n      switch2:\n        port: s5248-02/Ethernet73\n    sessionLinks: # Defines multiple links between a pair of MCLAG switches for Session link\n    - switch1:\n        port: s5248-01/Ethernet74\n      switch2:\n        port: s5248-02/Ethernet74\n    - switch1:\n        port: s5248-01/Ethernet75\n      switch2:\n        port: s5248-02/Ethernet75\n</code></pre>"},{"location":"user-guide/connections/#vpc-loopback","title":"VPC-Loopback","text":"<p>VPC-Loopback connections are required in order to implement a workaround for the local VPC peering (when both VPC are attached to the same switch), which is caused by a hardware limitation of the currently supported switches.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: s5248-01--vpc-loopback\n  namespace: default\nspec:\n  vpcLoopback:\n    links: # Defines multiple loopbacks on a single switch\n    - switch1:\n        port: s5248-01/Ethernet16\n      switch2:\n        port: s5248-01/Ethernet17\n    - switch1:\n        port: s5248-01/Ethernet18\n      switch2:\n        port: s5248-01/Ethernet19\n</code></pre>"},{"location":"user-guide/connections/#connecting-fabric-to-the-outside-world","title":"Connecting Fabric to the outside world","text":"<p>Connections in this section provide connectivity to the outside world. For example, they can be connections to the Internet, to other networks, or to some other systems such as DHCP, NTP, LMA, or AAA services.</p>"},{"location":"user-guide/connections/#staticexternal","title":"StaticExternal","text":"<p><code>StaticExternal</code> connections provide a simple way to connect things like DHCP servers directly to the Fabric by connecting them to specific switch ports.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: third-party-dhcp-server--static-external--s5248-04\n  namespace: default\nspec:\n  staticExternal:\n    link:\n      switch:\n        port: s5248-04/Ethernet1 # Switch port to use\n        ip: 172.30.50.5/24 # IP address that will be assigned to the switch port\n        vlan: 1005 # Optional VLAN ID to use for the switch port; if 0, no VLAN is configured\n        subnets: # List of subnets to route to the switch port using static routes and next hop\n          - 10.99.0.1/24\n          - 10.199.0.100/32\n        nextHop: 172.30.50.1 # Next hop IP address to use when configuring static routes for the \"subnets\" list\n</code></pre> <p>Additionally, it's possible to configure <code>StaticExternal</code> within the VPC to provide access to the third-party resources within a specific VPC, with the rest of the YAML configuration remaining unchanged.</p> <pre><code>...\nspec:\n  staticExternal:\n    withinVPC: vpc-1 # VPC name to attach the static external to\n    link:\n      ...\n</code></pre>"},{"location":"user-guide/connections/#external","title":"External","text":"<p>Connection to external systems, such as edge/provider routers using BGP peering and configuring Inbound/Outbound communities as well as granularly controlling what gets advertised and which routes are accepted.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: s5248-03--external--5835\n  namespace: default\nspec:\n  external:\n    link: # Defines a single link between a switch and an external system\n      switch:\n        port: s5248-03/Ethernet3\n</code></pre>"},{"location":"user-guide/devices/","title":"Switches and Servers","text":"<p>All devices in a Hedgehog Fabric are divided into two groups: switches and servers, represented by the corresponding <code>Switch</code> and <code>Server</code> objects in the API. These objects are needed to define all of the participants of the Fabric and their roles in the Wiring Diagram, together with <code>Connection</code> objects (see Connections).</p>"},{"location":"user-guide/devices/#switches","title":"Switches","text":"<p>Switches are the main building blocks of the Fabric. They are represented by <code>Switch</code> objects in the API. These objects consist of basic metadata like name, description, role, serial, management port mac, as well as port group speeds, port breakouts, ASN, IP addresses, and more. Additionally, a <code>Switch</code> contains a reference to a <code>SwitchProfile</code> object that defines the switch model and capabilities. More details can be found in the Switch Profiles and Port Naming section.</p> <p>In order for the fabric to manage a switch the profile needs to include either the <code>serial</code> or <code>mac</code> need to be defined in the YAML doc.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Switch\nmetadata:\n  name: s5248-01\n  namespace: default\nspec:\n  boot: # at least one of the serial or mac needs to be defined\n    serial: XYZPDQ1234\n    mac: 00:11:22:33:44:55 # Usually the first management port MAC address\n  profile: dell-s5248f-on # Mandatory reference to the SwitchProfile object defining the switch model and capabilities\n  asn: 65101 # ASN of the switch\n  description: leaf-1\n  ip: 172.30.10.100/32 # Switch IP that will be accessible from the Control Node\n  portBreakouts: # Configures port breakouts for the switch, see the SwitchProfile for available options\n    E1/55: 4x25G\n  portGroupSpeeds: # Configures port group speeds for the switch, see the SwitchProfile for available options\n    \"1\": 10G\n    \"2\": 10G\n  portSpeeds: # Configures port speeds for the switch, see the SwitchProfile for available options\n    E1/1: 25G\n  protocolIP: 172.30.11.100/32 # Used as BGP router ID\n  role: server-leaf # Role of the switch, one of server-leaf, border-leaf and mixed-leaf\n  vlanNamespaces: # Defines which VLANs could be used to attach servers\n  - default\n  vtepIP: 172.30.12.100/32\n  groups: # Defines which groups the switch belongs to, by referring to SwitchGroup objects\n  - some-group\n  redundancy: # Optional field to define that switch belongs to the redundancy group\n    group: eslag-1 # Name of the redundancy group\n    type: eslag # Type of the redundancy group, one of mclag or eslag\n</code></pre> <p>The <code>SwitchGroup</code> is just a marker at that point and doesn't have any configuration options.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: SwitchGroup\nmetadata:\n  name: border\n  namespace: default\nspec: {}\n</code></pre>"},{"location":"user-guide/devices/#redundancy-groups","title":"Redundancy Groups","text":"<p>Redundancy groups are used to define the redundancy between switches. It's a regular <code>SwitchGroup</code> used by multiple switches and currently it could be MCLAG or ESLAG (EVPN MH / ESI). A switch can only belong to a single redundancy group.</p> <p>MCLAG is only supported for pairs of switches and ESLAG is supported for up to 4 switches. Multiple types of redundancy groups can be used in the fabric simultaneously.</p> <p>Connections with types <code>mclag</code> and <code>eslag</code> are used to define the servers connections to switches. They are only supported if the switch belongs to a redundancy group with the corresponding type.</p> <p>In order to define a MCLAG or ESLAG redundancy group, you need to create a <code>SwitchGroup</code> object and assign it to the switches using the <code>redundancy</code> field.</p> <p>Example of switch configured for ESLAG:</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: SwitchGroup\nmetadata:\n  name: eslag-1\n  namespace: default\nspec: {}\n---\napiVersion: wiring.githedgehog.com/v1beta1\nkind: Switch\nmetadata:\n  name: s5248-03\n  namespace: default\nspec:\n  ...\n  redundancy:\n    group: eslag-1\n    type: eslag\n  ...\n</code></pre> <p>And example of switch configured for MCLAG:</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: SwitchGroup\nmetadata:\n  name: mclag-1\n  namespace: default\nspec: {}\n---\napiVersion: wiring.githedgehog.com/v1beta1\nkind: Switch\nmetadata:\n  name: s5248-01\n  namespace: default\nspec:\n  ...\n  redundancy:\n    group: mclag-1\n    type: mclag\n  ...\n</code></pre> <p>In case of MCLAG it's required to have a special connection with type <code>mclag-domain</code> that defines the peer and session links between switches. For more details, see Connections.</p>"},{"location":"user-guide/devices/#servers","title":"Servers","text":"<p>Regular workload server:</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Server\nmetadata:\n  name: server-1\n  namespace: default\nspec:\n  description: MH s5248-01/E1 s5248-02/E1\n</code></pre>"},{"location":"user-guide/external/","title":"External Peering","text":"<p>Hedgehog Fabric uses the Border Leaf concept to exchange VPC routes outside the Fabric and provide L3 connectivity. The <code>External Peering</code> feature allows you to set up an external peering endpoint and to enforce several policies between internal and external endpoints.</p> <p>Note</p> <p>Hedgehog Fabric does not operate Edge side devices.</p>"},{"location":"user-guide/external/#overview","title":"Overview","text":"<p>Traffic exits from the Fabric on Border Leaves that are connected with Edge devices. Border Leaves are suitable to terminate L2VPN connections, to distinguish VPC L3 routable traffic towards Edge devices, and to land VPC servers. Border Leaves (or Borders) can connect to several Edge devices.</p> <p>Note</p> <p>External Peering is only available on the switch devices that are capable for sub-interfaces.</p>"},{"location":"user-guide/external/#connect-border-leaf-to-edge-device","title":"Connect Border Leaf to Edge device","text":"<p>In order to distinguish VPC 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>"},{"location":"user-guide/external/#control-plane","title":"Control Plane","text":"<p>The Fabric shares VPC routes with Edge devices via BGP. Peering is done over VLAN in IPv4 Unicast AFI/SAFI.</p>"},{"location":"user-guide/external/#data-plane","title":"Data Plane","text":"<p>VPC L3 routable traffic will be tagged with VLAN and sent to Edge device. Later processing of VPC traffic (NAT, PBR, etc) should happen on Edge devices.</p>"},{"location":"user-guide/external/#vpc-access-to-edge-device","title":"VPC access to Edge device","text":"<p>Each VPC within the Fabric can be allowed to access Edge devices. Additional filtering can be applied to the routes that the VPC can export to Edge devices and import from the Edge devices.</p>"},{"location":"user-guide/external/#api-and-implementation","title":"API and implementation","text":""},{"location":"user-guide/external/#external","title":"External","text":"<p>General configuration starts with the specification of <code>External</code> objects. Each object of <code>External</code> type can represent a set of Edge devices, or a single BGP instance on Edge device, or any other united Edge entities that can be described with the following configuration:</p> <ul> <li>Name of <code>External</code></li> <li>Inbound routes marked with the dedicated BGP community</li> <li>Outbound routes marked with the dedicated community</li> </ul> <p>Each <code>External</code> should be bound to some VPC IP Namespace, otherwise prefixes overlap may happen.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: External\nmetadata:\n  name: default--5835\nspec:\n  ipv4Namespace: # VPC IP Namespace\n  inboundCommunity: # BGP Standard Community of routes from Edge devices\n  outboundCommunity: # BGP Standard Community required to be assigned on prefixes advertised from Fabric\n</code></pre>"},{"location":"user-guide/external/#connection","title":"Connection","text":"<p>A <code>Connection</code> of type <code>external</code> is used to identify the switch port on Border leaf that is cabled with an Edge device.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: # specified or generated\nspec:\n  external:\n    link:\n      switch:\n        port: # SwitchName/EthernetXXX\n</code></pre>"},{"location":"user-guide/external/#external-attachment","title":"External Attachment","text":"<p><code>External Attachment</code> defines BGP Peering and traffic connectivity between a Border leaf and <code>External</code>. Attachments are bound to a <code>Connection</code> with type <code>external</code> and they specify an optional <code>vlan</code> that will be used to segregate particular Edge peering.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: ExternalAttachment\nmetadata:\n  name: #\nspec:\n  connection: # Name of the Connection with type external\n  external: # Name of the External to pick config\n  neighbor:\n    asn: # Edge device ASN\n    ip: # IP address of Edge device to peer with\n  switch:\n    ip: # IP address on the Border Leaf to set up BGP peering\n    vlan: # VLAN (optional) ID to tag control and data traffic, use 0 for untagged\n</code></pre> <p>Several <code>External Attachment</code> can be configured for the same <code>Connection</code> but for different <code>vlan</code>.</p>"},{"location":"user-guide/external/#external-vpc-peering","title":"External VPC Peering","text":"<p>To allow a specific VPC to have access to Edge devices, bind the VPC to a specific <code>External</code> object. To do so, define an <code>External Peering</code> object.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: ExternalPeering\nmetadata:\n  name: # Name of ExternalPeering\nspec:\n  permit:\n    external:\n      name: # External Name\n      prefixes: # List of prefixes (routes) to be allowed to pick up from External\n      - # IPv4 prefix\n    vpc:\n      name: # VPC Name\n      subnets: # List of VPC subnets name to be allowed to have access to External (Edge)\n      - # Name of the subnet within VPC\n</code></pre> <p><code>Prefixes</code> is the list of subnets to permit from the External to the VPC. It matches any prefix length less than or equal to 32, effectively permitting all prefixes within the specified one. Use <code>0.0.0.0/0</code> for any route, including the default route.</p> <p>This example allows any IPv4 prefix that came from <code>External</code>:</p> <pre><code>spec:\n  permit:\n    external:\n      name: ###\n      prefixes:\n      - prefix: 0.0.0.0/0 # Any route will be allowed including default route\n</code></pre> <p>This example allows all prefixes that match the default route, with any prefix length:</p> <pre><code>spec:\n  permit:\n    external:\n      name: ###\n      prefixes:\n      - prefix: 77.0.0.0/8 # Any route that belongs to the specified prefix is allowed (such as 77.0.0.0/8 or 77.1.2.0/24)\n</code></pre>"},{"location":"user-guide/external/#examples","title":"Examples","text":"<p>This example shows how to peer with the <code>External</code> object with name <code>HedgeEdge</code>, given a Fabric VPC with name <code>vpc-1</code> on the Border Leaf <code>switchBorder</code> that has a cable connecting it to an Edge device on the port <code>Ethernet42</code>. Specifying <code>vpc-1</code> is required to receive any prefixes advertised from the <code>External</code>.</p>"},{"location":"user-guide/external/#fabric-api-configuration","title":"Fabric API configuration","text":""},{"location":"user-guide/external/#external_1","title":"External","text":"<pre><code># kubectl fabric external create --name hedgeedge --ipns default --in 65102:5000 --out 5000:65102\n</code></pre> <pre><code>- apiVersion: vpc.githedgehog.com/v1beta1\n  kind: External\n  metadata:\n    creationTimestamp: \"2024-11-26T21:24:32Z\"\n    generation: 1\n    labels:\n      fabric.githedgehog.com/ipv4ns: default\n    name: hedgeedge\n    namespace: default\n    resourceVersion: \"57628\"\n    uid: a0662988-73d0-45b3-afc0-0d009cd91ebd\n  spec:\n    inboundCommunity: 65102:5000\n    ipv4Namespace: default\n    outboundCommunity: 5000:6510\n</code></pre>"},{"location":"user-guide/external/#connection_1","title":"Connection","text":"<p>Connection should be specified in the <code>wiring</code> diagram.</p> <pre><code>###\n### switchBorder--external--HedgeEdge\n###\napiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: switchBorder--external--HedgeEdge\nspec:\n  external:\n    link:\n      switch:\n        port: switchBorder/Ethernet42\n</code></pre>"},{"location":"user-guide/external/#externalattachment","title":"ExternalAttachment","text":"<p>Specified in <code>wiring</code> diagram</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: ExternalAttachment\nmetadata:\n  name: switchBorder--HedgeEdge\nspec:\n  connection: switchBorder--external--HedgeEdge\n  external: HedgeEdge\n  neighbor:\n    asn: 65102\n    ip: 100.100.0.6\n  switch:\n    ip: 100.100.0.1/24\n    vlan: 100\n</code></pre>"},{"location":"user-guide/external/#externalpeering","title":"ExternalPeering","text":"<pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: ExternalPeering\nmetadata:\n  name: vpc-1--HedgeEdge\nspec:\n  permit:\n    external:\n      name: HedgeEdge\n      prefixes:\n      - prefix: 0.0.0.0/0\n    vpc:\n      name: vpc-1\n      subnets:\n      - default\n</code></pre>"},{"location":"user-guide/external/#example-edge-side-bgp-configuration-based-on-sonic-os","title":"Example Edge side BGP configuration based on SONiC OS","text":"<p>Warning</p> <p>Hedgehog does not recommend using the following configuration for production. It is only provided as an example of Edge Peer configuration.</p> <p>Interface configuration:</p> <pre><code>interface Ethernet2.100\n encapsulation dot1q vlan-id 100\n description switchBorder--Ethernet42\n no shutdown\n ip vrf forwarding VrfHedge\n ip address 100.100.0.6/24\n</code></pre> <p>BGP configuration:</p> <pre><code>!\nrouter bgp 65102 vrf VrfHedge\n log-neighbor-changes\n timers 60 180\n !\n address-family ipv4 unicast\n  maximum-paths 64\n  maximum-paths ibgp 1\n  import vrf VrfPublic\n !\n neighbor 100.100.0.1\n  remote-as 65103\n  !\n  address-family ipv4 unicast\n   activate\n   route-map HedgeIn in\n   route-map HedgeOut out\n   send-community both\n !\n</code></pre> <p>Route Map configuration:</p> <pre><code>route-map HedgeIn permit 10\n match community Hedgehog\n!\nroute-map HedgeOut permit 10\n set community 65102:5000\n!\n\nbgp community-list standard HedgeIn permit 5000:65102\n</code></pre>"},{"location":"user-guide/grafana/","title":"Grafana Dashboards","text":"<p>To provide monitoring for most critical metrics from the switches managed by Hedgehog Fabric there are several Dashboards that may be used in Grafana deployments. Make sure that you've enabled metrics and logs collection for the switches in the Fabric that is described in Fabric Config section.</p>"},{"location":"user-guide/grafana/#variables","title":"Variables","text":"<p>List of common variables used in Hedgehog Grafana dashboards</p> <ul> <li>env (Label: Env): <code>label_values(env)</code> - Environment to monitor</li> <li>node (Label: Switch): <code>label_values(hostname)</code> - Switch Name</li> <li>vrf (Label: VRF): <code>label_values(vrf)</code> - VRF name (Multi-value)</li> <li>neighbor (Label: Neighbor): <code>label_values(neighbor)</code> - BGP Neighbor IP address(Multi-value)</li> <li>interface (Label: Interface): <code>label_values(interface)</code> - Switch Interface name as defined in wiring (Multi-value)</li> <li>file (Label: File): <code>label_valuse(filename)</code> - Name of Logs file to inspect (Loki)</li> </ul>"},{"location":"user-guide/grafana/#switch-critical-resources","title":"Switch Critical Resources","text":"<p>This table reports usage and capacity of ASIC's programmable resources  such as:</p> <ul> <li>ACLs</li> <li>IPv4 Routes</li> <li>IPv4 Nexthops</li> <li>IPv4 Neihbours</li> <li>IPMC Table</li> <li>FDB</li> </ul> <p>JSON</p>"},{"location":"user-guide/grafana/#fabric","title":"Fabric","text":"<p>Fabric underlay and external peering monitoring. Including reporing for:</p> <ul> <li>BGP Neighbors</li> <li>BGP Session state</li> <li>Number of BGP Updates and Prefixes sent/received for each BGP Neighbor</li> <li>Keepalive counters</li> </ul> <p>JSON</p>"},{"location":"user-guide/grafana/#interfaces","title":"Interfaces","text":"<p>Switch interfaces monitoring visualization that includes:</p> <ul> <li>Interface Oper/Admin state</li> <li>Total input/output packets counter</li> <li>Input/output PPS/Bits rate</li> <li>Interface utilization</li> <li>Counters for Unicast/Broadcast/Multicast packets</li> <li>Errors and discards counters</li> </ul> <p>JSON</p>"},{"location":"user-guide/grafana/#logs","title":"Logs","text":"<p>System and fabric logs:</p> <ul> <li>Kernel and BGP logs from Syslog</li> <li>Errors in agent and syslog</li> <li>Full output of defined file</li> </ul> <p>JSON</p>"},{"location":"user-guide/grafana/#platform","title":"Platform","text":"<p>Information from PSU, temperature sensors and fan trays:</p> <ul> <li>Input/output PSU voltage</li> <li>Fan speed</li> <li>Temperature from switch sensors (CPU, PSU, etc)</li> <li>For transceivers with DOM - optic sensor temperature</li> </ul> <p>JSON</p>"},{"location":"user-guide/grafana/#node-exporter","title":"Node Exporter","text":"<p>Grafana Node Exporter Full is an opensource Grafana board that provide visualizations for monitoring Linux nodes. In particular case Node Exporter is used to track SONiC OS own stats such as</p> <ul> <li>Memory/disks usage</li> <li>CPU/System utilization</li> <li>Networking stats (traffic that hits SONiC interfaces) ...</li> </ul> <p>JSON</p>"},{"location":"user-guide/harvester/","title":"Using VPCs with Harvester","text":"<p>This section contains an example of how Hedgehog Fabric can be used with Harvester or any hypervisor on the servers connected to Fabric. It assumes that you have already installed Fabric and have some servers running Harvester attached to it.</p> <p>You need to define a <code>Server</code> object for each server running Harvester and a <code>Connection</code> object for each server connection to the switches.</p> <p>You can have multiple VPCs created and attached to the <code>Connections</code> to the servers to make them available to the VMs in Harvester or any other hypervisor.</p>"},{"location":"user-guide/harvester/#configure-harvester","title":"Configure Harvester","text":""},{"location":"user-guide/harvester/#add-a-cluster-network","title":"Add a Cluster Network","text":"<p>From the \"Cluster Networks/Configs\" side menu, create a new Cluster Network.</p> <p></p> <p>Here is a cleaned-up version of what the CRD looks like:</p> <pre><code>apiVersion: network.harvesterhci.io/v1beta1\nkind: ClusterNetwork\nmetadata:\n  name: testnet\n</code></pre>"},{"location":"user-guide/harvester/#add-a-network-config","title":"Add a Network Config","text":"<p>Click \"Create Network Config\". Add your connections and select the bonding type.</p> <p></p> <p>The resulting CRD (cleaned up) looks like the following:</p> <pre><code>apiVersion: network.harvesterhci.io/v1beta1\nkind: VlanConfig\nmetadata:\n  name: testconfig\n  labels:\n    network.harvesterhci.io/clusternetwork: testnet\nspec:\n  clusterNetwork: testnet\n  uplink:\n    bondOptions:\n      miimon: 100\n      mode: 802.3ad\n    linkAttributes:\n      txQLen: -1\n    nics:\n      - enp5s0f0\n      - enp3s0f1\n</code></pre>"},{"location":"user-guide/harvester/#add-vlan-based-vm-networks","title":"Add VLAN based VM Networks","text":"<p>Browse over to \"VM Networks\" and add one network for each VLAN you want to support. Assign them to the cluster network.</p> <p> </p> <p>Here is what the CRDs will look like for both VLANs:</p> <pre><code>apiVersion: k8s.cni.cncf.io/v1\nkind: NetworkAttachmentDefinition\nmetadata:\n  labels:\n    network.harvesterhci.io/clusternetwork: testnet\n    network.harvesterhci.io/ready: 'true'\n    network.harvesterhci.io/type: L2VlanNetwork\n    network.harvesterhci.io/vlan-id: '1001'\n  name: testnet1001\n  namespace: default\nspec:\n  config: &gt;-\n    {\"cniVersion\":\"0.3.1\",\"name\":\"testnet1001\",\"type\":\"bridge\",\"bridge\":\"testnet-br\",\"promiscMode\":true,\"vlan\":1001,\"ipam\":{}}\n</code></pre> <pre><code>apiVersion: k8s.cni.cncf.io/v1\nkind: NetworkAttachmentDefinition\nmetadata:\n  name: testnet1000\n  labels:\n    network.harvesterhci.io/clusternetwork: testnet\n    network.harvesterhci.io/ready: 'true'\n    network.harvesterhci.io/type: L2VlanNetwork\n    network.harvesterhci.io/vlan-id: '1000'\n    #  key: string\n  namespace: default\nspec:\n  config: &gt;-\n    {\"cniVersion\":\"0.3.1\",\"name\":\"testnet1000\",\"type\":\"bridge\",\"bridge\":\"testnet-br\",\"promiscMode\":true,\"vlan\":1000,\"ipam\":{}}\n</code></pre>"},{"location":"user-guide/harvester/#using-the-vpcs","title":"Using the VPCs","text":"<p>Now you can choose the new VM Networks when creating a VM in Harvester, and have them created as part of the VPC.</p>"},{"location":"user-guide/overview/","title":"Overview","text":"<p>This chapter gives an overview of the main features of Hedgehog Fabric and their usage.</p>"},{"location":"user-guide/profiles/","title":"Switch Profiles and Port Naming","text":""},{"location":"user-guide/profiles/#switch-profiles","title":"Switch Profiles","text":"<p>All supported switches have a <code>SwitchProfile</code> that defines the switch model, supported features, and available ports with supported configurations such as port group and speeds as well as port breakouts. <code>SwitchProfiles</code> available in-cluster or generated documentation can be found in the Reference section.</p> <p>Each switch used in the wiring diagram should have a <code>SwitchProfile</code> references in the <code>spec.profile</code> of the <code>Switch</code> object.</p> <p>Switch profile defines what features and ports are available on the switch. Based on the ports data in the profile, it's possible to set port speeds (for non-breakout and non-group ports), port group speeds and port breakout modes in the <code>Switch</code> object in the Fabric API.</p>"},{"location":"user-guide/profiles/#port-naming","title":"Port Naming","text":"<p>Each switch port is named using one of the the following formats:</p> <ul> <li> <p><code>M&lt;management-port-number&gt;</code></p> <ul> <li><code>&lt;management-port-number&gt;</code> is the management port number starting from <code>1</code> (usually only one named <code>1</code> for most   switches)</li> </ul> </li> <li> <p><code>E&lt;asic-or-chassis-number&gt;/&lt;port-number&gt;[/&lt;breakout&gt;][.&lt;subinterface.]</code></p> <ul> <li><code>&lt;asic-or-chassis-number&gt;</code> is the ASIC or chassis number (usually only one named <code>1</code> for the most switches)</li> <li><code>&lt;port-number&gt;</code> is the port number on the ASIC or chassis, starting from <code>1</code></li> <li>optional <code>/&lt;breakout&gt;</code> is the breakout number for the port, starting from <code>1</code>, only for breakout ports and always consecutive numbers independent of the lanes allocation and other implementation details</li> <li>optional <code>.&lt;subinterface&gt;</code> is the subinterface number for the port</li> </ul> </li> </ul> <p>Examples of port names:</p> <ul> <li><code>M1</code> - management port</li> <li><code>E1/1</code> - port <code>1</code> on the ASIC or chassis <code>1</code>, usually a first port on the switch</li> <li><code>E1/55/1</code> - first breakout port of the switch port <code>55</code> on the ASIC or chassis <code>1</code></li> </ul>"},{"location":"user-guide/profiles/#available-ports","title":"Available Ports","text":"<p>Each switch profile defines a set of ports available on the switch. Ports could be divided into the following types.</p>"},{"location":"user-guide/profiles/#directly-configurable-ports","title":"Directly configurable ports","text":"<p>Non-breakout and non-group ports. Would have a reference to the port profile with default and available speeds. Could be configured by setting the speed in the <code>Switch</code> object in the Fabric API:</p> <pre><code>.spec:\n  portSpeeds:\n    E1/1: 25G\n</code></pre>"},{"location":"user-guide/profiles/#port-groups","title":"Port groups","text":"<p>Ports that belong to a port group, non-breakout and not directly configurable. Would have a reference to the port group which will have a reference to the port profile with default and available speeds. Port couldn't be configured directly, speed configuration is applied to the whole group in the <code>Switch</code> object in the Fabric API:</p> <pre><code>.spec:\n  portGroupSpeeds:\n    \"1\": 10G\n</code></pre> <p>It'll set the speed of all ports in the group <code>1</code> to <code>10G</code>, e.g. if the group <code>1</code> contains ports <code>E1/1</code>, <code>E1/2</code>, <code>E1/3</code> and <code>E1/4</code>, all of them will be set to <code>10G</code> speed.</p>"},{"location":"user-guide/profiles/#breakout-ports","title":"Breakout ports","text":"<p>Ports that are breakouts and non-group ports. Would have a reference to the port profile with default and available breakout modes. Could be configured by setting the breakout mode in the <code>Switch</code> object in the Fabric API:</p> <pre><code>.spec:\n  portBreakouts:\n    E1/55: 4x25G\n</code></pre> <p>Configuring a port breakout mode will make \"breakout\" ports available for use in the wiring diagram. The breakout ports are named as <code>E&lt;asic-or-chassis-number&gt;/&lt;port-number&gt;/&lt;breakout&gt;</code>, e.g. <code>E1/55/1</code>, <code>E1/55/2</code>, <code>E1/55/3</code>, <code>E1/55/4</code> for the example above. Omitting the breakout number is allowed for the first breakout port, e.g. <code>E1/55</code> is the same as <code>E1/55/1</code>. The breakout ports are always consecutive numbers independent of the lanes allocation and other implementation details.</p>"},{"location":"user-guide/shrink-expand/","title":"Fabric Shrink/Expand","text":"<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 cabled and connected.</p> <p>This article uses terms that can be found in the Hedgehog Concepts, the User Guide documentation, and the Fabric API reference.</p>"},{"location":"user-guide/shrink-expand/#add-a-switch-to-the-existing-fabric","title":"Add a switch to the existing fabric","text":"<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 User Guide.</p> <p>Note</p> <p>If the<code>Switch</code> will be used in <code>ESLAG</code> or <code>MCLAG</code> groups, appropriate groups should exist. Redundancy groups should be specified in the <code>Switch</code> object before creation.</p> <p>After the <code>Switch</code> object has been created, you can define and create dedicated device <code>Connections</code>. The types of the connections may differ based on the <code>Switch</code> role given to the device. For more details, refer to Connections section.</p> <p>Note</p> <p>Switch devices should be booted in <code>ONIE</code> installation mode to install SONiC OS and configure the Fabric Agent.</p> <p>Ensure the management port of the switch is connected to fabric management network.</p>"},{"location":"user-guide/shrink-expand/#remove-a-switch-from-the-existing-fabric","title":"Remove a switch from the existing fabric","text":"<p>Before you decommission a switch from the Hedgehog Fabric, several preparation steps are necessary.</p> <p>Warning</p> <p>Currently the <code>Wiring</code> diagram used for initial deployment is saved in <code>/var/lib/rancher/k3s/server/manifests/hh-wiring.yaml</code> on the <code>Control</code> node. Fabric will sustain objects within the original wiring diagram. In order to remove any object, first remove the dedicated API objects from this file. It is recommended to reapply <code>hh-wiring.yaml</code> after changing its internals.</p> <ul> <li>If the <code>Switch</code> is a <code>Leaf</code> switch (including <code>Mixed</code> and <code>Border</code> leaf configurations), remove all <code>VPCAttachments</code> bound to all switches <code>Connections</code>.</li> <li>If the <code>Switch</code> was used for <code>ExternalPeering</code>, remove all <code>ExternalAttachment</code> objects that are bound to the <code>Connections</code> of the <code>Switch</code>.</li> <li>Remove all connections of the <code>Switch</code>.</li> <li>At last, remove the <code>Switch</code> and <code>Agent</code> objects.</li> </ul>"},{"location":"user-guide/vpcs/","title":"VPCs and Namespaces","text":""},{"location":"user-guide/vpcs/#vpc","title":"VPC","text":"<p>A Virtual Private Cloud (VPC) is similar to a public cloud VPC. It provides an isolated private network with support for multiple subnets, each with user-defined VLANs and optional DHCP services.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: VPC\nmetadata:\n  name: vpc-1\n  namespace: default\nspec:\n  ipv4Namespace: default # Limits which subnets can the VPC use to guarantee non-overlapping IPv4 ranges\n  vlanNamespace: default # Limits which Vlan Ids can the VPC use to guarantee non-overlapping VLANs\n\n  defaultIsolated: true # Sets default behavior for the current VPC subnets to be isolated\n  defaultRestricted: true # Sets default behavior for the current VPC subnets to be restricted\n\n  subnets:\n    default: # Each subnet is named, \"default\" subnet isn't required, but actively used by CLI\n      dhcp:\n        enable: true # On-demand DHCP server\n        range: # Optionally, start/end range could be specified, otherwise all available IPs are used\n          start: 10.10.1.10\n          end: 10.10.1.99\n        options: # Optional, additional DHCP options to enable for DHCP server, only available when enable is true\n          pxeURL: tftp://10.10.10.99/bootfilename # PXEURL (optional) to identify the PXE server to use to boot hosts; HTTP query strings are not supported\n          dnsServers: # (optional) configure DNS servers\n            - 1.1.1.1\n          timeServers: # (optional) configure Time (NTP) Servers\n            - 1.1.1.1\n          interfaceMTU: 1500 # (optional) configure the MTU (default is 9036); doesn't affect the actual MTU of the switch interfaces\n      subnet: 10.10.1.0/24 # User-defined subnet from ipv4 namespace\n      gateway: 10.10.1.1 # User-defined gateway (optional, default is .1)\n      vlan: 1001 # User-defined VLAN from VLAN namespace\n      isolated: true # Makes subnet isolated from other subnets within the VPC (doesn't affect VPC peering)\n      restricted: true # Causes all hosts in the subnet to be isolated from each other\n\n    thrird-party-dhcp: # Another subnet\n      dhcp:\n        relay: 10.99.0.100/24 # Use third-party DHCP server (DHCP relay configuration), access to it could be enabled using StaticExternal connection\n      subnet: \"10.10.2.0/24\"\n      vlan: 1002\n\n    another-subnet: # Minimal configuration is just a name, subnet and VLAN\n      subnet: 10.10.100.0/24\n      vlan: 1100\n\n  permit: # Defines which subnets of the current VPC can communicate to each other, applied on top of subnets \"isolated\" flag (doesn't affect VPC peering)\n    - [subnet-1, subnet-2, subnet-3] # 1, 2 and 3 subnets can communicate to each other\n    - [subnet-4, subnet-5] # Possible to define multiple lists\n\n  staticRoutes: # Optional, static routes to be added to the VPC\n    - prefix: 10.100.0.0/24 # Destination prefix\n      nextHops: # Next hop IP addresses\n        - 10.200.0.0\n</code></pre>"},{"location":"user-guide/vpcs/#isolated-and-restricted-subnets-permit-lists","title":"Isolated and restricted subnets, permit lists","text":"<p>Subnets can be isolated and restricted, with the ability to define permit lists to allow communication between specific isolated subnets. The permit list is applied on top of the isolated flag and doesn't affect VPC peering.</p> <p>Isolated subnet means that the subnet has no connectivity with other subnets within the VPC, but it could still be allowed by permit lists.</p> <p>Restricted subnet means that all hosts in the subnet are isolated from each other within the subnet.</p> <p>A Permit list contains a list. Every element of the list is a set of subnets that can communicate with each other.</p>"},{"location":"user-guide/vpcs/#third-party-dhcp-server-configuration","title":"Third-party DHCP server configuration","text":"<p>In case you use a third-party DHCP server, by configuring <code>spec.subnets.&lt;subnet&gt;.dhcp.relay</code>, additional information is added to the DHCP packet forwarded to the DHCP server to make it possible to identify the VPC and subnet. This information is added under the RelayAgentInfo (option 82) in the DHCP packet. The relay sets two suboptions in the packet:</p> <ul> <li>VirtualSubnetSelection (suboption 151) is populated with the VRF which uniquely identifies a VPC on the Hedgehog   Fabric and will be in <code>VrfV&lt;VPC-name&gt;</code> format, for example <code>VrfVvpc-1</code> for a VPC named <code>vpc-1</code> in the Fabric API.</li> <li>CircuitID (suboption 1) identifies the VLAN which, together with the VRF (VPC) name, maps to a specific VPC subnet.</li> </ul>"},{"location":"user-guide/vpcs/#vpcattachment","title":"VPCAttachment","text":"<p>A VPCAttachment represents a specific VPC subnet assignment to the <code>Connection</code> object which means a binding between an exact server port and a VPC. It basically leads to the VPC being available on the specific server port(s) on a subnet VLAN.</p> <p>VPC could be attached to a switch that is part of the VLAN namespace used by the VPC.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: VPCAttachment\nmetadata:\n  name: vpc-1-server-1--mclag--s5248-01--s5248-02\n  namespace: default\nspec:\n  connection: server-1--mclag--s5248-01--s5248-02 # Connection name representing the server port(s)\n  subnet: vpc-1/default # VPC subnet name\n  nativeVLAN: true # (Optional) if true, the port will be configured as a native VLAN port (untagged)\n</code></pre>"},{"location":"user-guide/vpcs/#vpcpeering","title":"VPCPeering","text":"<p>A VPCPeering enables VPC-to-VPC connectivity. There are two types of VPC peering:</p> <ul> <li>Local: peering is implemented on the same switches where VPCs are attached</li> <li>Remote: peering is implemented on the border/mixed leaves defined by the <code>SwitchGroup</code> object</li> </ul> <p>VPC peering is only possible between VPCs attached to the same IPv4 namespace (see IPv4Namespace)</p>"},{"location":"user-guide/vpcs/#local-vpc-peering","title":"Local VPC peering","text":"<pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: VPCPeering\nmetadata:\n  name: vpc-1--vpc-2\n  namespace: default\nspec:\n  permit: # Defines a pair of VPCs to peer\n  - vpc-1: {} # Meaning all subnets of two VPCs will be able to communicate with each other\n    vpc-2: {} # See \"Subnet filtering\" for more advanced configuration\n</code></pre>"},{"location":"user-guide/vpcs/#remote-vpc-peering","title":"Remote VPC peering","text":"<pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: VPCPeering\nmetadata:\n  name: vpc-1--vpc-2\n  namespace: default\nspec:\n  permit:\n  - vpc-1: {}\n    vpc-2: {}\n  remote: border # Indicates a switch group to implement the peering on\n</code></pre>"},{"location":"user-guide/vpcs/#subnet-filtering","title":"Subnet filtering","text":"<p>It's possible to specify which specific subnets of the peering VPCs could communicate to each other using the <code>permit</code> field.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: VPCPeering\nmetadata:\n  name: vpc-1--vpc-2\n  namespace: default\nspec:\n  permit: # subnet-1 and subnet-2 of vpc-1 could communicate to subnet-3 of vpc-2 as well as subnet-4 of vpc-2 could communicate to subnet-5 and subnet-6 of vpc-2\n  - vpc-1:\n      subnets: [subnet-1, subnet-2]\n    vpc-2:\n      subnets: [subnet-3]\n  - vpc-1:\n      subnets: [subnet-4]\n    vpc-2:\n      subnets: [subnet-5, subnet-6]\n</code></pre>"},{"location":"user-guide/vpcs/#ipv4namespace","title":"IPv4Namespace","text":"<p>An <code>IPv4Namespace</code> defines a set of (non-overlapping) IPv4 address ranges available for use by VPC subnets. Each VPC belongs to a specific IPv4 namespace. Therefore, its subnet prefixes must be from that IPv4 namespace.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: IPv4Namespace\nmetadata:\n  name: default\n  namespace: default\nspec:\n  subnets: # List of prefixes that VPCs can pick their subnets from\n  - 10.10.0.0/16\n</code></pre>"},{"location":"user-guide/vpcs/#vlannamespace","title":"VLANNamespace","text":"<p>A <code>VLANNamespace</code> defines a set of VLAN ranges available for attaching servers to switches. Each switch can belong to one or more disjoint VLANNamespaces.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: VLANNamespace\nmetadata:\n  name: default\n  namespace: default\nspec:\n  ranges: # List of VLAN ranges that VPCs can pick their subnet VLANs from\n  - from: 1000\n    to: 2999\n</code></pre>"},{"location":"vlab/demo/","title":"Demo on VLAB","text":""},{"location":"vlab/demo/#goals","title":"Goals","text":"<p>The goal of this demo is to show how to use VPCs, attach and peer them and run test connectivity between the servers. Examples are based on the default VLAB topology.</p> <p>You can find instructions on how to setup VLAB in the Overview and Running VLAB sections.</p>"},{"location":"vlab/demo/#default-topology","title":"Default topology","text":"<p>The default topology is Spine-Leaf with 2 spines, 2 MCLAG leaves, 2 ESLAG leaves and 1 non-MCLAG leaf. Optionally, you can choose to run the default Collapsed Core topology using flag <code>--fabric-mode collapsed-core</code> (or <code>-m collapsed-core</code>) which only consists of 2 switches.</p> <p>For more details on customizing topologies see the Running VLAB section.</p> <p>In the default topology, the following Control Node and Switch VMs are created, the Control Node is connected to every switch, the lines are ommitted for clarity:</p> <pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n\n    L1([MCLAG Leaf 1])\n    L2([MCLAG Leaf 2])\n    L3([ESLAG Leaf 3])\n    L4([ESLAG Leaf 4])\n    L5([Leaf 5])\n\n\n    L1 &amp; L2 &amp; L5 &amp; L3 &amp; L4 --&gt; S1 &amp; S2</code></pre> <p>As well as the following test servers, as above Control Node connections are omitted:</p> <pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n    L1([MCLAG Leaf 1])\n    L2([MCLAG Leaf 2])\n    L3([ESLAG Leaf 3])\n    L4([ESLAG Leaf 4])\n    L5([Leaf 5])\n\n    TS1[Server 1]\n    TS2[Server 2]\n    TS3[Server 3]\n    TS4[Server 4]\n    TS5[Server 5]\n    TS6[Server 6]\n    TS7[Server 7]\n    TS8[Server 8]\n    TS9[Server 9]\n    TS10[Server 10]\n\n    subgraph MCLAG\n    L1\n    L2\n    end\n    TS3 --&gt; L1\n    TS1 --&gt; L1\n    TS1 --&gt; L2\n\n    TS2 --&gt; L1\n    TS2 --&gt; L2\n\n    TS4 --&gt; L2\n\n    subgraph ESLAG\n    L3\n    L4\n    end\n\n    TS7 --&gt; L3\n    TS5 --&gt; L3\n    TS5 --&gt; L4\n    TS6 --&gt; L3\n    TS6 --&gt; L4\n\n    TS8 --&gt; L4\n    TS9 --&gt; L5\n    TS10 --&gt; L5\n\n    L1 &amp; L2 &amp; L2 &amp; L3 &amp; L4 &amp; L5 &lt;----&gt; S1 &amp; S2</code></pre>"},{"location":"vlab/demo/#utility-based-vpc-creation","title":"Utility based VPC creation","text":""},{"location":"vlab/demo/#setup-vpcs","title":"Setup VPCs","text":"<p><code>hhfab vlab</code> includes a utility to create VPCs in vlab. This utility is a <code>hhfab vlab</code> sub-command. <code>hhfab vlab setup-vpcs</code>.</p> <pre><code>NAME:\n   hhfab vlab setup-vpcs - setup VPCs and VPCAttachments for all servers and configure networking on them\n\nUSAGE:\n   hhfab vlab setup-vpcs [command options]\n\nOPTIONS:\n   --dns-servers value, --dns value [ --dns-servers value, --dns value ]    DNS servers for VPCs advertised by DHCP\n   --force-clenup, -f                                                       start with removing all existing VPCs and VPCAttachments (default: false)\n   --help, -h                                                               show help\n   --interface-mtu value, --mtu value                                       interface MTU for VPCs advertised by DHCP (default: 0)\n   --ipns value                                                             IPv4 namespace for VPCs (default: \"default\")\n   --name value, -n value                                                   name of the VM or HW to access\n   --servers-per-subnet value, --servers value                              number of servers per subnet (default: 1)\n   --subnets-per-vpc value, --subnets value                                 number of subnets per VPC (default: 1)\n   --time-servers value, --ntp value [ --time-servers value, --ntp value ]  Time servers for VPCs advertised by DHCP\n   --vlanns value                                                           VLAN namespace for VPCs (default: \"default\")\n   --wait-switches-ready, --wait                                            wait for switches to be ready before and after configuring VPCs and VPCAttachments (default: true)\n\n   Global options:\n\n   --brief, -b      brief output (only warn and error) (default: false) [$HHFAB_BRIEF]\n   --cache-dir DIR  use cache dir DIR for caching downloaded files (default: \"/home/ubuntu/.hhfab-cache\") [$HHFAB_CACHE_DIR]\n   --verbose, -v    verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]\n   --workdir PATH   run as if hhfab was started in PATH instead of the current working directory (default: \"/home/ubuntu\") [$HHFAB_WORK_DIR]\n</code></pre>"},{"location":"vlab/demo/#setup-peering","title":"Setup Peering","text":"<p><code>hhfab vlab</code> includes a utility to create VPC peerings in VLAB. This utility is a <code>hhfab vlab</code> sub-command. <code>hhfab vlab setup-peerings</code>.</p> <pre><code>NAME:\n   hhfab vlab setup-peerings - setup VPC and External Peerings per requests (remove all if empty)\n\nUSAGE:\n   Setup test scenario with VPC/External Peerings by specifying requests in the format described below.\n\n   Example command:\n\n   $ hhfab vlab setup-peerings 1+2 2+4:r=border 1~as5835 2~as5835:subnets=sub1,sub2:prefixes=0.0.0.0/0,22.22.22.0/24\n\n   Which will produce:\n   1. VPC peering between vpc-01 and vpc-02\n   2. Remote VPC peering between vpc-02 and vpc-04 on switch group named border\n   3. External peering for vpc-01 with External as5835 with default vpc subnet and any routes from external permitted\n   4. External peering for vpc-02 with External as5835 with subnets sub1 and sub2 exposed from vpc-02 and default route\n      from external permitted as well any route that belongs to 22.22.22.0/24\n\n   VPC Peerings:\n\n   1+2 -- VPC peering between vpc-01 and vpc-02\n   demo-1+demo-2 -- VPC peering between demo-1 and demo-2\n   1+2:r -- remote VPC peering between vpc-01 and vpc-02 on switch group if only one switch group is present\n   1+2:r=border -- remote VPC peering between vpc-01 and vpc-02 on switch group named border\n   1+2:remote=border -- same as above\n\n   External Peerings:\n\n   1~as5835 -- external peering for vpc-01 with External as5835\n   1~ -- external peering for vpc-1 with external if only one external is present for ipv4 namespace of vpc-01, allowing\n     default subnet and any route from external\n   1~:subnets=default@prefixes=0.0.0.0/0 -- external peering for vpc-1 with auth external with default vpc subnet and\n     default route from external permitted\n   1~as5835:subnets=default,other:prefixes=0.0.0.0/0_le32_ge32,22.22.22.0/24 -- same but with more details\n   1~as5835:s=default,other:p=0.0.0.0/0_le32_ge32,22.22.22.0/24 -- same as above\n\nOPTIONS:\n   --help, -h                     show help\n   --name value, -n value         name of the VM or HW to access\n   --wait-switches-ready, --wait  wait for switches to be ready before before and after configuring peerings (default: true)\n\n   Global options:\n\n   --brief, -b      brief output (only warn and error) (default: false) [$HHFAB_BRIEF]\n   --cache-dir DIR  use cache dir DIR for caching downloaded files (default: \"/home/ubuntu/.hhfab-cache\") [$HHFAB_CACHE_DIR]\n   --verbose, -v    verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]\n   --workdir PATH   run as if hhfab was started in PATH instead of the current working directory (default: \"/home/ubuntu\") [$HHFAB_WORK_DIR]\n</code></pre>"},{"location":"vlab/demo/#test-connectivity","title":"Test Connectivity","text":"<p><code>hhfab vlab</code> includes a utility to test connectivity between servers inside VLAB. This utility is a <code>hhfab vlab</code> sub-command. <code>hhfab vlab test-connectivity</code>.</p> <pre><code>NAME:\n   hhfab vlab test-connectivity - test connectivity between all servers\n\nUSAGE:\n   hhfab vlab test-connectivity [command options]\n\nOPTIONS:\n   --curls value                  number of curl tests to run for each server to test external connectivity (0 to disable) (default: 3)\n   --help, -h                     show help\n   --iperfs value                 seconds of iperf3 test to run between each pair of reachable servers (0 to disable) (default: 10)\n   --iperfs-speed value           minimum speed in Mbits/s for iperf3 test to consider successful (0 to not check speeds) (default: 7000)\n   --name value, -n value         name of the VM or HW to access\n   --pings value                  number of pings to send between each pair of servers (0 to disable) (default: 5)\n   --wait-switches-ready, --wait  wait for switches to be ready before testing connectivity (default: true)\n\n   Global options:\n\n   --brief, -b      brief output (only warn and error) (default: false) [$HHFAB_BRIEF]\n   --cache-dir DIR  use cache dir DIR for caching downloaded files (default: \"/home/ubuntu/.hhfab-cache\") [$HHFAB_CACHE_DIR]\n   --verbose, -v    verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]\n   --workdir PATH   run as if hhfab was started in PATH instead of the current working directory (default: \"/home/ubuntu\") [$HHFAB_WORK_DIR]\n</code></pre>"},{"location":"vlab/demo/#manual-vpc-creation","title":"Manual VPC creation","text":""},{"location":"vlab/demo/#creating-and-attaching-vpcs","title":"Creating and attaching VPCs","text":"<p>You can create and attach VPCs to the VMs using the <code>kubectl fabric vpc</code> command on the Control Node or outside of the cluster using the kubeconfig. For example, run the following commands to create 2 VPCs with a single subnet each, a DHCP server enabled with its optional IP address range start defined, and to attach them to some of the test servers:</p> <pre><code>core@control-1 ~ $ kubectl get conn | grep server\nserver-01--mclag--leaf-01--leaf-02   mclag          5h13m\nserver-02--mclag--leaf-01--leaf-02   mclag          5h13m\nserver-03--unbundled--leaf-01        unbundled      5h13m\nserver-04--bundled--leaf-02          bundled        5h13m\nserver-05--unbundled--leaf-03        unbundled      5h13m\nserver-06--bundled--leaf-03          bundled        5h13m\n\ncore@control-1 ~ $ kubectl fabric vpc create --name vpc-1 --subnet 10.0.1.0/24 --vlan 1001 --dhcp --dhcp-start 10.0.1.10\n06:48:46 INF VPC created name=vpc-1\n\ncore@control-1 ~ $ kubectl fabric vpc create --name vpc-2 --subnet 10.0.2.0/24 --vlan 1002 --dhcp --dhcp-start 10.0.2.10\n06:49:04 INF VPC created name=vpc-2\n\ncore@control-1 ~ $ kubectl fabric vpc attach --vpc-subnet vpc-1/default --connection server-01--mclag--leaf-01--leaf-02\n06:49:24 INF VPCAttachment created name=vpc-1--default--server-01--mclag--leaf-01--leaf-02\n\ncore@control-1 ~ $ kubectl fabric vpc attach --vpc-subnet vpc-2/default --connection server-02--mclag--leaf-01--leaf-02\n06:49:34 INF VPCAttachment created name=vpc-2--default--server-02--mclag--leaf-01--leaf-02\n</code></pre> <p>The VPC subnet should belong to an IPv4Namespace, the default one in the VLAB is <code>10.0.0.0/16</code>:</p> <pre><code>core@control-1 ~ $ kubectl get ipns\nNAME      SUBNETS           AGE\ndefault   [\"10.0.0.0/16\"]   5h14m\n</code></pre> <p>After you created the VPCs and VPCAttachments, you can check the status of the agents to make sure that the requested configuration was applied to the switches:</p> <pre><code>core@control-1 ~ $ kubectl get agents\nNAME       ROLE          DESCR           APPLIED   APPLIEDG   CURRENTG   VERSION\nleaf-01    server-leaf   VS-01 MCLAG 1   2m2s      5          5          v0.23.0\nleaf-02    server-leaf   VS-02 MCLAG 1   2m2s      4          4          v0.23.0\nleaf-03    server-leaf   VS-03           112s      5          5          v0.23.0\nspine-01   spine         VS-04           16m       3          3          v0.23.0\nspine-02   spine         VS-05           18m       4          4          v0.23.0\n</code></pre> <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>"},{"location":"vlab/demo/#setting-up-networking-on-test-servers","title":"Setting up networking on test servers","text":"<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 pre-installed by Fabricator on test servers, <code>hhnet</code>.</p> <p>For <code>server-01</code>:</p> <pre><code>core@server-01 ~ $ hhnet cleanup\ncore@server-01 ~ $ hhnet bond 1001 enp2s1 enp2s2\n10.0.1.10/24\ncore@server-01 ~ $ ip a\n...\n3: enp2s1: &lt;BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000\n    link/ether 06:5a:e8:38:3b:ea brd ff:ff:ff:ff:ff:ff permaddr 0c:20:12:fe:01:01\n4: enp2s2: &lt;BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000\n    link/ether 06:5a:e8:38:3b:ea brd ff:ff:ff:ff:ff:ff permaddr 0c:20:12:fe:01:02\n6: bond0: &lt;BROADCAST,MULTICAST,MASTER,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP group default qlen 1000\n    link/ether 06:5a:e8:38:3b:ea brd ff:ff:ff:ff:ff:ff\n    inet6 fe80::45a:e8ff:fe38:3bea/64 scope link\n       valid_lft forever preferred_lft forever\n7: bond0.1001@bond0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP group default qlen 1000\n    link/ether 06:5a:e8:38:3b:ea brd ff:ff:ff:ff:ff:ff\n    inet 10.0.1.10/24 metric 1024 brd 10.0.1.255 scope global dynamic bond0.1001\n       valid_lft 86396sec preferred_lft 86396sec\n    inet6 fe80::45a:e8ff:fe38:3bea/64 scope link\n       valid_lft forever preferred_lft forever\n</code></pre> <p>And for <code>server-02</code>:</p> <pre><code>core@server-02 ~ $ hhnet cleanup\ncore@server-02 ~ $ hhnet bond 1002 enp2s1 enp2s2\n10.0.2.10/24\ncore@server-02 ~ $ ip a\n...\n3: enp2s1: &lt;BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000\n    link/ether 5e:10:b1:f7:d0:4c brd ff:ff:ff:ff:ff:ff permaddr 0c:20:12:fe:02:01\n4: enp2s2: &lt;BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000\n    link/ether 5e:10:b1:f7:d0:4c brd ff:ff:ff:ff:ff:ff permaddr 0c:20:12:fe:02:02\n8: bond0: &lt;BROADCAST,MULTICAST,MASTER,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP group default qlen 1000\n    link/ether 5e:10:b1:f7:d0:4c brd ff:ff:ff:ff:ff:ff\n    inet6 fe80::5c10:b1ff:fef7:d04c/64 scope link\n       valid_lft forever preferred_lft forever\n9: bond0.1002@bond0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP group default qlen 1000\n    link/ether 5e:10:b1:f7:d0:4c brd ff:ff:ff:ff:ff:ff\n    inet 10.0.2.10/24 metric 1024 brd 10.0.2.255 scope global dynamic bond0.1002\n       valid_lft 86185sec preferred_lft 86185sec\n    inet6 fe80::5c10:b1ff:fef7:d04c/64 scope link\n       valid_lft forever preferred_lft forever\n</code></pre>"},{"location":"vlab/demo/#testing-connectivity-before-peering","title":"Testing connectivity before peering","text":"<p>You can test connectivity between the servers before peering the switches using the <code>ping</code> command:</p> <pre><code>core@server-01 ~ $ ping 10.0.2.10\nPING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.\nFrom 10.0.1.1 icmp_seq=1 Destination Net Unreachable\nFrom 10.0.1.1 icmp_seq=2 Destination Net Unreachable\nFrom 10.0.1.1 icmp_seq=3 Destination Net Unreachable\n^C\n--- 10.0.2.10 ping statistics ---\n3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2003ms\n</code></pre> <pre><code>core@server-02 ~ $ ping 10.0.1.10\nPING 10.0.1.10 (10.0.1.10) 56(84) bytes of data.\nFrom 10.0.2.1 icmp_seq=1 Destination Net Unreachable\nFrom 10.0.2.1 icmp_seq=2 Destination Net Unreachable\nFrom 10.0.2.1 icmp_seq=3 Destination Net Unreachable\n^C\n--- 10.0.1.10 ping statistics ---\n3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2004ms\n</code></pre>"},{"location":"vlab/demo/#peering-vpcs-and-testing-connectivity","title":"Peering VPCs and testing connectivity","text":"<p>To enable connectivity between the VPCs, peer them using <code>kubectl fabric vpc peer</code>:</p> <pre><code>core@control-1 ~ $ kubectl fabric vpc peer --vpc vpc-1 --vpc vpc-2\n07:04:58 INF VPCPeering created name=vpc-1--vpc-2\n</code></pre> <p>Make sure to wait until the peering is applied to the switches using <code>kubectl get agents</code> command. After that, you can test connectivity between the servers again:</p> <pre><code>core@server-01 ~ $ ping 10.0.2.10\nPING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.\n64 bytes from 10.0.2.10: icmp_seq=1 ttl=62 time=6.25 ms\n64 bytes from 10.0.2.10: icmp_seq=2 ttl=62 time=7.60 ms\n64 bytes from 10.0.2.10: icmp_seq=3 ttl=62 time=8.60 ms\n^C\n--- 10.0.2.10 ping statistics ---\n3 packets transmitted, 3 received, 0% packet loss, time 2004ms\nrtt min/avg/max/mdev = 6.245/7.481/8.601/0.965 ms\n</code></pre> <pre><code>core@server-02 ~ $ ping 10.0.1.10\nPING 10.0.1.10 (10.0.1.10) 56(84) bytes of data.\n64 bytes from 10.0.1.10: icmp_seq=1 ttl=62 time=5.44 ms\n64 bytes from 10.0.1.10: icmp_seq=2 ttl=62 time=6.66 ms\n64 bytes from 10.0.1.10: icmp_seq=3 ttl=62 time=4.49 ms\n^C\n--- 10.0.1.10 ping statistics ---\n3 packets transmitted, 3 received, 0% packet loss, time 2004ms\nrtt min/avg/max/mdev = 4.489/5.529/6.656/0.886 ms\n</code></pre> <p>If you delete the VPC peering with <code>kubectl delete</code> applied to the relevant object and wait for the agent to apply the configuration on the switches, you can observe that connectivity is lost again:</p> <pre><code>core@control-1 ~ $ kubectl delete vpcpeering/vpc-1--vpc-2\nvpcpeering.vpc.githedgehog.com \"vpc-1--vpc-2\" deleted\n</code></pre> <pre><code>core@server-01 ~ $ ping 10.0.2.10\nPING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.\nFrom 10.0.1.1 icmp_seq=1 Destination Net Unreachable\nFrom 10.0.1.1 icmp_seq=2 Destination Net Unreachable\nFrom 10.0.1.1 icmp_seq=3 Destination Net Unreachable\n^C\n--- 10.0.2.10 ping statistics ---\n3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2004ms\n</code></pre> <p>You can see duplicate packets in the output of the <code>ping</code> command between some of the servers. This is expected behavior and is caused by the limitations in the VLAB environment.</p> <pre><code>core@server-01 ~ $ ping 10.0.5.10\nPING 10.0.5.10 (10.0.5.10) 56(84) bytes of data.\n64 bytes from 10.0.5.10: icmp_seq=1 ttl=62 time=9.58 ms\n64 bytes from 10.0.5.10: icmp_seq=1 ttl=62 time=9.58 ms (DUP!)\n64 bytes from 10.0.5.10: icmp_seq=2 ttl=62 time=6.99 ms\n64 bytes from 10.0.5.10: icmp_seq=2 ttl=62 time=6.99 ms (DUP!)\n64 bytes from 10.0.5.10: icmp_seq=3 ttl=62 time=9.59 ms\n64 bytes from 10.0.5.10: icmp_seq=3 ttl=62 time=9.60 ms (DUP!)\n^C\n--- 10.0.5.10 ping statistics ---\n3 packets transmitted, 3 received, +3 duplicates, 0% packet loss, time 2003ms\nrtt min/avg/max/mdev = 6.987/8.720/9.595/1.226 ms\n</code></pre>"},{"location":"vlab/demo/#using-vpcs-with-overlapping-subnets","title":"Using VPCs with overlapping subnets","text":"<p>First, create a second IPv4Namespace with the same subnet as the default one:</p> <pre><code>core@control-1 ~ $ kubectl get ipns\nNAME      SUBNETS           AGE\ndefault   [\"10.0.0.0/16\"]   24m\n\ncore@control-1 ~ $ cat &lt;&lt;EOF &gt; ipns-2.yaml\napiVersion: vpc.githedgehog.com/v1beta1\nkind: IPv4Namespace\nmetadata:\n  name: ipns-2\n  namespace: default\nspec:\n  subnets:\n  - 10.0.0.0/16\nEOF\n\ncore@control-1 ~ $ kubectl apply -f ipns-2.yaml\nipv4namespace.vpc.githedgehog.com/ipns-2 created\n\ncore@control-1 ~ $ kubectl get ipns\nNAME      SUBNETS           AGE\ndefault   [\"10.0.0.0/16\"]   30m\nipns-2    [\"10.0.0.0/16\"]   8s\n</code></pre> <p>Let's assume that <code>vpc-1</code> already exists and is attached to <code>server-01</code> (see Creating and attaching VPCs). Now we can create <code>vpc-3</code> with the same subnet as <code>vpc-1</code> (but in the different IPv4Namespace) and attach it to the <code>server-03</code>:</p> <pre><code>core@control-1 ~ $ cat &lt;&lt;EOF &gt; vpc-3.yaml\napiVersion: vpc.githedgehog.com/v1beta1\nkind: VPC\nmetadata:\n  name: vpc-3\n  namespace: default\nspec:\n  ipv4Namespace: ipns-2\n  subnets:\n    default:\n      dhcp:\n        enable: true\n        range:\n          start: 10.0.1.10\n      subnet: 10.0.1.0/24\n      vlan: 2001\n  vlanNamespace: default\nEOF\n\ncore@control-1 ~ $ kubectl apply -f vpc-3.yaml\n</code></pre> <p>At that point you can setup networking on <code>server-03</code> the same as you did for <code>server-01</code> and <code>server-02</code> in a previous section. Once you have configured networking, <code>server-01</code> and <code>server-03</code> have IP addresses from the same subnets.</p>"},{"location":"vlab/overview/","title":"VLAB Overview","text":"<p>It's possible to run Hedgehog Fabric in a fully virtual environment using QEMU/KVM and SONiC Virtual Switch (VS). It's a great way to try out Fabric and learn about its look and feel, API, and capabilities. It's not suitable for any data plane or performance testing, or for production use.</p> <p>In the VLAB all switches start as empty VMs with only the ONIE image on them, and they go through the whole discovery, boot and installation process like on real hardware.</p>"},{"location":"vlab/overview/#hhfab","title":"HHFAB","text":"<p>Hedgehog maintains a utility to install and configure VLAB, called <code>hhfab</code>, aka Fabricator.</p> <p>The <code>hhfab</code> CLI provides a special command <code>vlab</code> to manage the virtual labs. It allows you to run sets of virtual machines to simulate the Fabric infrastructure including control node, switches, test servers and it automatically runs the installer to get Fabric up and running.</p> <p>You can find more information about getting <code>hhfab</code> in the download section.</p>"},{"location":"vlab/overview/#system-requirements","title":"System Requirements","text":"<p>Currently, it's only tested on Ubuntu 22.04 LTS, but should work on any Linux distribution with QEMU/KVM support and fairly up-to-date packages.</p> <p>The following packages needs to be installed: <code>qemu-kvm socat</code>. Docker is also required, to login into the OCI registry.</p> <p>By default, the VLAB topology is Spine-Leaf with 2 spines, 2 MCLAG leaves and 1 non-MCLAG leaf. Optionally, you can choose to run the default Collapsed Core topology using flag <code>--fabric-mode collapsed-core</code> (or <code>-m collapsed-core</code>) which only consists of 2 switches.</p> <p>You can calculate the system requirements based on the allocated resources to the VMs using the following table:</p> Device vCPU RAM Disk Control Node 6 6GB 100GB Test Server 2 768MB 10GB Switch 4 5GB 50GB <p>These numbers give approximately the following requirements for the default topologies:</p> <ul> <li>Spine-Leaf: 38 vCPUs, 36352 MB, 410 GB disk</li> <li>Collapsed Core: 22 vCPUs, 19456 MB, 240 GB disk</li> </ul> <p>Usually, none of the VMs will reach 100% utilization of the allocated resources, but as a rule of thumb you should make sure that you have at least allocated RAM and disk space for all VMs.</p> <p>NVMe SSD for VM disks is highly recommended.</p>"},{"location":"vlab/overview/#installing-prerequisites","title":"Installing Prerequisites","text":"<p>To run VLAB, your system needs <code>docker</code>,<code>qemu</code>,<code>kvm</code>, and <code>hhfab</code>. On Ubuntu 22.04 LTS you can install all required packages using the following commands:</p>"},{"location":"vlab/overview/#docker","title":"Docker","text":"<pre><code>curl -fsSL https://get.docker.com -o install-docker.sh\nsudo sh install-docker.sh\nsudo usermod -aG docker $USER\nnewgrp docker\n</code></pre>"},{"location":"vlab/overview/#qemukvm","title":"Qemu/KVM","text":"<pre><code>sudo apt install -y qemu-kvm swtpm-tools tpm2-tools socat\nsudo usermod -aG kvm $USER\nnewgrp kvm\nkvm-ok\n</code></pre> <p>Good output of the <code>kvm-ok</code> command should look like this:</p> <pre><code>ubuntu@docs:~$ kvm-ok\nINFO: /dev/kvm exists\nKVM acceleration can be used\n</code></pre>"},{"location":"vlab/overview/#oras","title":"Oras","text":"<p>For convenience Hedgehog provides a script to install <code>oras</code>:</p> <pre><code>curl -fsSL https://i.hhdev.io/oras | bash\n</code></pre>"},{"location":"vlab/overview/#hhfab_1","title":"Hhfab","text":"<p>You need a GitHub access token to download <code>hhfab</code>, please submit a ticket using the Hedgehog Support Portal. Once in possession of the credentials, use the provided username and token to log into the GitHub container registry:</p> <pre><code>docker login ghcr.io --username provided_username --password provided_token\n</code></pre> <p>Once logged in, download and run the script:</p> <pre><code>curl -fsSL https://i.hhdev.io/hhfab | bash\n</code></pre>"},{"location":"vlab/overview/#next-steps","title":"Next steps","text":"<ul> <li>Configure and Run VLAB</li> </ul>"},{"location":"vlab/running/","title":"Running VLAB","text":"<p>Make sure to follow the prerequisites and check system requirements in the VLAB Overview section before running VLAB.</p>"},{"location":"vlab/running/#initialize-vlab","title":"Initialize VLAB","text":"<p>First, initialize Fabricator by running <code>hhfab init --dev</code>. This command creates the <code>fab.yaml</code> file, which is the main configuration file for the fabric. This command supports several customization options that are listed in the output of <code>hhfab init --help</code>.</p> <pre><code>ubuntu@docs:~$ hhfab init --dev\n11:26:52 INF Hedgehog Fabricator version=v0.30.0\n11:26:52 INF Generated initial config\n11:26:52 INF Adjust configs (incl. credentials, modes, subnets, etc.) file=fab.yaml\n11:26:52 INF Include wiring files (.yaml) or adjust imported ones dir=include\n</code></pre>"},{"location":"vlab/running/#vlab-topology","title":"VLAB Topology","text":"<p>By default, <code>hhfab init</code> creates 2 spines, 2 MCLAG leaves and 1 non-MCLAG leaf with 2 fabric connections (between each spine and leaf), 2 MCLAG peer links and 2 MCLAG session links as well as 2 loopbacks per leaf for implementing VPC loopback workaround. To generate the preceding topology, <code>hhfab vlab gen</code>. You can also configure the number of spines, leafs, connections, and so on. For example, flags <code>--spines-count</code> and <code>--mclag-leafs-count</code> allow you to set the number of spines and MCLAG leaves, respectively. For complete options, <code>hhfab vlab gen -h</code>.</p> <p><pre><code>ubuntu@docs:~$ hhfab vlab gen\n21:27:16 INF Hedgehog Fabricator version=v0.30.0\n21:27:16 INF Building VLAB wiring diagram fabricMode=spine-leaf\n21:27:16 INF &gt;&gt;&gt; spinesCount=2 fabricLinksCount=2\n21:27:16 INF &gt;&gt;&gt; eslagLeafGroups=2\n21:27:16 INF &gt;&gt;&gt; mclagLeafsCount=2 mclagSessionLinks=2 mclagPeerLinks=2\n21:27:16 INF &gt;&gt;&gt; orphanLeafsCount=1 vpcLoopbacks=2\n21:27:16 INF &gt;&gt;&gt; mclagServers=2 eslagServers=2 unbundledServers=1 bundledServers=1\n21:27:16 INF Generated wiring file name=vlab.generated.yaml\n</code></pre> You can jump to the instructions to start VLAB, or see the next section for customizing the topology.</p>"},{"location":"vlab/running/#collapsed-core","title":"Collapsed Core","text":"<p>If a Collapsed Core topology is desired, after the <code>hhfab init --dev</code> step, edit the resulting <code>fab.yaml</code> file and change the <code>mode: spine-leaf</code> to <code>mode: collapsed-core</code>:</p> <pre><code>ubuntu@docs:~$ hhfab vlab gen\n11:39:02 INF Hedgehog Fabricator version=v0.30.0\n11:39:02 INF Building VLAB wiring diagram fabricMode=collapsed-core\n11:39:02 INF &gt;&gt;&gt; mclagLeafsCount=2 mclagSessionLinks=2 mclagPeerLinks=2\n11:39:02 INF &gt;&gt;&gt; orphanLeafsCount=0 vpcLoopbacks=2\n11:39:02 INF &gt;&gt;&gt; mclagServers=2 eslagServers=2 unbundledServers=1 bundledServers=1\n11:39:02 INF Generated wiring file name=vlab.generated.yaml\n</code></pre>"},{"location":"vlab/running/#custom-spine-leaf","title":"Custom Spine Leaf","text":"<p>Or you can run custom topology with 2 spines, 4 MCLAG leaves and 2 non-MCLAG leaves using flags:</p> <pre><code>ubuntu@docs:~$ hhfab vlab gen --mclag-leafs-count 4 --orphan-leafs-count 2\n11:41:06 INF Hedgehog Fabricator version=v0.30.0\n11:41:06 INF Building VLAB wiring diagram fabricMode=spine-leaf\n11:41:06 INF &gt;&gt;&gt; spinesCount=2 fabricLinksCount=2\n11:41:06 INF &gt;&gt;&gt; eslagLeafGroups=\"\"\n11:41:06 INF &gt;&gt;&gt; mclagLeafsCount=4 mclagSessionLinks=2 mclagPeerLinks=2\n11:41:06 INF &gt;&gt;&gt; orphanLeafsCount=2 vpcLoopbacks=2\n11:41:06 INF &gt;&gt;&gt; mclagServers=2 eslagServers=2 unbundledServers=1 bundledServers=1\n11:41:06 INF Generated wiring file name=vlab.generated.yaml\n</code></pre> <p>Additionally, you can pass extra Fabric configuration items using flags on <code>init</code> command or by passing a configuration file. For more information, refer to the Fabric Configuration section.</p> <p>Once you have initialized the VLAB, download the artifacts and build the installer using <code>hhfab build</code>. This command automatically downloads all required artifacts from the OCI registry and builds the installer and all other prerequisites for running the VLAB.</p>"},{"location":"vlab/running/#build-the-installer-and-start-vlab","title":"Build the Installer and Start VLAB","text":"<p>To build and start the virtual machines, use <code>hhfab vlab up</code>. For successive runs, use the <code>--kill-stale</code> flag to ensure that any virtual machines from a previous run are gone. <code>hhfab vlab up</code> runs in the foreground and does not return, which allows you to stop all VLAB VMs by simply pressing <code>Ctrl + C</code>. <pre><code>ubuntu@docs:~$ hhfab vlab up\n11:48:22 INF Hedgehog Fabricator version=v0.30.0\n11:48:22 INF Wiring hydrated successfully mode=if-not-present\n11:48:22 INF VLAB config created file=vlab/config.yaml\n11:48:22 INF Downloader cache=/home/ubuntu/.hhfab-cache/v1 repo=ghcr.io prefix=githedgehog\n11:48:22 INF Building installer control=control-1\n11:48:22 INF Adding recipe bin to installer control=control-1\n11:48:24 INF Adding k3s and tools to installer control=control-1\n11:48:25 INF Adding zot to installer control=control-1\n11:48:25 INF Adding cert-manager to installer control=control-1\n11:48:26 INF Adding config and included wiring to installer control=control-1\n11:48:26 INF Adding airgap artifacts to installer control=control-1\n11:48:36 INF Archiving installer path=/home/ubuntu/result/control-1-install.tgz control=control-1\n11:48:45 INF Creating ignition path=/home/ubuntu/result/control-1-install.ign control=control-1\n11:48:46 INF Taps and bridge are ready count=8\n11:48:46 INF Downloader cache=/home/ubuntu/.hhfab-cache/v1 repo=ghcr.io prefix=githedgehog\n11:48:46 INF Preparing new vm=control-1 type=control\n11:48:51 INF Preparing new vm=server-01 type=server\n11:48:52 INF Preparing new vm=server-02 type=server\n11:48:54 INF Preparing new vm=server-03 type=server\n11:48:55 INF Preparing new vm=server-04 type=server\n11:48:57 INF Preparing new vm=server-05 type=server\n11:48:58 INF Preparing new vm=server-06 type=server\n11:49:00 INF Preparing new vm=server-07 type=server\n11:49:01 INF Preparing new vm=server-08 type=server\n11:49:03 INF Preparing new vm=server-09 type=server\n11:49:04 INF Preparing new vm=server-10 type=server\n11:49:05 INF Preparing new vm=leaf-01 type=switch\n11:49:06 INF Preparing new vm=leaf-02 type=switch\n11:49:06 INF Preparing new vm=leaf-03 type=switch\n11:49:06 INF Preparing new vm=leaf-04 type=switch\n11:49:06 INF Preparing new vm=leaf-05 type=switch\n11:49:06 INF Preparing new vm=spine-01 type=switch\n11:49:06 INF Preparing new vm=spine-02 type=switch\n11:49:06 INF Starting VMs count=18 cpu=\"54 vCPUs\" ram=\"49664 MB\" disk=\"550 GB\"\n11:49:59 INF Uploading control install vm=control-1 type=control\n11:53:39 INF Running control install vm=control-1 type=control\n11:53:40 INF control-install: 01:53:39 INF Hedgehog Fabricator Recipe version=v0.30.0 vm=control-1\n11:53:40 INF control-install: 01:53:39 INF Running control node installation vm=control-1\n12:00:32 INF control-install: 02:00:31 INF Control node installation complete vm=control-1\n12:00:32 INF Control node is ready vm=control-1 type=control\n12:00:32 INF All VMs are ready\n</code></pre> When the message <code>INF Control node is ready vm=control-1 type=control</code> from the installer's output means that the installer has finished. After this line has been displayed, you can get into the control node and other VMs to watch the Fabric coming up and switches getting provisioned. See Accessing the VLAB.</p>"},{"location":"vlab/running/#enable-outside-connectivity-from-vlab-vms","title":"Enable Outside connectivity from VLAB VMs","text":"<p>By default, all test server VMs are isolated and have no connectivity to the host or the Internet. You can configure enable connectivity using <code>hhfab vlab up --restrict-servers=false</code> to allow the test servers to access the Internet and the host. When you enable connectivity, VMs get a default route pointing to the host, which means that in case of the VPC peering you need to configure test server VMs to use the VPC attachment as a default route (or just some specific subnets).</p>"},{"location":"vlab/running/#accessing-the-vlab","title":"Accessing the VLAB","text":"<p>The <code>hhfab vlab</code> command provides <code>ssh</code> and <code>serial</code> subcommands to access the VMs. You can use <code>ssh</code> to get into the control node and test servers after the VMs are started. You can use <code>serial</code> to get into the switch VMs while they are provisioning and installing the software. After switches are installed you can use <code>ssh</code> to get into them.</p> <p>You can select device you want to access or pass the name using the <code>--vm</code> flag.</p> <pre><code>ubuntu@docs:~$ hhfab vlab ssh\nUse the arrow keys to navigate: \u2193 \u2191 \u2192 \u2190  and / toggles search\nSSH to VM:\n  \ud83e\udd94 control-1\n  server-01\n  server-02\n  server-03\n  server-04\n  server-05\n  server-06\n  leaf-01\n  leaf-02\n  leaf-03\n  spine-01\n  spine-02\n\n----------- VM Details ------------\nID:             0\nName:           control-1\nReady:          true\nBasedir:        .hhfab/vlab-vms/control-1\n</code></pre>"},{"location":"vlab/running/#default-credentials","title":"Default credentials","text":"<p>Fabricator creates default users and keys for you to login into the control node and test servers as well as for the SONiC Virtual Switches.</p> <p>The default user with password-less sudo for the control node and test servers is <code>core</code> with password <code>HHFab.Admin!</code>. The admin user with full access and password-less sudo for the switches is <code>admin</code> with password <code>HHFab.Admin!</code>. The read-only, non-sudo user with access to the switch CLI is <code>op</code> with password <code>HHFab.Op!</code>.</p>"},{"location":"vlab/running/#use-kubectl-to-interact-with-the-fabric","title":"Use Kubectl to Interact with the Fabric","text":"<p>On the control node you have access to kubectl, Fabric CLI, and k9s to manage the Fabric. To view information about the switches run <code>kubectl get agents -o wide</code>. After the control node is available it usually takes about 10-15 minutes for the switches to get installed.</p> <p>After the switches are provisioned, the command returns something like this:</p> <pre><code>core@control-1 ~ $ kubectl get agents -o wide\nNAME       ROLE          DESCR           HWSKU                      ASIC   HEARTBEAT   APPLIED   APPLIEDG   CURRENTG   VERSION   SOFTWARE                ATTEMPT   ATTEMPTG   AGE\nleaf-01    server-leaf   VS-01 MCLAG 1   DellEMC-S5248f-P-25G-DPB   vs     30s         5m5s      4          4          v0.23.0   4.1.1-Enterprise_Base   5m5s      4          10m\nleaf-02    server-leaf   VS-02 MCLAG 1   DellEMC-S5248f-P-25G-DPB   vs     27s         3m30s     3          3          v0.23.0   4.1.1-Enterprise_Base   3m30s     3          10m\nleaf-03    server-leaf   VS-03           DellEMC-S5248f-P-25G-DPB   vs     18s         3m52s     4          4          v0.23.0   4.1.1-Enterprise_Base   3m52s     4          10m\nspine-01   spine         VS-04           DellEMC-S5248f-P-25G-DPB   vs     26s         3m59s     3          3          v0.23.0   4.1.1-Enterprise_Base   3m59s     3          10m\nspine-02   spine         VS-05           DellEMC-S5248f-P-25G-DPB   vs     19s         3m53s     4          4          v0.23.0   4.1.1-Enterprise_Base   3m53s     4          10m\n</code></pre> <p>The <code>Heartbeat</code> column shows how long ago the switch has sent the heartbeat to the control node. The <code>Applied</code> column shows how long ago the switch has applied the configuration. <code>AppliedG</code> shows the generation of the configuration applied. <code>CurrentG</code> shows the generation of the configuration the switch is supposed to run. Different values for <code>AppliedG</code> and <code>CurrentG</code> mean that the switch is in the process of applying the configuration.</p> <p>At that point Fabric is ready and you can use <code>kubectl</code> and <code>kubectl fabric</code> to manage the Fabric. You can find more about managing the Fabric in the Running Demo and User Guide sections.</p>"},{"location":"vlab/running/#getting-main-fabric-objects","title":"Getting main Fabric objects","text":"<p>You can list the main Fabric objects by running <code>kubectl get</code> on the control node. You can find more details about using the Fabric in the User Guide, Fabric API and Fabric CLI sections.</p> <p>For example, to get the list of switches, run:</p> <pre><code>core@control-1 ~ $ kubectl get switch\nNAME       ROLE          DESCR           GROUPS   LOCATIONUUID                           AGE\nleaf-01    server-leaf   VS-01 MCLAG 1            5e2ae08a-8ba9-599a-ae0f-58c17cbbac67   6h10m\nleaf-02    server-leaf   VS-02 MCLAG 1            5a310b84-153e-5e1c-ae99-dff9bf1bfc91   6h10m\nleaf-03    server-leaf   VS-03                    5f5f4ad5-c300-5ae3-9e47-f7898a087969   6h10m\nspine-01   spine         VS-04                    3e2c4992-a2e4-594b-bbd1-f8b2fd9c13da   6h10m\nspine-02   spine         VS-05                    96fbd4eb-53b5-5a4c-8d6a-bbc27d883030   6h10m\n</code></pre> <p>Similarly, to get the list of servers, run:</p> <pre><code>core@control-1 ~ $ kubectl get server\nNAME        TYPE      DESCR                        AGE\ncontrol-1   control   Control node                 6h10m\nserver-01             S-01 MCLAG leaf-01 leaf-02   6h10m\nserver-02             S-02 MCLAG leaf-01 leaf-02   6h10m\nserver-03             S-03 Unbundled leaf-01       6h10m\nserver-04             S-04 Bundled leaf-02         6h10m\nserver-05             S-05 Unbundled leaf-03       6h10m\nserver-06             S-06 Bundled leaf-03         6h10m\n</code></pre> <p>For connections, use:</p> <pre><code>core@control-1 ~ $ kubectl get connection\nNAME                                 TYPE           AGE\nleaf-01--mclag-domain--leaf-02       mclag-domain   6h11m\nleaf-01--vpc-loopback                vpc-loopback   6h11m\nleaf-02--vpc-loopback                vpc-loopback   6h11m\nleaf-03--vpc-loopback                vpc-loopback   6h11m\nserver-01--mclag--leaf-01--leaf-02   mclag          6h11m\nserver-02--mclag--leaf-01--leaf-02   mclag          6h11m\nserver-03--unbundled--leaf-01        unbundled      6h11m\nserver-04--bundled--leaf-02          bundled        6h11m\nserver-05--unbundled--leaf-03        unbundled      6h11m\nserver-06--bundled--leaf-03          bundled        6h11m\nspine-01--fabric--leaf-01            fabric         6h11m\nspine-01--fabric--leaf-02            fabric         6h11m\nspine-01--fabric--leaf-03            fabric         6h11m\nspine-02--fabric--leaf-01            fabric         6h11m\nspine-02--fabric--leaf-02            fabric         6h11m\nspine-02--fabric--leaf-03            fabric         6h11m\n</code></pre> <p>For IPv4 and VLAN namespaces, use:</p> <pre><code>core@control-1 ~ $ kubectl get ipns\nNAME      SUBNETS           AGE\ndefault   [\"10.0.0.0/16\"]   6h12m\n\ncore@control-1 ~ $ kubectl get vlanns\nNAME      AGE\ndefault   6h12m\n</code></pre>"},{"location":"vlab/running/#reset-vlab","title":"Reset VLAB","text":"<p>If VLAB is currently running, press <code>Ctrl + C</code> to stop it. To reset VLAB and start over run <code>hhfab init -f</code>. This option forces the process to overwrite your existing configuration in <code>fab.yaml</code>.</p>"},{"location":"vlab/running/#next-steps","title":"Next steps","text":"<ul> <li>Running Demo</li> </ul>"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Introduction","text":"<p>The Hedgehog Open Network Fabric is an open networking platform that brings the user experience enjoyed by so many in the public cloud to private environments. It comes without vendor lock-in.</p> <p>The Fabric is built around the concept of VPCs (Virtual Private Clouds), similar to public cloud offerings. It provides a multi-tenant API to define the user intent on network isolation and connectivity, which is automatically transformed into configuration for switches and software appliances.</p> <p>You can read more about its concepts and architecture in the documentation.</p> <p>You can find out how to download and try the Fabric on the self-hosted fully virtualized lab or on hardware.</p>"},{"location":"architecture/fabric/","title":"Hedgehog Network Fabric","text":"<p>The Hedgehog Open Network Fabric is an open-source network architecture that provides connectivity between virtual and physical workloads and provides a way to achieve network isolation between different groups of workloads using standard BGP EVPN and VXLAN technology. The fabric provides a standard Kubernetes interface to manage the elements in the physical network and provides a mechanism to configure virtual networks and define attachments to these virtual networks. The Hedgehog Fabric provides isolation between different groups of workloads by placing them in different virtual networks called VPC's. To achieve this, it defines different abstractions starting from the physical network where a set of <code>Connection</code> objects defines how a physical server on the network connects to a physical switch on the fabric.</p>"},{"location":"architecture/fabric/#underlay-network","title":"Underlay Network","text":"<p>The Hedgehog Fabric currently supports two underlay network topologies.</p>"},{"location":"architecture/fabric/#collapsed-core","title":"Collapsed Core","text":"<p>A collapsed core topology is just a pair of switches connected in a MCLAG configuration with no other network elements. All workloads attach to these two switches.</p> <p></p> <p>The leaves in this setup are configured to be in a MCLAG pair and servers can either be connected to both switches as a MCLAG port channel or as orphan ports connected to only one switch. Both the leaves peer to external networks using BGP and act as gateway for workloads attached to them. The configuration of the underlay in the collapsed core is very simple and is ideal for very small deployments.</p>"},{"location":"architecture/fabric/#spine-leaf","title":"Spine-Leaf","text":"<p>A spine-leaf topology is a standard Clos network with workloads attaching to leaf switches and the spines providing connectivity between different leaves.</p> <p></p> <p>This kind of topology is useful for bigger deployments and provides all the advantages of a typical Clos network. The underlay network is established using eBGP where each leaf has a separate ASN and peers will all spines in the network. RFC7938 was used as the reference for establishing the underlay network.</p>"},{"location":"architecture/fabric/#overlay-network","title":"Overlay Network","text":"<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. 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 VPC. The following subsections contain a high-level overview of how VPCs are implemented in the Hedgehog Fabric and its associated objects.</p>"},{"location":"architecture/fabric/#vpc","title":"VPC","text":"<p>The previous subsections have described what a VPC is, and how to attach workloads to a specific VPC. The following bullet points describe how VPCs are actually implemented in the network to ensure a private view the network.</p> <ul> <li>Each VPC is modeled as a VRF on each switch where there are VPC attachments defined for this VPC. 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   and configuring an EVPN instance in each VRF, a shared L3VNI is established across the entire fabric. All VRFs   participating in this VNI can freely communicate with each other without the need for a policy. A VLAN is allocated   for each VRF which functions as an IRB VLAN for the VRF.</li> <li>The VRF created on each switch corresponding to a VPC configures a BGP instance with EVPN to advertise its locally   attached subnets and import routes from its peered VPCs. The BGP instance in the tenant VRFs does not establish   neighbor relationships and is purely used to advertise locally attached routes into the VPC (all VRFs with the same   L3VNI) across leaves in the network.</li> <li>A VPC can have multiple subnets. Each subnet in the VPC is modeled as a VLAN on the switch. The VLAN is only locally   significant and a given subnet might have different VLANs on different leaves on the network. A globally significant   VNI is assigned to each subnet. This VNI is used to extend the subnet across different leaves in the network and   provides a view of single stretched L2 domain if the applications need it.</li> <li>The Hedgehog Fabric has a built-in DHCP server which will automatically assign IP addresses to each workload depending   on the VPC it belongs to. This is achieved by configuring a DHCP relay on each of the server facing VLANs. The DHCP   server is accessible through the underlay network and is shared by all VPCs in the fabric. The inbuilt DHCP server is   capable of identifying the source VPC of the request and assigning IP addresses from a pool allocated to the VPC at   creation.</li> <li>A VPC by default cannot communicate to anyone outside the VPC and specific peering rules are required to allow   communication to external networks or to other VPCs.</li> </ul>"},{"location":"architecture/fabric/#vpc-peering","title":"VPC Peering","text":"<p>To enable communication between 2 different VPCs, one needs to configure a VPC peering policy. The Hedgehog Fabric supports two different peering modes.</p> <ul> <li>Local Peering: A local peering directly imports routes from another VPC locally. This is achieved by a simple   import route from the peer VPC. In case there are no locally attached workloads to the peer VPC the fabric   automatically creates a stub VPC for peering and imports routes from it. This allows VPCs to peer with each other   without the need for a dedicated peering leaf. If a local peering is done for a pair of VPCs which have locally   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. 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 VPC'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   the peering switch advertise default routes into their specific VRFs identified by the L3VNI. All traffic that does   not belong to the VPCs is forwarded to the peering switch which has routes to the other VPCs and gets forwarded from   there. The bandwidth limitation that exists in the local peering solution is solved here as the bandwidth between the   two VPCs is determined by the fabric cross section bandwidth.</li> </ul>"},{"location":"architecture/overview/","title":"Overview","text":"<p>Under construction.</p>"},{"location":"concepts/overview/","title":"Concepts","text":""},{"location":"concepts/overview/#introduction","title":"Introduction","text":"<p>Hedgehog Open Network Fabric is built on top of Kubernetes and uses Kubernetes API to manage its resources. It means that all user-facing APIs are Kubernetes Custom Resources (CRDs), so you can use standard Kubernetes tools to manage Fabric resources.</p> <p>Hedgehog Fabric consists of the following components:</p> <ul> <li>Fabricator - special tool to install and configure Fabric, or to run virtual labs</li> <li>Control Node - one or more Kubernetes nodes in a single cluster running Fabric software:<ul> <li>Fabric Controller - main control plane component that manages Fabric resources</li> </ul> </li> <li>Fabric Kubectl plugin (Fabric CLI) - kubectl plugin to manage Fabric resources in an easy way</li> <li>Fabric Agent - runs on every switch and manages switch configuration</li> </ul>"},{"location":"concepts/overview/#fabric-api","title":"Fabric API","text":"<p>All infrastructure is represented as a set of Fabric resource (Kubernetes CRDs) and named Wiring Diagram. With this representation, Fabric defines switches, servers, control nodes, external systems and connections between them in a single place and then uses these definitions to deploy and manage the whole infrastructure. On top of the Wiring Diagram, Fabric provides a set of APIs to manage the VPCs and the connections between them and between VPCs and External systems.</p>"},{"location":"concepts/overview/#wiring-diagram-api","title":"Wiring Diagram API","text":"<p>Wiring Diagram consists of the following resources:</p> <ul> <li>\"Devices\": describe any device in the Fabric and can be of two types:<ul> <li>Switch: configuration of the switch, containing for example: port group speeds, port breakouts, switch IP/ASN</li> <li>Server: any physical server attached to the Fabric including Control Nodes</li> </ul> </li> <li>Connection: any logical connection for devices<ul> <li>usually it's a connection between two or more ports on two different devices</li> <li>for example: MCLAG Peer Link, Unbundled/MCLAG server connections, Fabric connection between spine and leaf</li> </ul> </li> <li>VLANNamespace -&gt; non-overlapping VLAN ranges for attaching servers</li> <li>IPv4Namespace -&gt; non-overlapping IPv4 ranges for VPC subnets</li> </ul>"},{"location":"concepts/overview/#user-facing-api","title":"User-facing API","text":"<ul> <li>VPC API<ul> <li>VPC: Virtual Private Cloud, similar to a public cloud VPC, provides an isolated private network for the   resources, with support for multiple subnets, each with user-defined VLANs and optional DHCP service</li> <li>VPCAttachment: represents a specific VPC subnet assignment to the Connection object which means exact server port to a VPC binding</li> <li>VPCPeering: enables VPC-to-VPC connectivity (could be Local where VPCs are used or Remote peering on the border/mixed leaves)</li> </ul> </li> <li>External API<ul> <li>External: definition of the \"external system\" to peer with (could be one or multiple devices such as edge/provider routers)</li> <li>ExternalAttachment: configuration for a specific switch (using Connection object) describing how it connects to an external system</li> <li>ExternalPeering: provides VPC with External connectivity by exposing specific VPC subnets to the external system and allowing inbound routes from it</li> </ul> </li> </ul>"},{"location":"concepts/overview/#fabricator","title":"Fabricator","text":"<p>Installer builder and VLAB.</p> <ul> <li>Installer builder based on a preset (currently: <code>vlab</code> for virtual and <code>lab</code> for physical)<ul> <li>Main input: Wiring Diagram</li> <li>All input artifacts coming from OCI registry</li> <li>Always full airgap (everything running from private registry)</li> <li>Flatcar Linux for Control Node, generated <code>ignition.json</code></li> <li>Automatic K3s installation and private registry setup</li> <li>All components and their dependencies running in Kubernetes</li> </ul> </li> <li>Integrated Virtual Lab (VLAB) management</li> <li>Future:<ul> <li>In-cluster (control) Operator to manage all components</li> <li>Upgrades handling for everything starting Control Node OS</li> <li>Installation progress, status and retries</li> <li>Disaster recovery and backups</li> </ul> </li> </ul>"},{"location":"concepts/overview/#fabric","title":"Fabric","text":"<p>Control plane and switch agent.</p> <ul> <li>Currently Fabric is basically a single controller manager running in Kubernetes<ul> <li>It includes controllers for different CRDs and needs</li> <li>For example, auto assigning VNIs to VPCs or generating the Agent configuration</li> <li>Additionally, it's running the admission webhook for Hedgehog's CRD APIs</li> </ul> </li> <li>The Agent is watching for the corresponding Agent CRD in Kubernetes API<ul> <li>It applies the changes and saves the new configuration locally</li> <li>It reports status and information back to the API</li> <li>It can perform reinstallation and reboot of SONiC</li> </ul> </li> </ul>"},{"location":"contribute/docs/","title":"Documentation","text":""},{"location":"contribute/docs/#getting-started","title":"Getting started","text":"<p>This documentation is done using MkDocs with multiple plugins enabled. It's based on the Markdown, you can find basic syntax overview here.</p> <p>In order to contribute to the documentation, you'll need to have Git and Docker installed on your machine as well as any editor of your choice, preferably supporting Markdown preview. You can run the preview server using following command:</p> <pre><code>just serve\n</code></pre> <p>Now you can open continuously updated preview of your edits in browser at http://127.0.0.1:8000. Pages will be automatically updated while you're editing.</p> <p>Additionally you can run</p> <pre><code>just build\n</code></pre> <p>to make sure that your changes will be built correctly and doesn't break documentation.</p>"},{"location":"contribute/docs/#workflow","title":"Workflow","text":"<p>If you want to quick edit any page in the documentation, you can press the <code>Edit this page</code> icon at the top right of the page. It'll open the page in the GitHub editor. You can edit it and create a pull request with your changes.</p> <p>Please, never push to the <code>master</code> or <code>release/*</code> branches directly. Always create a pull request and wait for the review.</p> <p>Each pull request will be automatically built and preview will be deployed. You can find the link to the preview in the comments in pull request.</p>"},{"location":"contribute/docs/#repository","title":"Repository","text":"<p>Documentation is organized in per-release branches:</p> <ul> <li><code>master</code> - ongoing development, not released yet, referenced as <code>dev</code> version in the documentation</li> <li><code>release/alpha-1</code>/<code>release/alpha-2</code> - alpha releases, referenced as <code>alpha-1</code>/<code>alpha-2</code> versions in the documentation, if patches released for alpha-1, they'll be merged into <code>release/alpha-1</code> branch</li> <li><code>release/v1.0</code> - first stable release, referenced as <code>v1.0</code> version in the documentation, if patches (e.g. <code>v1.0.1</code>) released for v1.0, they'll be merged into <code>release/v1.0</code> branch</li> </ul> <p>Latest release branch is referenced as <code>latest</code> version in the documentation and will be used by default when you open the documentation.</p>"},{"location":"contribute/docs/#file-layout","title":"File layout","text":"<p>All documentation files are located in <code>docs</code> directory. Each file is a Markdown file with <code>.md</code> extension. You can create subdirectories to organize your files. Each directory can have a <code>.pages</code> file that overrides the default navigation order and titles.</p> <p>For example, top-level <code>.pages</code> in this repository looks like this:</p> <pre><code>nav:\n  - index.md\n  - getting-started\n  - concepts\n  - Wiring Diagram: wiring\n  - Install &amp; Upgrade: install-upgrade\n  - User Guide: user-guide\n  - Reference: reference\n  - Troubleshooting: troubleshooting\n  - ...\n  - release-notes\n  - contribute\n</code></pre> <p>Where you can add pages by file name like <code>index.md</code> and page title will be taked from the file (first line with <code>#</code>). Additionally, you can reference the whole directory to created nested section in navigation. You can also add custom titles by using <code>:</code> separator like <code>Wiring Diagram: wiring</code> where <code>Wiring Diagram</code> is a title and <code>wiring</code> is a file/directory name.</p> <p>More details in the MkDocs Pages plugin.</p>"},{"location":"contribute/docs/#abbreviations","title":"Abbreviations","text":"<p>You can find abbreviations in <code>includes/abbreviations.md</code> file. You can add various abbreviations there and all usages of the defined words in the documentation will get a highlight.</p> <p>For example, we have following in <code>includes/abbreviations.md</code>:</p> <pre><code>*[HHFab]: Hedgehog Fabricator - a tool for building Hedgehog Fabric\n</code></pre> <p>It'll highlight all usages of <code>HHFab</code> in the documentation and show a tooltip with the definition like this: HHFab.</p>"},{"location":"contribute/docs/#markdown-extensions","title":"Markdown extensions","text":"<p>We're using MkDocs Material theme with multiple extensions enabled. You can find detailed reference here, but here you can find some of the most useful ones.</p> <p>To view code for examples, please, check the source code of this page.</p>"},{"location":"contribute/docs/#text-formatting","title":"Text formatting","text":"<p>Text can be deleted and replacement text added. This can also be combined into onea single operation. Highlighting is also possible and comments can be added inline.</p> <p>Formatting can also be applied to blocks by putting the opening and closing tags on separate lines and adding new lines between the tags and the content.</p> <p>Keyboard keys can be written like so:</p> <p>Ctrl+Alt+Del</p> <p>Amd inline icons/emojis can be added like this:</p> <pre><code>:fontawesome-regular-face-laugh-wink:\n:fontawesome-brands-twitter:{ .twitter }\n</code></pre> <p> </p>"},{"location":"contribute/docs/#admonitions","title":"Admonitions","text":"<p>Admonitions, also known as call-outs, are an excellent choice for including side content without significantly interrupting the document flow. Different types of admonitions are available, each with a unique icon and color. Details can be found here.</p> <p>Lorem ipsum</p> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla et euismod nulla. Curabitur feugiat, tortor non consequat finibus, justo purus auctor massa, nec semper lorem quam in massa.</p>"},{"location":"contribute/docs/#code-blocks","title":"Code blocks","text":"<p>Details can be found here.</p> <p>Simple code block with line nums and highlighted lines:</p> bubble_sort.py<pre><code>def bubble_sort(items):\n    for i in range(len(items)):\n        for j in range(len(items) - 1 - i):\n            if items[j] &gt; items[j + 1]:\n                items[j], items[j + 1] = items[j + 1], items[j]\n</code></pre> <p>Code annotations:</p> <pre><code>theme:\n  features:\n    - content.code.annotate # (1)\n</code></pre> <ol> <li> I'm a code annotation! I can contain <code>code</code>, formatted     text, images, ... basically anything that can be written in Markdown.</li> </ol>"},{"location":"contribute/docs/#tabs","title":"Tabs","text":"<p>You can use Tabs to better organize content.</p> CC++ <pre><code>#include &lt;stdio.h&gt;\n\nint main(void) {\n  printf(\"Hello world!\\n\");\n  return 0;\n}\n</code></pre> <pre><code>#include &lt;iostream&gt;\n\nint main(void) {\n  std::cout &lt;&lt; \"Hello world!\" &lt;&lt; std::endl;\n  return 0;\n}\n</code></pre>"},{"location":"contribute/docs/#tables","title":"Tables","text":"Method Description <code>GET</code>      Fetch resource <code>PUT</code>  Update resource <code>DELETE</code>      Delete resource"},{"location":"contribute/docs/#diagrams","title":"Diagrams","text":"<p>You can directly include Mermaid diagrams in your Markdown files. Details can be found here.</p> <pre><code>graph LR\n  A[Start] --&gt; B{Error?};\n  B --&gt;|Yes| C[Hmm...];\n  C --&gt; D[Debug];\n  D --&gt; B;\n  B ----&gt;|No| E[Yay!];</code></pre> <pre><code>sequenceDiagram\n  autonumber\n  Alice-&gt;&gt;John: Hello John, how are you?\n  loop Healthcheck\n      John-&gt;&gt;John: Fight against hypochondria\n  end\n  Note right of John: Rational thoughts!\n  John--&gt;&gt;Alice: Great!\n  John-&gt;&gt;Bob: How about you?\n  Bob--&gt;&gt;John: Jolly good!</code></pre>"},{"location":"contribute/overview/","title":"Overview","text":"<p>Under construction.</p>"},{"location":"faq/overview/","title":"Frequently Asked Questions (FAQ)","text":""},{"location":"faq/overview/#what-is-the-hedgehog-fabric","title":"What is the Hedgehog Fabric?","text":"<p>The Hedgehog Fabric is a topology of routers arranged in a spine-leaf architecture. A spine-leaf architecture is a type of Clos network topology. In a spine-leaf architecture, the leaves are usually placed in racks and connected directly to the servers, whereas spines are connected only to leaves. In a spine-leaf architecture, the fundamental unit of connection is a layer 3 route.</p> <p>The Hedgehog Fabric is managed via Kubernetes objects and custom resource definitions.</p>"},{"location":"faq/overview/#what-are-the-advantages-of-a-spine-leaf-architecture","title":"What are the advantages of a spine-leaf architecture?","text":"<p>A spine-leaf architecture is designed to facilitate traffic that is passing between servers inside of a data center. By contrast, other architectures like core-access-aggregation facilitate traffic moving in and out of the data center. A spine-leaf architecture provides multiple paths between nodes which allows for router maintenance and resilience in the case of failures. The spine-leaf architecture allows for multiple points of egress via border leaf nodes. In a spine-leaf architecture the unit of connection is a layer 3 route. There are robust tools, queueing algorithms and hardware available to manage network traffic at layer 3. To manage the distribution of routes to switches inside the fabric a protocol such as BGP, OSPF, or IS-IS is used. </p>"},{"location":"faq/overview/#spine-leaf-architecture-diagram","title":"Spine Leaf Architecture Diagram","text":"<p>The following diagram contains Leaf and Spine routers. Servers inside of a virtual private cloud can be attached to any leaf. To allow the servers to communicate, routes are applied to leaf nodes. The traffic passing from leaf 1 to leaf 2 can travel via any spine: the leaf uses ECMP to decide which spine to use. EVPN ensures that servers inside of a VPC are reachable at layer 2 regardless of which leaf they are attached to in the Fabric. </p> <pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n    S3([Spine 3])\n    L1([Leaf 1])\n    L2([Leaf 2])\n    L3([Leaf 3])\n    L4([Leaf 4])\n    WS1[[Worload Servers]]\n    WS2[[Worload Servers]]\n    WS3[[Worload Servers]]\n    WS4[[Worload Servers]]\n\n    S1 &amp; S2 &amp; S3 ---- L1 &amp; L2 &amp; L3 &amp; L4 \n    L1 ---- WS1\n    L2 ---- WS2\n    L3 ---- WS3\n    L4 ---- WS4\n</code></pre>"},{"location":"faq/overview/#core-access-aggregation-diagram","title":"Core Access Aggregation Diagram","text":"<p>In the diagram below, the Access switches are isolated or managed by layer-2 constructs like ACLs, bridging, and VLANs. The Aggregation routers are where layer-2 traffic is promoted to layer 3. The core routers handle layer-3 traffic only. Often some form of Spanning Tree Protocol is used to avoid loops in the layer-2 domain. Loops would cripple the network as layer 2 often relies on Broadcast/Flooding for discovery. While there are multiple paths out from the workload servers to the core they are often not passing traffic due to the Spanning Tree Protocol, these disable links are shown as dotted lines.</p> <pre><code>graph TD\n    CG1((Core Router 1))\n    CG2((Core Router 2))\n    AG1([Aggregation 1])\n    AG2([Aggregation 2])\n    AG3([Aggregation 3])\n    A1[Access 1]\n    A2[Access 2]\n    A3[Access 3]\n    WS1[[Worload Servers]]\n    WS2[[Worload Servers]]\n    WS3[[Worload Servers]]\n\n    CG1 ---- AG1 &amp; AG2 &amp; AG3\n    CG2 ---- AG1 &amp; AG2 &amp; AG3\n    AG1 ---- A1 \n    AG2 ---- A2 \n    AG3 ---- A3 \n    AG1 -..- A2 &amp; A3\n    AG2 -..- A1 &amp; A3\n    AG3 -..- A1 &amp; A2\n    A1 ---- WS1\n    A2 ---- WS2\n    A3 ---- WS3\n</code></pre>"},{"location":"faq/overview/#what-does-it-mean-to-manage-my-network-with-kubernetes","title":"What does it mean to manage my network with Kubernetes?","text":"<p>A common way to manage a network is to proceed manually via the command-line interface of the equipment, or with the hardware vendor tools. Managing a small number of switches and routers this way is workable, but cumbersome, and it only gets more painful when the network grows. Managing switches and servers with Kubernetes is similar to managing pods and applications with Kubernetes: it provides assistance for deployment, scaling, and management of the network appliances.</p> <p>For example, if the administrator of a Kubernetes cluster wants to create a new Nginx pod, they write down the YAML file describing the pod name, the container image, any ports that the pod needs exposed, and what namespace to run the pod in. After the YAML file is created, a simple <code>kubectl apply -f nginx.yaml</code> is all that the administrator needs to run in order for the pod to be scheduled. </p> <p>With the Hedgehog Fabric, the same principles apply to managing network resources. Administrators create a YAML file to configure a VPC. The YAML file describes the IP address range for the private cloud, for example the <code>192.168.0.0/16</code> space. It also describes any VLANs that the private cloud needs. After the desired options are in the file, administrators can push the configuration to the switch with a mere <code>kubectl apply -f vpc1.yaml</code>, and within a few seconds the switch configuration is live.</p>"},{"location":"faq/overview/#what-is-a-virtual-private-cloud-vpc","title":"What is a Virtual Private Cloud (VPC)?","text":"<p>A VPC provides layer 3 logical isolation inside of a network. To isolate the servers, a VRF is used. A VRF allows for multiple routing tables to exist at the same time on a switch. Each VPC is isolated from the others because there is simply no route between them.</p>"},{"location":"getting-started/download/","title":"Download","text":"<p>The main entry point for the software is the Hedgehog Fabricator CLI named <code>hhfab</code>. It is a command-line tool that allows to build installer for the Hedgehog Fabric, upgrade the existing installation, or run the Virtual LAB.</p>"},{"location":"getting-started/download/#getting-access","title":"Getting access","text":"<p>Prior to General Availability, access to the full software is limited and requires Design Partner Agreement. Please submit a ticket with the request using Hedgehog Support Portal.</p> <p>After that you will be provided with the credentials to access the software on GitHub Package. In order to use the software, log in to the registry using the following command:</p> <pre><code>docker login ghcr.io --username provided_user_name --password provided_token_string\n</code></pre>"},{"location":"getting-started/download/#downloading-hhfab","title":"Downloading hhfab","text":"<p>Currently <code>hhfab</code> is supported on Linux x86/arm64 (tested on Ubuntu 22.04) and MacOS x86/arm64 for building installers/upgraders. It may work on Windows WSL2 (with Ubuntu), but it's not tested. For running VLAB only Linux x86 is currently supported.</p> <p>All software is published into the OCI registry GitHub Package including binaries, container images, or Helm charts. Download the latest stable <code>hhfab</code> binary from the GitHub Package using the following command, it requires ORAS to be installed (see below):</p> <pre><code>curl -fsSL https://i.hhdev.io/hhfab | bash\n</code></pre> <p>Or download a specific version (e.g. beta-1) using the following command:</p> <pre><code>curl -fsSL https://i.hhdev.io/hhfab | VERSION=beta-1 bash\n</code></pre> <p>Use the <code>VERSION</code> environment variable to specify the version of the software to download. By default, the latest stable release is downloaded. You can pick a specific release series (e.g. <code>alpha-2</code>) or a specific release.</p>"},{"location":"getting-started/download/#installing-oras","title":"Installing ORAS","text":"<p>The download script requires ORAS to be installed. ORAS is used to download the binary from the OCI registry and can be installed using following command:</p> <pre><code>curl -fsSL https://i.hhdev.io/oras | bash\n</code></pre>"},{"location":"getting-started/download/#next-steps","title":"Next steps","text":"<ul> <li>Concepts</li> <li>Virtual LAB</li> <li>Installation</li> <li>User guide</li> </ul>"},{"location":"install-upgrade/build-wiring/","title":"Build Wiring Diagram","text":"<p>Under construction.</p>"},{"location":"install-upgrade/build-wiring/#overview","title":"Overview","text":"<p>A wiring diagram is a YAML file that is a digital representation of your network. You can find more YAML level details in the User Guide section switch features and port naming and the api. It's mandatory for all switches to reference a <code>SwitchProfile</code> in the <code>spec.profile</code> of the <code>Switch</code> object. Only port naming defined by switch profiles could be used in the wiring diagram, NOS (or any other) port names aren't supported.</p> <p>In the meantime, to have a look at working wiring diagram for Hedgehog Fabric, run the sample generator that produces working wiring diagrams:</p> <pre><code>ubuntu@sl-dev:~$ hhfab sample -h\n\nNAME:\n   hhfab sample - generate sample wiring diagram\n\nUSAGE:\n   hhfab sample command [command options]\n\nCOMMANDS:\n   spine-leaf, sl      generate sample spine-leaf wiring diagram\n   collapsed-core, cc  generate sample collapsed-core wiring diagram\n   help, h             Shows a list of commands or help for one command\n\nOPTIONS:\n   --help, -h  show help\n</code></pre> <p>Or you can generate a wiring diagram for a VLAB environment with flags to customize number of switches, links, servers, etc.:</p> <pre><code>ubuntu@sl-dev:~$ hhfab vlab gen --help\nNAME:\n   hhfab vlab generate - generate VLAB wiring diagram\n\nUSAGE:\n   hhfab vlab generate [command options]\n\nOPTIONS:\n   --bundled-servers value      number of bundled servers to generate for switches (only for one of the second switch in the redundancy group or orphan switch) (default: 1)\n   --eslag-leaf-groups value    eslag leaf groups (comma separated list of number of ESLAG switches in each group, should be 2-4 per group, e.g. 2,4,2 for 3 groups with 2, 4 and 2 switches)\n   --eslag-servers value        number of ESLAG servers to generate for ESLAG switches (default: 2)\n   --fabric-links-count value   number of fabric links if fabric mode is spine-leaf (default: 0)\n   --help, -h                   show help\n   --mclag-leafs-count value    number of mclag leafs (should be even) (default: 0)\n   --mclag-peer-links value     number of mclag peer links for each mclag leaf (default: 0)\n   --mclag-servers value        number of MCLAG servers to generate for MCLAG switches (default: 2)\n   --mclag-session-links value  number of mclag session links for each mclag leaf (default: 0)\n   --no-switches                do not generate any switches (default: false)\n   --orphan-leafs-count value   number of orphan leafs (default: 0)\n   --spines-count value         number of spines if fabric mode is spine-leaf (default: 0)\n   --unbundled-servers value    number of unbundled servers to generate for switches (only for one of the first switch in the redundancy group or orphan switch) (default: 1)\n   --vpc-loopbacks value        number of vpc loopbacks for each switch (default: 0)\n</code></pre>"},{"location":"install-upgrade/build-wiring/#sample-switch-configuration","title":"Sample Switch Configuration","text":"<pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Switch\nmetadata:\n  name: ds3000-02\nspec:\n  boot:\n    serial: ABC123XYZ\n  role: server-leaf\n  description: leaf-2\n  profile: celestica-ds3000\n  portBreakouts:\n    E1/1: 4x10G\n    E1/2: 4x10G\n    E1/17: 4x25G\n    E1/18: 4x25G\n    E1/32: 4x25G\n  redundancy:\n    group: mclag-1\n    type: mclag\n</code></pre>"},{"location":"install-upgrade/build-wiring/#design-discussion","title":"Design Discussion","text":"<p>This section is meant to help the reader understand how to assemble the primitives presented by the Fabric API into a functional fabric.</p>"},{"location":"install-upgrade/build-wiring/#vpc","title":"VPC","text":"<p>A VPC allows for isolation at layer 3. This is the main building block for users when creating their architecture. Hosts inside of a VPC belong to the same broadcast domain and can communicate with each other, if desired a single VPC can be configured with multiple broadcast domains. The hosts inside of a VPC will likely need to connect to other VPCs or the outside world. To communicate between two VPC a peering will need to be created. A VPC can be a logical separation of workloads. By separating these workloads additional controls are available. The logical separation doesn't have to be the traditional database, web, and compute layers it could be development teams who need isolation, it could be tenants inside of an office building, or any separation that allows for better control of the network. Once your VPCs are decided, the rest of the fabric will come together. With the VPCs decided traffic can be prioritized, security can be put into place, and the wiring can begin. The fabric allows for the VPC to span more than one switch, which provides great flexibility.</p> <pre><code>graph TD\n    L1([Leaf 1])\n    L2([Leaf 2])\n    S1[\"Server 1\n      10.7.71.1\"]\n    S2[\"Server 2\n      172.16.2.31\"]\n    S3[\"Server 3\n       192.168.18.85\"]\n\n    L1 &lt;--&gt; S1\n    L1 &lt;--&gt; S2\n    L2 &lt;--&gt; S3\n\n    subgraph VPC 1\n    S1\n    S2\n    S3\n    end</code></pre>"},{"location":"install-upgrade/build-wiring/#connection","title":"Connection","text":"<p>A connection represents the physical wires in your data center. They connect switches to other switches or switches to servers.</p>"},{"location":"install-upgrade/build-wiring/#server-connections","title":"Server Connections","text":"<p>A server connection is a connection used to connect servers to the fabric. The fabric will configure the server-facing port according to the type of the connection (MLAG, Bundle, etc). The configuration of the actual server needs to be done by the server administrator. The server port names are not validated by the fabric and used as metadata to identify the connection. A server connection can be one of:</p> <ul> <li>Unbundled - A single cable connecting switch to server.</li> <li>Bundled - Two or more cables going to a single switch, a LAG or similar.</li> <li>MCLAG -  Two cables going to two different switches, also called dual homing. The switches will need a fabric link between them.</li> <li>ESLAG - Two to four cables going to different switches, also called multi-homing. If four links are used there will need to be four switches connected to a single server with four NIC ports.</li> </ul> <pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n    L1([Leaf 1])\n    L2([Leaf 2])\n    L3([Leaf 3])\n    L4([Leaf 4])\n    L5([Leaf 5])\n    L6([Leaf 6])\n    L7([Leaf 7])\n\n    TS1[Server1]\n    TS2[Server2]\n    TS3[Server3]\n    TS4[Server4]\n\n    S1 &amp; S2 ---- L1 &amp; L2 &amp; L3 &amp; L4 &amp; L5 &amp; L6 &amp; L7\n    L1 &lt;-- Bundled --&gt; TS1\n    L1 &lt;-- Bundled --&gt; TS1\n    L1 &lt;-- Unbundled --&gt; TS2\n    L2 &lt;-- MCLAG --&gt; TS3\n    L3 &lt;-- MCLAG --&gt; TS3\n    L4 &lt;-- ESLAG --&gt; TS4\n    L5 &lt;-- ESLAG --&gt; TS4\n    L6 &lt;-- ESLAG --&gt; TS4\n    L7 &lt;-- ESLAG --&gt; TS4\n\n    subgraph VPC 1\n    TS1\n    TS2\n    TS3\n    TS4\n    end\n\n    subgraph MCLAG\n    L2\n    L3\n    end\n\n    subgraph ESLAG\n    L3\n    L4\n    L5\n    L6\n    L7\n    end\n</code></pre>"},{"location":"install-upgrade/build-wiring/#fabric-connections","title":"Fabric Connections","text":"<p>Fabric connections serve as connections between switches, they form the fabric of the network.</p>"},{"location":"install-upgrade/build-wiring/#vpc-peering","title":"VPC Peering","text":"<p>VPCs need VPC Peerings to talk to each other. VPC Peerings come in two varieties: local and remote.</p> <pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n    L1([Leaf 1])\n    L2([Leaf 2])\n    TS1[Server1]\n    TS2[Server2]\n    TS3[Server3]\n    TS4[Server4]\n\n    S1 &amp; S2 &lt;--&gt; L1 &amp; L2\n    L1 &lt;--&gt; TS1 &amp; TS2\n    L2 &lt;--&gt; TS3 &amp; TS4\n\n\n    subgraph VPC 1\n    TS1\n    TS2\n    end\n\n    subgraph VPC 2\n    TS3\n    TS4\n    end</code></pre>"},{"location":"install-upgrade/build-wiring/#local-vpc-peering","title":"Local VPC Peering","text":"<p>When there is no dedicated border/peering switch available in the fabric we can use local VPC peering. This kind of peering tries sends traffic between the two VPC's on the switch where either of the VPC's has workloads attached. Due to limitation in the Sonic network operating system this kind of peering bandwidth is limited to the number of VPC loopbacks you have selected while initializing the fabric. Traffic between the VPCs will use the loopback interface, the bandwidth of this connection will be equal to the bandwidth of port used in the loopback.</p> <p><pre><code>graph TD\n\n    L1([Leaf 1])\n    S1[Server1]\n    S2[Server2]\n    S3[Server3]\n    S4[Server4]\n\n    L1 &lt;-.2,loopback.-&gt; L1;\n    L1 &lt;-.3.-&gt; S1;\n    L1 &lt;--&gt; S2 &amp; S4;\n    L1 &lt;-.1.-&gt; S3;\n\n    subgraph VPC 1\n    S1\n    S2\n    end\n\n    subgraph VPC 2\n    S3\n    S4\n    end</code></pre> The dotted line in the diagram shows the traffic flow for local peering. The traffic originates in VPC 2, travels to the switch, travels out the first loopback port, into the second loopback port, and finally out the port destined for VPC 1.</p>"},{"location":"install-upgrade/build-wiring/#remote-vpc-peering","title":"Remote VPC Peering","text":"<p>Remote Peering is used when you need a high bandwidth connection between the VPCs, you will dedicate a switch to the peering traffic. This is either done on the border leaf or on a switch where either of the VPC's are not present. This kind of peering allows peer traffic between different VPC's at line rate and is only limited by fabric bandwidth. Remote peering introduces a few additional hops in the traffic and may cause a small increase in latency.</p> <p><pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n    L1([Leaf 1])\n    L2([Leaf 2])\n    L3([Leaf 3])\n    TS1[Server1]\n    TS2[Server2]\n    TS3[Server3]\n    TS4[Server4]\n\n    S1 &lt;-.5.-&gt; L1;\n    S1 &lt;-.2.-&gt; L2;\n    S1 &lt;-.3,4.-&gt; L3;\n    S2 &lt;--&gt; L1;\n    S2 &lt;--&gt; L2;\n    S2 &lt;--&gt; L3;\n    L1 &lt;-.6.-&gt; TS1;\n    L1 &lt;--&gt; TS2;\n    L2 &lt;--&gt; TS3;\n    L2 &lt;-.1.-&gt; TS4;\n\n\n    subgraph VPC 1\n    TS1\n    TS2\n    end\n\n    subgraph VPC 2\n    TS3\n    TS4\n    end</code></pre> The dotted line in the diagram shows the traffic flow for remote peering. The traffic could take a different path because of ECMP. It is important to note that Leaf 3 cannot have any servers from VPC 1 or VPC 2 on it, but it can have a  different VPC attached to it.</p>"},{"location":"install-upgrade/build-wiring/#vpc-loopback","title":"VPC Loopback","text":"<p>A VPC loopback is a physical cable with both ends plugged into the same switch, suggested but not required to be the adjacent ports. This loopback allows two different VPCs to communicate with each other. This is due to a Broadcom limitation.</p>"},{"location":"install-upgrade/config/","title":"Fabric Configuration","text":""},{"location":"install-upgrade/config/#overview","title":"Overview","text":"<p>The <code>fab.yaml</code> file is the configuration file for the fabric. It supplies the configuration of the users, their credentials, logging, telemetry, and other non wiring related settings. The <code>fab.yaml</code> file is composed of multiple YAML documents inside of a single file. Per the YAML spec 3 hyphens (<code>---</code>) on a single line separate the end of one document from the beginning of the next. There are two YAML documents in the <code>fab.yaml</code> file. For more information about how to use <code>hhfab init</code>, run <code>hhfab init --help</code>.</p>"},{"location":"install-upgrade/config/#typical-hhfab-workflows","title":"Typical HHFAB workflows","text":""},{"location":"install-upgrade/config/#hhfab-for-vlab","title":"HHFAB for VLAB","text":"<p>For a VLAB user, the typical workflow with hhfab is:</p> <ol> <li><code>hhfab init --dev</code></li> <li><code>hhfab vlab gen</code></li> <li><code>hhfab vlab up</code></li> </ol> <p>The above workflow will get a user up and running with a spine-leaf VLAB.</p>"},{"location":"install-upgrade/config/#hhfab-for-physical-machines","title":"HHFAB for Physical Machines","text":"<p>It's possible to start from scratch:</p> <ol> <li><code>hhfab init</code> (see different flags to cusomize initial configuration)</li> <li>Adjust the <code>fab.yaml</code> file to your needs</li> <li><code>hhfab validate</code></li> <li><code>hhfab build</code></li> </ol> <p>Or import existing config and wiring files:</p> <ol> <li><code>hhfab init -c fab.yaml -w wiring-file.yaml -w extra-wiring-file.yaml</code></li> <li><code>hhfab validate</code></li> <li><code>hhfab build</code></li> </ol> <p>After the above workflow a user will have a .img file suitable for installing the control node, then bringing up the switches which comprise the fabric.</p>"},{"location":"install-upgrade/config/#fabyaml","title":"Fab.yaml","text":""},{"location":"install-upgrade/config/#configure-control-node-and-switch-users","title":"Configure control node and switch users","text":"<p>Configuring control node and switch users is done either passing <code>--default-password-hash</code> to <code>hhfab init</code> or editing the resulting <code>fab.yaml</code> file emitted by <code>hhfab init</code>. You can specify users to be configured on the control node(s) and switches in the following format:</p> <pre><code>spec:\n    config:\n      control:\n        defaultUser: # user 'core' on all control nodes\n          password: \"hashhashhashhashhash\" # password hash\n          authorizedKeys:\n            - \"ssh-ed25519 SecREKeyJumblE\"\n\n        fabric:\n          mode: spine-leaf # \"spine-leaf\" or \"collapsed-core\"\n\n          defaultSwitchUsers:\n            admin: # at least one user with name 'admin' and role 'admin'\n              role: admin\n              #password: \"$5$8nAYPGcl4...\" # password hash\n              #authorizedKeys: # optional SSH authorized keys\n              #  - \"ssh-ed25519 AAAAC3Nza...\"\n            op: # optional read-only user\n              role: operator\n              #password: \"$5$8nAYPGcl4...\" # password hash\n              #authorizedKeys: # optional SSH authorized keys\n              #  - \"ssh-ed25519 AAAAC3Nza...\"\n</code></pre> <p>Control node(s) user is always named <code>core</code>.</p> <p>The role of the user,<code>operator</code> is read-only access to <code>sonic-cli</code> command on the switches. In order to avoid conflicts, do not use the following usernames: <code>operator</code>,<code>hhagent</code>,<code>netops</code>.</p>"},{"location":"install-upgrade/config/#ntp-and-dhcp","title":"NTP and DHCP","text":"<p>The control node uses public ntp servers from cloudflare and google by default. The control node runs a dhcp server on the management network. See the example file.</p>"},{"location":"install-upgrade/config/#control-node","title":"Control Node","text":"<p>The control node is the host that manages all the switches, runs k3s, and serves images. This is the YAML document configure the control node: <pre><code>apiVersion: fabricator.githedgehog.com/v1beta1\nkind: ControlNode\nmetadata:\n  name: control-1\n  namespace: fab\nspec:\n  bootstrap:\n   disk: \"/dev/sda\" # disk to install OS on, e.g. \"sda\" or \"nvme0n1\"\n  external:\n    interface: enp2s0 # interface for external\n    ip: dhcp # IP address for external interface\n  management:\n    interface: enp2s1 # interface for management\n\n# Currently only one ControlNode is supported\n</code></pre> The management interface is for the control node to manage the fabric switches, not end-user management of the control node. For end-user management of the control node specify the external interface name.</p>"},{"location":"install-upgrade/config/#forward-switch-metrics-and-logs","title":"Forward switch metrics and logs","text":"<p>There is an option to enable Grafana Alloy on all switches to forward metrics and logs to the configured targets using Prometheus Remote-Write API and Loki API. If those APIs are available from Control Node(s), but not from the switches, it's possible to enable HTTP Proxy on Control Node(s) that will be used by Grafana Alloy running on the switches to access the configured targets. It could be done by passing <code>--control-proxy=true</code> to <code>hhfab init</code>.</p> <p>Metrics includes port speeds, counters, errors, operational status, transceivers, fans, power supplies, temperature sensors, BGP neighbors, LLDP neighbors, and more. Logs include agent logs.</p> <p>Configuring the exporters and targets is currently only possible by editing the <code>fab.yaml</code> configuration file. An example configuration is provided below:</p> <pre><code>spec:\n  config:\n      ...\n      defaultAlloyConfig:\n        agentScrapeIntervalSeconds: 120\n        unixScrapeIntervalSeconds: 120\n        unixExporterEnabled: true\n        lokiTargets:\n          grafana_cloud: # target name, multiple targets can be configured\n              basicAuth: # optional\n                  password: \"&lt;password&gt;\"\n                  username: \"&lt;username&gt;\"\n              labels: # labels to be added to all logs\n                  env: env-1\n              url: https://logs-prod-021.grafana.net/loki/api/v1/push\n              useControlProxy: true # if the Loki API is not available from the switches directly, use the Control Node as a proxy\n        prometheusTargets:\n          grafana_cloud: # target name, multiple targets can be configured\n              basicAuth: # optional\n                  password: \"&lt;password&gt;\"\n                  username: \"&lt;username&gt;\"\n              labels: # labels to be added to all metrics\n                  env: env-1\n              sendIntervalSeconds: 120\n              url: https://prometheus-prod-36-prod-us-west-0.grafana.net/api/prom/push\n              useControlProxy: true # if the Loki API is not available from the switches directly, use the Control Node as a proxy\n              unixExporterCollectors: # list of node-exporter collectors to enable, https://grafana.com/docs/alloy/latest/reference/components/prometheus.exporter.unix/#collectors-list\n                  - cpu\n                  - filesystem\n                  - loadavg\n                  - meminfo\n              collectSyslogEnabled: true # collect /var/log/syslog on switches and forward to the lokiTargets\n</code></pre> <p>For additional options, see the <code>AlloyConfig</code> struct in Fabric repo.</p>"},{"location":"install-upgrade/config/#complete-example-file","title":"Complete Example File","text":"<pre><code>apiVersion: fabricator.githedgehog.com/v1beta1\nkind: Fabricator\nmetadata:\n  name: default\n  namespace: fab\nspec:\n  config:\n    control:\n      tlsSAN: # IPs and DNS names to access API\n        - \"customer.site.io\"\n\n      ntpServers:\n      - time.cloudflare.com\n      - time1.google.com\n\n      defaultUser: # user 'core' on all control nodes\n        password: \"hash...\" # password hash\n        authorizedKeys:\n          - \"ssh-ed25519 hash...\"\n\n    fabric:\n      mode: spine-leaf # \"spine-leaf\" or \"collapsed-core\"\n      includeONIE: true\n      defaultSwitchUsers:\n        admin: # at least one user with name 'admin' and role 'admin'\n          role: admin\n          password: \"hash...\" # password hash\n          authorizedKeys:\n            - \"ssh-ed25519 hash...\"\n        op: # optional read-only user\n          role: operator\n          password: \"hash...\" # password hash\n          authorizedKeys:\n            - \"ssh-ed25519 hash...\"\n\n      defaultAlloyConfig:\n        agentScrapeIntervalSeconds: 120\n        unixScrapeIntervalSeconds: 120\n        unixExporterEnabled: true\n        collectSyslogEnabled: true\n        lokiTargets:\n          lab:\n            url: http://url.io:3100/loki/api/v1/push\n            useControlProxy: true\n            labels:\n              descriptive: name\n        prometheusTargets:\n          lab:\n            url: http://url.io:9100/api/v1/push\n            useControlProxy: true\n            labels:\n              descriptive: name\n            sendIntervalSeconds: 120\n\n---\napiVersion: fabricator.githedgehog.com/v1beta1\nkind: ControlNode\nmetadata:\n  name: control-1\n  namespace: fab\nspec:\n  bootstrap:\n    disk: \"/dev/sda\" # disk to install OS on, e.g. \"sda\" or \"nvme0n1\"\n  external:\n    interface: eno2 # interface for external\n    ip: dhcp # IP address for external interface\n  management:\n    interface: eno1\n\n# Currently only one ControlNode is supported\n</code></pre>"},{"location":"install-upgrade/install/","title":"Install Fabric","text":""},{"location":"install-upgrade/install/#prerequisites","title":"Prerequisites","text":"<ul> <li>A machine with access to the Internet to use Fabricator and build installer with at least 8 GB RAM and 25 GB of disk space</li> <li>An 16 GB USB flash drive, if you are not using virtual media</li> <li>Have a machine to function as the Fabric Control Node. System Requirements as well as IPMI access to it to install   the OS.</li> <li>A management switch with at least 1 10GbE port is recommended</li> <li>Enough Supported Switches for your Fabric</li> </ul>"},{"location":"install-upgrade/install/#overview-of-install-process","title":"Overview of Install Process","text":"<p>This section is dedicated to the Hedgehog Fabric installation on bare-metal control node(s) and switches, their preparation and configuration. To install the VLAB see VLAB Overview.</p> <p>Download and install <code>hhfab</code> following instructions from the Download section.</p> <p>The main steps to install Fabric are:</p> <ol> <li>Install <code>hhfab</code> on the machines with access to the Internet<ol> <li>Prepare Wiring Diagram</li> <li>Select Fabric Configuration</li> <li>Build Control Node configuration and installer</li> </ol> </li> <li>Install Control Node<ol> <li>Insert USB with control-os image into Fabric Control Node</li> <li>Boot the node off the USB to initiate the installation</li> </ol> </li> <li>Prepare Management Network<ol> <li>Connect management switch to Fabric control node</li> <li>Connect 1GbE Management port of switches to management switch</li> </ol> </li> <li>Prepare supported switches<ol> <li>Ensure switch serial numbers and / or first management interface MAC addresses are recorded in wiring diagram</li> <li>Boot them into ONIE Install Mode to have them automatically provisioned</li> </ol> </li> </ol>"},{"location":"install-upgrade/install/#build-control-node-configuration-and-installer","title":"Build Control Node configuration and Installer","text":"<p>Hedgehog has created a command line utility, called <code>hhfab</code>, that helps generate the wiring diagram and fabric configuration, validate the supplied configurations, and generate an installation image (.img or .iso) suitable  for writing to a USB flash drive or mounting via IPMI virtual media. The first <code>hhfab</code> command to run is <code>hhfab init</code>. This will generate the main configuration file, <code>fab.yaml</code>. <code>fab.yaml</code> is  responsible for almost every configuration of the fabric with the exception of the wiring. Each  command and subcommand have usage messages, simply supply the <code>-h</code> flag to your command or sub  command to see the available options. For example <code>hhfab vlab -h</code> and <code>hhfab vlab gen -h</code>.</p>"},{"location":"install-upgrade/install/#hhfab-commands-to-make-a-bootable-image","title":"HHFAB commands to make a bootable image","text":"<ol> <li><code>hhfab init --wiring wiring-lab.yaml</code></li> <li>The <code>init</code> command generates a <code>fab.yaml</code> file, edit the <code>fab.yaml</code> file for your needs<ol> <li>ensure the correct boot disk (e.g. <code>/dev/sda</code>) and control node NIC names are supplied</li> </ol> </li> <li><code>hhfab validate</code></li> <li><code>hhfab build --mode iso</code><ol> <li>An ISO is best suited to use with IPMI based virtual media. If desired an IMG file suitable for writing to a USB drive, can be created by passing the <code>--mode usb</code> option. ISO is the default.</li> </ol> </li> </ol> <p>The installer for the fabric is generated in <code>$CWD/result/</code>. This installation image is named <code>control-1-install-usb.iso</code> and is 7.5 GB in size. Once the image is created, you can write it to a USB drive, or mount it via virtual media.</p>"},{"location":"install-upgrade/install/#write-usb-image-to-disk","title":"Write USB Image to Disk","text":"<p>This will erase data on the USB disk.</p>"},{"location":"install-upgrade/install/#steps-for-linux","title":"Steps for Linux","text":"<ol> <li>Insert the USB to your machine</li> <li>Identify the path to your USB stick, for example: <code>/dev/sdc</code></li> <li>Issue the command to write the image to the USB drive<ul> <li><code>sudo dd if=control-1-install-usb.img of=/dev/sdc bs=4k status=progress</code></li> </ul> </li> </ol>"},{"location":"install-upgrade/install/#steps-for-macos","title":"Steps for MacOS","text":"<ol> <li>Plug the drive into the computer</li> <li>Open the terminal</li> <li>Identify the drive using <code>diskutil list</code></li> <li>Unmount the disk <code>diskutil unmount disk5</code>, the disk is specific to your environment</li> <li>Write the image to the disk: <code>sudo dd if=./control-1-install-usb.img of=/dev/disk5 bs=4k status=progress</code></li> </ol> <p>There are utilities that assist this process such as etcher.</p>"},{"location":"install-upgrade/install/#install-control-node","title":"Install Control Node","text":"<p>This control node should be given a static IP address. Either a lease or statically assigned.</p> <ol> <li> <p>Configure the server to use UEFI boot without secure boot</p> </li> <li> <p>Attach the image to the server either by inserting via USB, or attaching via virtual media</p> </li> <li> <p>Select boot off of the attached media, the installation process is automated</p> </li> <li> <p>Once the control node has booted, it logs in automatically and begins the installation process</p> <ol> <li>Optionally use <code>journalctl -f -u flatcar-install.service</code> to monitor progress</li> </ol> </li> <li> <p>Once the installation is complete, the system automatically reboots.</p> </li> <li> <p>After the system has shutdown but before the boot up process reaches the operating system, remove the USB image from the system. Removal during the UEFI boot screen is acceptable.</p> </li> <li> <p>Upon booting into the freshly installed system, the fabric installation will automatically begin</p> <ol> <li>If the insecure <code>--dev</code> flag was passed to <code>hhfab init</code> the password for the <code>core</code> user is <code>HHFab.Admin!</code>, the switches have two users created <code>admin</code> and <code>op</code>. <code>admin</code> has administrator privileges and password <code>HHFab.Admin!</code>, whereas the <code>op</code> user is a read-only, non-sudo user with password <code>HHFab.Op!</code>.</li> <li>Optionally this can be monitored with <code>journalctl -f -u fabric-install.service</code></li> </ol> </li> <li> <p>The install is complete when the log emits \"Control Node installation complete\". Additionally, the systemctl status will show <code>inactive (dead)</code> indicating that the executable has finished.</p> </li> </ol>"},{"location":"install-upgrade/install/#configure-management-network","title":"Configure Management Network","text":"<p>The control node is dual-homed: it connects to two different networks, which are called <code>management</code> and <code>external</code>, respectively, in the <code>fab.yaml</code> file. The <code>management</code> network is for controlling the switches that comprise the fabric. It can be a simple broadcast domain with layer 2 connectivity. The management network is not accessible to machines or devices not associated with the fabric; it is a private, exclusive network. The control node connects to the management network via a 10 GbE interface. It runs a DHCP server, as well as a small HTTP server.</p> <p>The <code>external</code> network allows the user to access the control node via their local IT network. It provides SSH access to the host operating system on the control node.</p>"},{"location":"install-upgrade/install/#fabric-manages-switches","title":"Fabric Manages Switches","text":"<p>Now that the install has finished, you can start interacting with the Fabric using <code>kubectl</code>, <code>kubectl fabric</code> and <code>k9s</code>, all pre-installed as part of the Control Node installer.</p> <p>At this stage, the fabric hands out DHCP addresses to the switches via the management network. Optionally, you can monitor this process by going through the following steps: - enter <code>k9s</code> at the command prompt - use the arrow keys to select the pod named <code>fabric-boot</code> - the logs of the pod will be displayed showing the DHCP lease process - use the switches screen of <code>k9s</code> to see the heartbeat column to verify the connection between switch and controller.     - to see the switches type <code>:switches</code> (like a vim command) into <code>k9s</code></p>"},{"location":"install-upgrade/requirements/","title":"System Requirements","text":""},{"location":"install-upgrade/requirements/#out-of-band-management-network","title":"Out of Band Management Network","text":"<p>In order to provision and manage the switches that comprise the fabric, an out of band switch must also be installed. This network is to be used exclusively by the control node and the fabric switches, no other access is permitted. This switch (or switches) is not managed by the fabric. It is recommended that this switch have at least a 10GbE port and that port connect to the control node.</p>"},{"location":"install-upgrade/requirements/#control-node","title":"Control Node","text":"<ul> <li>Fast SSDs for system/root is mandatory for Control Nodes<ul> <li>NVMe SSDs are recommended</li> <li>DRAM-less NAND SSDs are not supported (e.g. Crucial BX500)</li> </ul> </li> <li>10 GbE port for connection to management network is recommended</li> <li>Minimal (non-HA) setup is a single Control Node</li> <li>(Future) Full (HA) setup is at least 3 Control Nodes</li> <li>(Future) Extra nodes could be used for things like Logging, Monitoring, Alerting stack, and more</li> </ul> <p>In internal testing Hedgehog uses a server with the following specifications:</p> <ul> <li>CPU - AMD EPYC 4344P </li> <li>Memory - 32 GiB DDR5 ECC 4800MT/s</li> <li>Storage - PCIe Gen 4 NVMe M.2 400GB</li> <li>Network - AOC-STG-i4S Intel X710-BM1 controller</li> <li>Motherboard - H13SAE-MF</li> </ul>"},{"location":"install-upgrade/requirements/#non-ha-minimal-setup-1-control-node","title":"Non-HA (minimal) setup - 1 Control Node","text":"<ul> <li>Control Node runs non-HA Kubernetes Control Plane installation with non-HA Hedgehog Fabric Control Plane on top of it</li> <li>Not recommended for more then 10 devices participating in the Hedgehog Fabric or production deployments</li> </ul> Minimal Recommended CPU 6 8 RAM 16 GB 32 GB Disk 150 GB 250 GB"},{"location":"install-upgrade/requirements/#future-ha-setup-3-control-nodes-per-node","title":"(Future) HA setup - 3+ Control Nodes (per node)","text":"<ul> <li>Each Control Node runs part of the HA Kubernetes Control Plane installation with Hedgehog Fabric Control Plane on top   of it in HA mode as well</li> <li>Recommended for all cases where more than 10 devices participating in the Hedgehog Fabric</li> </ul> Minimal Recommended CPU 6 8 RAM 16 GB 32 GB Disk 150 GB 250 GB"},{"location":"install-upgrade/requirements/#reference-control-node-configuration","title":"Reference Control Node Configuration","text":"<ul> <li>AMD EPYC 4344P (8C/16T, 3.8 GHz, 32 MB L3, 65W, single socket)</li> <li>32 GB DDR5-4800 ECC UDIMM (2 x 16 GB)</li> <li>Micron 7450 MAX 400GB NVMe</li> </ul>"},{"location":"install-upgrade/requirements/#device-participating-in-the-hedgehog-fabric-eg-switch","title":"Device participating in the Hedgehog Fabric (e.g. switch)","text":"<ul> <li>(Future) Each participating device is part of the Kubernetes cluster, so it runs Kubernetes kubelet</li> <li>Additionally, it runs the Hedgehog Fabric Agent that controls devices configuration</li> </ul> <p>Following resources should be available on a device to run in the Hedgehog Fabric (after other software such as SONiC usage):</p> Minimal Recommended CPU 1 2 RAM 1 GB 1.5 GB Disk 5 GB 10 GB"},{"location":"install-upgrade/supported-devices/","title":"Supported Devices","text":"<p>You can find detailed information about devices in the Switch Profiles Catalog and in the User Guide switch features and port naming.</p>"},{"location":"install-upgrade/supported-devices/#spine","title":"Spine","text":"<ul> <li>Celestica DS3000</li> <li>Celestica DS4000</li> <li>Dell S5232F-ON</li> <li>Dell Z9332F-ON</li> <li>Edgecore DCS204 (AS7726-32X)</li> <li>Edgecore DCS501 (AS7712-32X-EC)</li> <li>Supermicro SSE-C4632SB</li> </ul>"},{"location":"install-upgrade/supported-devices/#leaf","title":"Leaf","text":"<p>(could be used for collapsed-core)</p> <ul> <li>Celestica DS3000</li> <li>Dell S5232F-ON</li> <li>Dell S5248F-ON</li> <li>Edgecore DCS203 (AS7326-56X)</li> <li>Edgecore DCS204 (AS7726-32X)</li> <li>Edgecore EPS203 (AS4630-54NPE)</li> <li>Supermicro SSE-C4632SB</li> </ul>"},{"location":"install-upgrade/upgrade/","title":"Upgrade","text":""},{"location":"install-upgrade/upgrade/#upgrades-from-beta-1-onwards","title":"Upgrades from Beta-1 onwards","text":"<p>Starting with Beta-1 release and onwards, the upgrade process is more streamlined and fully automated. The control node is upgraded in place and the agents/switches is upgraded using the control node.</p> <p>In order to apply the upgrade, the following steps need to be followed:</p> <ul> <li>use the <code>hhfab</code> directory from the initial deployment or init the new one using the configs from the running installation</li> <li>run <code>hhfab build --mode=manual</code> to generate fully self-contained (airgap) upgrade package</li> <li>for control node named <code>control-1</code> it will be <code>result/control-1-install.tgz</code></li> <li>upload it to the control node (e.g. using <code>scp</code>)</li> <li>unpack and run <code>hhfab-recipe control upgrade</code> from the resulting directory</li> </ul> <pre><code>tar xzf control-1-install.tgz\ncd control-1-install\n./hhfab-recipe control upgrade\n</code></pre> <p>It'll do all necessary steps to upgrade the control node and the agents/switches. Resulting version could be checked using <code>kubectl -n fab get fab/default -o=jsonpath='{.status.versions.fabricator.controller}'</code> and compare to the fabricator version in the release notes.</p> <p>Upgrade process is idempotent and can be run multiple times without any issues.</p>"},{"location":"install-upgrade/upgrade/#init-hhfab-dir-from-the-running-installation","title":"Init hhfab dir from the running installation","text":"<p>If the original <code>hhfab</code> directory is no longer available, it is possible to export the current configuration from the running installation and init the new <code>hhfab</code> directory with it.</p> <pre><code># on a control node\nkubectl hhfab config export &gt; fab.yaml\n\n# on a node with internet access using the exported config\nhhfab init -c fab.yaml\n</code></pre>"},{"location":"install-upgrade/upgrade/#upgrade-from-alpha-7-to-beta-1","title":"Upgrade from Alpha-7 to Beta-1","text":""},{"location":"install-upgrade/upgrade/#control-node","title":"Control Node","text":"<p>Ensure the hardware that is to be used for the control node meets the system requirements. The upgrade process is destructive of the host, so ensure all data needed is removed from the selected server before the upgrade is started.</p>"},{"location":"install-upgrade/upgrade/#management-network","title":"Management Network","text":"<p>Beta-1 uses the RJ-45 management ports of the switches instead of front panel ports. A simple management network will need to be in place and cabled before the install of Beta-1. The control node will run a DHCP server on this network and must be the sole DHCP server. Do not co-mingle other services or equipment on this network, it is for the exclusive use of the control node and switches.</p>"},{"location":"install-upgrade/upgrade/#install-switch-vendor-onie","title":"Install Switch Vendor ONIE","text":"<p>Beta-1 uses the switch vendor ONIE for installation of the NOS. The latest vendor provided version of ONIE is recommended to be installed. Hedgehog ONIE must not be used.</p>"},{"location":"install-upgrade/upgrade/#changes-to-the-wiring-diagram","title":"Changes to the Wiring Diagram","text":"<ul> <li>All API versions changed from <code>v1alpha2</code> to <code>v1beta1</code></li> <li><code>Server[control=true]</code> object type was removed and replaced with <code>ControlNode</code> object in the <code>fabricator.githedgehog.com/v1beta1</code> API (.spec.control field removed), <code>Server</code> object only describes workload server now</li> <li>All initial configuration is mainly still available using the <code>hhfab init</code> flags but now configurable in the <code>fab.yaml</code> file it creates and available in the runtime in the <code>Fabricator</code> object in the <code>fabricator.githedgehog.com/v1beta1</code> API</li> <li><code>Connection[type=management]</code> object removed, relevant information is now present on the <code>ControlNode</code> object in the form of the management interface and its config, switches are always connected using management port</li> <li><code>.spec.location</code> remove from <code>Switch</code> object</li> <li><code>.spec.boot</code> added to <code>Switch</code> object with <code>mac</code> and <code>serial</code> fields, at least one of them is required to identify switch for installation</li> </ul>"},{"location":"install-upgrade/upgrade/#install-the-control-node","title":"Install The Control Node","text":"<p>Follow the instructions for installing the Beta-1 Fabric on a control node.</p>"},{"location":"install-upgrade/upgrade/#install-nos-using-onie-nos-install-option","title":"Install NOS using ONIE NOS Install Option","text":"<p>As the switches boot up, select the ONIE option from the grub screen. From there select the \"NOS Install\" option. The install option will cause the switch to begin searching for installation media, this media is supplied by the control node.</p>"},{"location":"reference/api/","title":"API Reference","text":""},{"location":"reference/api/#packages","title":"Packages","text":"<ul> <li>agent.githedgehog.com/v1beta1</li> <li>dhcp.githedgehog.com/v1beta1</li> <li>vpc.githedgehog.com/v1beta1</li> <li>wiring.githedgehog.com/v1beta1</li> </ul>"},{"location":"reference/api/#agentgithedgehogcomv1beta1","title":"agent.githedgehog.com/v1beta1","text":"<p>Package v1beta1 contains API Schema definitions for the agent v1beta1 API group. This is the internal API group for the switch and control node agents. Not intended to be modified by the user.</p>"},{"location":"reference/api/#resource-types","title":"Resource Types","text":"<ul> <li>Agent</li> </ul>"},{"location":"reference/api/#adminstatus","title":"AdminStatus","text":"<p>Underlying type: string</p> <p>Appears in: - SwitchStateInterface</p> Field Description `` <code>up</code> <code>down</code> <code>testing</code>"},{"location":"reference/api/#agent","title":"Agent","text":"<p>Agent is an internal API object used by the controller to pass all relevant information to the agent running on a specific switch in order to fully configure it and manage its lifecycle. It is not intended to be used directly by users. Spec of the object isn't user-editable, it is managed by the controller. Status of the object is updated by the agent and is used by the controller to track the state of the agent and the switch it is running on. Name of the Agent object is the same as the name of the switch it is running on and it's created in the same namespace as the Switch object.</p> Field Description Default Validation <code>apiVersion</code> string <code>agent.githedgehog.com/v1beta1</code> <code>kind</code> string <code>Agent</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>status</code> AgentStatus Status is the observed state of the Agent"},{"location":"reference/api/#agentstatus","title":"AgentStatus","text":"<p>AgentStatus defines the observed state of the agent running on a specific switch and includes information about the switch itself as well as the state of the agent and applied configuration.</p> <p>Appears in: - Agent</p> Field Description Default Validation <code>version</code> string Current running agent version <code>installID</code> string ID of the agent installation, used to track NOS re-installs <code>runID</code> string ID of the agent run, used to track NOS reboots <code>lastHeartbeat</code> Time Time of the last heartbeat from the agent <code>lastAttemptTime</code> Time Time of the last attempt to apply configuration <code>lastAttemptGen</code> integer Generation of the last attempt to apply configuration <code>lastAppliedTime</code> Time Time of the last successful configuration application <code>lastAppliedGen</code> integer Generation of the last successful configuration application <code>state</code> SwitchState Detailed switch state updated with each heartbeat <code>conditions</code> Condition array Conditions of the agent, includes readiness marker for use with kubectl wait"},{"location":"reference/api/#bgpmessages","title":"BGPMessages","text":"<p>Appears in: - SwitchStateBGPNeighbor</p> Field Description Default Validation <code>received</code> BGPMessagesCounters <code>sent</code> BGPMessagesCounters"},{"location":"reference/api/#bgpmessagescounters","title":"BGPMessagesCounters","text":"<p>Appears in: - BGPMessages</p> Field Description Default Validation <code>capability</code> integer <code>keepalive</code> integer <code>notification</code> integer <code>open</code> integer <code>routeRefresh</code> integer <code>update</code> integer"},{"location":"reference/api/#bgpneighborsessionstate","title":"BGPNeighborSessionState","text":"<p>Underlying type: string</p> <p>Appears in: - SwitchStateBGPNeighbor</p> Field Description `` <code>idle</code> <code>connect</code> <code>active</code> <code>openSent</code> <code>openConfirm</code> <code>established</code>"},{"location":"reference/api/#bgppeertype","title":"BGPPeerType","text":"<p>Underlying type: string</p> <p>Appears in: - SwitchStateBGPNeighbor</p> Field Description `` <code>internal</code> <code>external</code>"},{"location":"reference/api/#operstatus","title":"OperStatus","text":"<p>Underlying type: string</p> <p>Appears in: - SwitchStateInterface</p> Field Description `` <code>up</code> <code>down</code> <code>testing</code> <code>unknown</code> <code>dormant</code> <code>notPresent</code> <code>lowerLayerDown</code>"},{"location":"reference/api/#switchstate","title":"SwitchState","text":"<p>Appears in: - AgentStatus</p> Field Description Default Validation <code>nos</code> SwitchStateNOS Information about the switch and NOS <code>interfaces</code> object (keys:string, values:SwitchStateInterface) Switch interfaces state (incl. physical, management and port channels) <code>breakouts</code> object (keys:string, values:SwitchStateBreakout) Breakout ports state (port -&gt; breakout state) <code>bgpNeighbors</code> object (keys:string, values:map[string]SwitchStateBGPNeighbor) State of all BGP neighbors (VRF -&gt; neighbor address -&gt; state) <code>platform</code> SwitchStatePlatform State of the switch platform (fans, PSUs, sensors) <code>criticalResources</code> SwitchStateCRM State of the critical resources (ACLs, routes, etc.)"},{"location":"reference/api/#switchstatebgpneighbor","title":"SwitchStateBGPNeighbor","text":"<p>Appears in: - SwitchState</p> Field Description Default Validation <code>connectionsDropped</code> integer <code>enabled</code> boolean <code>establishedTransitions</code> integer <code>lastEstablished</code> Time <code>lastRead</code> Time <code>lastResetReason</code> string <code>lastResetTime</code> Time <code>lastWrite</code> Time <code>localAS</code> integer <code>messages</code> BGPMessages <code>peerAS</code> integer <code>peerGroup</code> string <code>peerPort</code> integer <code>peerType</code> BGPPeerType <code>remoteRouterID</code> string <code>sessionState</code> BGPNeighborSessionState <code>shutdownMessage</code> string <code>prefixes</code> object (keys:string, values:SwitchStateBGPNeighborPrefixes)"},{"location":"reference/api/#switchstatebgpneighborprefixes","title":"SwitchStateBGPNeighborPrefixes","text":"<p>Appears in: - SwitchStateBGPNeighbor</p> Field Description Default Validation <code>received</code> integer <code>receivedPrePolicy</code> integer <code>sent</code> integer"},{"location":"reference/api/#switchstatebreakout","title":"SwitchStateBreakout","text":"<p>Appears in: - SwitchState</p> Field Description Default Validation <code>mode</code> string <code>nosMembers</code> string array <code>status</code> string"},{"location":"reference/api/#switchstatecrm","title":"SwitchStateCRM","text":"<p>Appears in: - SwitchState</p> Field Description Default Validation <code>aclStats</code> SwitchStateCRMACLStats <code>stats</code> SwitchStateCRMStats"},{"location":"reference/api/#switchstatecrmacldetails","title":"SwitchStateCRMACLDetails","text":"<p>Appears in: - SwitchStateCRMACLInfo</p> Field Description Default Validation <code>groupsAvailable</code> integer <code>groupsUsed</code> integer <code>tablesAvailable</code> integer <code>tablesUsed</code> integer"},{"location":"reference/api/#switchstatecrmaclinfo","title":"SwitchStateCRMACLInfo","text":"<p>Appears in: - SwitchStateCRMACLStats</p> Field Description Default Validation <code>lag</code> SwitchStateCRMACLDetails <code>port</code> SwitchStateCRMACLDetails <code>rif</code> SwitchStateCRMACLDetails <code>switch</code> SwitchStateCRMACLDetails <code>vlan</code> SwitchStateCRMACLDetails"},{"location":"reference/api/#switchstatecrmaclstats","title":"SwitchStateCRMACLStats","text":"<p>Appears in: - SwitchStateCRM</p> Field Description Default Validation <code>egress</code> SwitchStateCRMACLInfo <code>ingress</code> SwitchStateCRMACLInfo"},{"location":"reference/api/#switchstatecrmstats","title":"SwitchStateCRMStats","text":"<p>Appears in: - SwitchStateCRM</p> Field Description Default Validation <code>dnatEntriesAvailable</code> integer <code>dnatEntriesUsed</code> integer <code>fdbEntriesAvailable</code> integer <code>fdbEntriesUsed</code> integer <code>ipmcEntriesAvailable</code> integer <code>ipmcEntriesUsed</code> integer <code>ipv4NeighborsAvailable</code> integer <code>ipv4NeighborsUsed</code> integer <code>ipv4NexthopsAvailable</code> integer <code>ipv4NexthopsUsed</code> integer <code>ipv4RoutesAvailable</code> integer <code>ipv4RoutesUsed</code> integer <code>ipv6NeighborsAvailable</code> integer <code>ipv6NeighborsUsed</code> integer <code>ipv6NexthopsAvailable</code> integer <code>ipv6NexthopsUsed</code> integer <code>ipv6RoutesAvailable</code> integer <code>ipv6RoutesUsed</code> integer <code>nexthopGroupMembersAvailable</code> integer <code>nexthopGroupMembersUsed</code> integer <code>nexthopGroupsAvailable</code> integer <code>nexthopGroupsUsed</code> integer <code>snatEntriesAvailable</code> integer <code>snatEntriesUsed</code> integer"},{"location":"reference/api/#switchstateinterface","title":"SwitchStateInterface","text":"<p>Appears in: - SwitchState</p> Field Description Default Validation <code>enabled</code> boolean <code>adminStatus</code> AdminStatus <code>operStatus</code> OperStatus <code>mac</code> string <code>lastChanged</code> Time <code>speed</code> string <code>counters</code> SwitchStateInterfaceCounters <code>transceiver</code> SwitchStateTransceiver <code>lldpNeighbors</code> SwitchStateLLDPNeighbor array"},{"location":"reference/api/#switchstateinterfacecounters","title":"SwitchStateInterfaceCounters","text":"<p>Appears in: - SwitchStateInterface</p> Field Description Default Validation <code>inBitsPerSecond</code> float <code>inDiscards</code> integer <code>inErrors</code> integer <code>inPktsPerSecond</code> float <code>inUtilization</code> integer <code>lastClear</code> Time <code>outBitsPerSecond</code> float <code>outDiscards</code> integer <code>outErrors</code> integer <code>outPktsPerSecond</code> float <code>outUtilization</code> integer"},{"location":"reference/api/#switchstatelldpneighbor","title":"SwitchStateLLDPNeighbor","text":"<p>Appears in: - SwitchStateInterface</p> Field Description Default Validation <code>chassisID</code> string <code>systemName</code> string <code>systemDescription</code> string <code>portID</code> string <code>portDescription</code> string <code>manufacturer</code> string <code>model</code> string <code>serialNumber</code> string"},{"location":"reference/api/#switchstatenos","title":"SwitchStateNOS","text":"<p>SwitchStateNOS contains information about the switch and NOS received from the switch itself by the agent</p> <p>Appears in: - SwitchState</p> Field Description Default Validation <code>asicVersion</code> string ASIC name, such as \"broadcom\" or \"vs\" <code>buildCommit</code> string NOS build commit <code>buildDate</code> string NOS build date <code>builtBy</code> string NOS build user <code>configDbVersion</code> string NOS config DB version, such as \"version_4_2_1\" <code>distributionVersion</code> string Distribution version, such as \"Debian 10.13\" <code>hardwareVersion</code> string Hardware version, such as \"X01\" <code>hwskuVersion</code> string Hwsku version, such as \"DellEMC-S5248f-P-25G-DPB\" <code>kernelVersion</code> string Kernel version, such as \"5.10.0-21-amd64\" <code>mfgName</code> string Manufacturer name, such as \"Dell EMC\" <code>platformName</code> string Platform name, such as \"x86_64-dellemc_s5248f_c3538-r0\" <code>productDescription</code> string NOS product description, such as \"Enterprise SONiC Distribution by Broadcom - Enterprise Base package\" <code>productVersion</code> string NOS product version, empty for Broadcom SONiC <code>serialNumber</code> string Switch serial number <code>softwareVersion</code> string NOS software version, such as \"4.2.0-Enterprise_Base\" <code>uptime</code> string Switch uptime, such as \"21:21:27 up 1 day, 23:26, 0 users, load average: 1.92, 1.99, 2.00 \""},{"location":"reference/api/#switchstateplatform","title":"SwitchStatePlatform","text":"<p>Appears in: - SwitchState</p> Field Description Default Validation <code>fans</code> object (keys:string, values:SwitchStatePlatformFan) <code>psus</code> object (keys:string, values:SwitchStatePlatformPSU) <code>temperature</code> object (keys:string, values:SwitchStatePlatformTemperature)"},{"location":"reference/api/#switchstateplatformfan","title":"SwitchStatePlatformFan","text":"<p>Appears in: - SwitchStatePlatform</p> Field Description Default Validation <code>direction</code> string <code>speed</code> float <code>presence</code> boolean <code>status</code> boolean"},{"location":"reference/api/#switchstateplatformpsu","title":"SwitchStatePlatformPSU","text":"<p>Appears in: - SwitchStatePlatform</p> Field Description Default Validation <code>inputCurrent</code> float <code>inputPower</code> float <code>inputVoltage</code> float <code>outputCurrent</code> float <code>outputPower</code> float <code>outputVoltage</code> float <code>presence</code> boolean <code>status</code> boolean"},{"location":"reference/api/#switchstateplatformtemperature","title":"SwitchStatePlatformTemperature","text":"<p>Appears in: - SwitchStatePlatform</p> Field Description Default Validation <code>temperature</code> float <code>alarms</code> string <code>highThreshold</code> float <code>criticalHighThreshold</code> float <code>lowThreshold</code> float <code>criticalLowThreshold</code> float"},{"location":"reference/api/#switchstatetransceiver","title":"SwitchStateTransceiver","text":"<p>Appears in: - SwitchStateInterface</p> Field Description Default Validation <code>description</code> string <code>cableClass</code> string <code>formFactor</code> string <code>connectorType</code> string <code>present</code> string <code>cableLength</code> float <code>operStatus</code> string <code>temperature</code> float <code>voltage</code> float <code>serialNumber</code> string <code>vendor</code> string <code>vendorPart</code> string <code>vendorOUI</code> string <code>vendorRev</code> string"},{"location":"reference/api/#dhcpgithedgehogcomv1beta1","title":"dhcp.githedgehog.com/v1beta1","text":"<p>Package v1beta1 contains API Schema definitions for the dhcp v1beta1 API group. It is the primary internal API group for the intended Hedgehog DHCP server configuration and storing leases as well as making them available to the end user through API. Not intended to be modified by the user.</p>"},{"location":"reference/api/#resource-types_1","title":"Resource Types","text":"<ul> <li>DHCPSubnet</li> </ul>"},{"location":"reference/api/#dhcpallocated","title":"DHCPAllocated","text":"<p>DHCPAllocated is a single allocated IP with expiry time and hostname from DHCP requests, it's effectively a DHCP lease</p> <p>Appears in: - DHCPSubnetStatus</p> Field Description Default Validation <code>ip</code> string Allocated IP address <code>expiry</code> Time Expiry time of the lease <code>hostname</code> string Hostname from DHCP request"},{"location":"reference/api/#dhcpsubnet","title":"DHCPSubnet","text":"<p>DHCPSubnet is the configuration (spec) for the Hedgehog DHCP server and storage for the leases (status). It's primary internal API group, but it makes allocated IPs / leases information available to the end user through API. Not intended to be modified by the user.</p> Field Description Default Validation <code>apiVersion</code> string <code>dhcp.githedgehog.com/v1beta1</code> <code>kind</code> string <code>DHCPSubnet</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> DHCPSubnetSpec Spec is the desired state of the DHCPSubnet <code>status</code> DHCPSubnetStatus Status is the observed state of the DHCPSubnet"},{"location":"reference/api/#dhcpsubnetspec","title":"DHCPSubnetSpec","text":"<p>DHCPSubnetSpec defines the desired state of DHCPSubnet</p> <p>Appears in: - DHCPSubnet</p> Field Description Default Validation <code>subnet</code> string Full VPC subnet name (including VPC name), such as \"vpc-0/default\" <code>cidrBlock</code> string CIDR block to use for VPC subnet, such as \"10.10.10.0/24\" <code>gateway</code> string Gateway, such as 10.10.10.1 <code>startIP</code> string Start IP from the CIDRBlock to allocate IPs, such as 10.10.10.10 <code>endIP</code> string End IP from the CIDRBlock to allocate IPs, such as 10.10.10.99 <code>vrf</code> string VRF name to identify specific VPC (will be added to DHCP packets by DHCP relay in suboption 151), such as \"VrfVvpc-1\" as it's named on switch <code>circuitID</code> string VLAN ID to identify specific subnet within the VPC, such as \"Vlan1000\" as it's named on switch <code>pxeURL</code> string PXEURL (optional) to identify the pxe server to use to boot hosts connected to this segment such as http://10.10.10.99/bootfilename or tftp://10.10.10.99/bootfilename, http query strings are not supported <code>dnsServers</code> string array DNSservers (optional) to configure Domain Name Servers for this particular segment such as: 10.10.10.1, 10.10.10.2 <code>timeServers</code> string array TimeServers (optional) NTP server addresses to configure for time servers for this particular segment such as: 10.10.10.1, 10.10.10.2 <code>interfaceMTU</code> integer InterfaceMTU (optional) is the MTU setting that the dhcp server will send to the clients. It is dependent on the client to honor this option. <code>defaultURL</code> string DefaultURL (optional) is the option 114 \"default-url\" to be sent to the clients"},{"location":"reference/api/#dhcpsubnetstatus","title":"DHCPSubnetStatus","text":"<p>DHCPSubnetStatus defines the observed state of DHCPSubnet</p> <p>Appears in: - DHCPSubnet</p> Field Description Default Validation <code>allocated</code> object (keys:string, values:DHCPAllocated) Allocated is a map of allocated IPs with expiry time and hostname from DHCP requests"},{"location":"reference/api/#vpcgithedgehogcomv1beta1","title":"vpc.githedgehog.com/v1beta1","text":"<p>Package v1beta1 contains API Schema definitions for the vpc v1beta1 API group. It is public API group for the VPCs and Externals APIs. Intended to be used by the user.</p>"},{"location":"reference/api/#resource-types_2","title":"Resource Types","text":"<ul> <li>External</li> <li>ExternalAttachment</li> <li>ExternalPeering</li> <li>IPv4Namespace</li> <li>VPC</li> <li>VPCAttachment</li> <li>VPCPeering</li> </ul>"},{"location":"reference/api/#external","title":"External","text":"<p>External object represents an external system connected to the Fabric and available to the specific IPv4Namespace. Users can do external peering with the external system by specifying the name of the External Object without need to worry about the details of how external system is attached to the Fabric.</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>External</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> ExternalSpec Spec is the desired state of the External <code>status</code> ExternalStatus Status is the observed state of the External"},{"location":"reference/api/#externalattachment","title":"ExternalAttachment","text":"<p>ExternalAttachment is a definition of how specific switch is connected with external system (External object). Effectively it represents BGP peering between the switch and external system including all needed configuration.</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>ExternalAttachment</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> ExternalAttachmentSpec Spec is the desired state of the ExternalAttachment <code>status</code> ExternalAttachmentStatus Status is the observed state of the ExternalAttachment"},{"location":"reference/api/#externalattachmentneighbor","title":"ExternalAttachmentNeighbor","text":"<p>ExternalAttachmentNeighbor defines the BGP neighbor configuration for the external attachment</p> <p>Appears in: - ExternalAttachmentSpec</p> Field Description Default Validation <code>asn</code> integer ASN is the ASN of the BGP neighbor <code>ip</code> string IP is the IP address of the BGP neighbor to peer with"},{"location":"reference/api/#externalattachmentspec","title":"ExternalAttachmentSpec","text":"<p>ExternalAttachmentSpec defines the desired state of ExternalAttachment</p> <p>Appears in: - ExternalAttachment</p> Field Description Default Validation <code>external</code> string External is the name of the External object this attachment belongs to <code>connection</code> string Connection is the name of the Connection object this attachment belongs to (essentially the name of the switch/port) <code>switch</code> ExternalAttachmentSwitch Switch is the switch port configuration for the external attachment <code>neighbor</code> ExternalAttachmentNeighbor Neighbor is the BGP neighbor configuration for the external attachment"},{"location":"reference/api/#externalattachmentstatus","title":"ExternalAttachmentStatus","text":"<p>ExternalAttachmentStatus defines the observed state of ExternalAttachment</p> <p>Appears in: - ExternalAttachment</p>"},{"location":"reference/api/#externalattachmentswitch","title":"ExternalAttachmentSwitch","text":"<p>ExternalAttachmentSwitch defines the switch port configuration for the external attachment</p> <p>Appears in: - ExternalAttachmentSpec</p> Field Description Default Validation <code>vlan</code> integer VLAN (optional) is the VLAN ID used for the subinterface on a switch port specified in the connection, set to 0 if no VLAN is used <code>ip</code> string IP is the IP address of the subinterface on a switch port specified in the connection"},{"location":"reference/api/#externalpeering","title":"ExternalPeering","text":"<p>ExternalPeering is the Schema for the externalpeerings API</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>ExternalPeering</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> ExternalPeeringSpec Spec is the desired state of the ExternalPeering <code>status</code> ExternalPeeringStatus Status is the observed state of the ExternalPeering"},{"location":"reference/api/#externalpeeringspec","title":"ExternalPeeringSpec","text":"<p>ExternalPeeringSpec defines the desired state of ExternalPeering</p> <p>Appears in: - ExternalPeering</p> Field Description Default Validation <code>permit</code> ExternalPeeringSpecPermit Permit defines the peering policy - which VPC and External to peer with and which subnets/prefixes to permit"},{"location":"reference/api/#externalpeeringspecexternal","title":"ExternalPeeringSpecExternal","text":"<p>ExternalPeeringSpecExternal defines the External-side of the configuration to peer with</p> <p>Appears in: - ExternalPeeringSpecPermit</p> Field Description Default Validation <code>name</code> string Name is the name of the External to peer with <code>prefixes</code> ExternalPeeringSpecPrefix array Prefixes is the list of prefixes to permit from the External to the VPC"},{"location":"reference/api/#externalpeeringspecpermit","title":"ExternalPeeringSpecPermit","text":"<p>ExternalPeeringSpecPermit defines the peering policy - which VPC and External to peer with and which subnets/prefixes to permit</p> <p>Appears in: - ExternalPeeringSpec</p> Field Description Default Validation <code>vpc</code> ExternalPeeringSpecVPC VPC is the VPC-side of the configuration to peer with <code>external</code> ExternalPeeringSpecExternal External is the External-side of the configuration to peer with"},{"location":"reference/api/#externalpeeringspecprefix","title":"ExternalPeeringSpecPrefix","text":"<p>ExternalPeeringSpecPrefix defines the prefix to permit from the External to the VPC</p> <p>Appears in: - ExternalPeeringSpecExternal</p> Field Description Default Validation <code>prefix</code> string Prefix is the subnet to permit from the External to the VPC, e.g. 0.0.0.0/0 for any route including default route.It matches any prefix length less than or equal to 32 effectively permitting all prefixes within the specified one."},{"location":"reference/api/#externalpeeringspecvpc","title":"ExternalPeeringSpecVPC","text":"<p>ExternalPeeringSpecVPC defines the VPC-side of the configuration to peer with</p> <p>Appears in: - ExternalPeeringSpecPermit</p> Field Description Default Validation <code>name</code> string Name is the name of the VPC to peer with <code>subnets</code> string array Subnets is the list of subnets to advertise from VPC to the External"},{"location":"reference/api/#externalpeeringstatus","title":"ExternalPeeringStatus","text":"<p>ExternalPeeringStatus defines the observed state of ExternalPeering</p> <p>Appears in: - ExternalPeering</p>"},{"location":"reference/api/#externalspec","title":"ExternalSpec","text":"<p>ExternalSpec describes IPv4 namespace External belongs to and inbound/outbound communities which are used to filter routes from/to the external system.</p> <p>Appears in: - External</p> Field Description Default Validation <code>ipv4Namespace</code> string IPv4Namespace is the name of the IPv4Namespace this External belongs to <code>inboundCommunity</code> string InboundCommunity is the inbound community to filter routes from the external system (e.g. 65102:5000) <code>outboundCommunity</code> string OutboundCommunity is theoutbound community that all outbound routes will be stamped with (e.g. 50000:50001)"},{"location":"reference/api/#externalstatus","title":"ExternalStatus","text":"<p>ExternalStatus defines the observed state of External</p> <p>Appears in: - External</p>"},{"location":"reference/api/#ipv4namespace","title":"IPv4Namespace","text":"<p>IPv4Namespace represents a namespace for VPC subnets allocation. All VPC subnets within a single IPv4Namespace are non-overlapping. Users can create multiple IPv4Namespaces to allocate same VPC subnets.</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>IPv4Namespace</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> IPv4NamespaceSpec Spec is the desired state of the IPv4Namespace <code>status</code> IPv4NamespaceStatus Status is the observed state of the IPv4Namespace"},{"location":"reference/api/#ipv4namespacespec","title":"IPv4NamespaceSpec","text":"<p>IPv4NamespaceSpec defines the desired state of IPv4Namespace</p> <p>Appears in: - IPv4Namespace</p> Field Description Default Validation <code>subnets</code> string array Subnets is the list of subnets to allocate VPC subnets from, couldn't overlap between each other and with Fabric reserved subnets MaxItems: 20 MinItems: 1"},{"location":"reference/api/#ipv4namespacestatus","title":"IPv4NamespaceStatus","text":"<p>IPv4NamespaceStatus defines the observed state of IPv4Namespace</p> <p>Appears in: - IPv4Namespace</p>"},{"location":"reference/api/#vpc","title":"VPC","text":"<p>VPC is 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.</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>VPC</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> VPCSpec Spec is the desired state of the VPC <code>status</code> VPCStatus Status is the observed state of the VPC"},{"location":"reference/api/#vpcattachment","title":"VPCAttachment","text":"<p>VPCAttachment is the Schema for the vpcattachments API</p> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>VPCAttachment</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> VPCAttachmentSpec Spec is the desired state of the VPCAttachment <code>status</code> VPCAttachmentStatus Status is the observed state of the VPCAttachment"},{"location":"reference/api/#vpcattachmentspec","title":"VPCAttachmentSpec","text":"<p>VPCAttachmentSpec defines the desired state of VPCAttachment</p> <p>Appears in: - VPCAttachment</p> Field Description Default Validation <code>subnet</code> string Subnet is the full name of the VPC subnet to attach to, such as \"vpc-1/default\" <code>connection</code> string Connection is the name of the connection to attach to the VPC <code>nativeVLAN</code> boolean NativeVLAN is the flag to indicate if the native VLAN should be used for attaching the VPC subnet"},{"location":"reference/api/#vpcattachmentstatus","title":"VPCAttachmentStatus","text":"<p>VPCAttachmentStatus defines the observed state of VPCAttachment</p> <p>Appears in: - VPCAttachment</p>"},{"location":"reference/api/#vpcdhcp","title":"VPCDHCP","text":"<p>VPCDHCP defines the on-demand DHCP configuration for the subnet</p> <p>Appears in: - VPCSubnet</p> Field Description Default Validation <code>relay</code> string Relay is the DHCP relay IP address, if specified, DHCP server will be disabled <code>enable</code> boolean Enable enables DHCP server for the subnet <code>range</code> VPCDHCPRange Range (optional) is the DHCP range for the subnet if DHCP server is enabled <code>options</code> VPCDHCPOptions Options (optional) is the DHCP options for the subnet if DHCP server is enabled"},{"location":"reference/api/#vpcdhcpoptions","title":"VPCDHCPOptions","text":"<p>VPCDHCPOptions defines the DHCP options for the subnet if DHCP server is enabled</p> <p>Appears in: - VPCDHCP</p> Field Description Default Validation <code>pxeURL</code> string PXEURL (optional) to identify the pxe server to use to boot hosts connected to this segment such as http://10.10.10.99/bootfilename or tftp://10.10.10.99/bootfilename, http query strings are not supported <code>dnsServers</code> string array DNSservers (optional) to configure Domain Name Servers for this particular segment such as: 10.10.10.1, 10.10.10.2 Optional: {}  <code>timeServers</code> string array TimeServers (optional) NTP server addresses to configure for time servers for this particular segment such as: 10.10.10.1, 10.10.10.2 Optional: {}  <code>interfaceMTU</code> integer InterfaceMTU (optional) is the MTU setting that the dhcp server will send to the clients. It is dependent on the client to honor this option."},{"location":"reference/api/#vpcdhcprange","title":"VPCDHCPRange","text":"<p>VPCDHCPRange defines the DHCP range for the subnet if DHCP server is enabled</p> <p>Appears in: - VPCDHCP</p> Field Description Default Validation <code>start</code> string Start is the start IP address of the DHCP range <code>end</code> string End is the end IP address of the DHCP range"},{"location":"reference/api/#vpcpeer","title":"VPCPeer","text":"<p>Appears in: - VPCPeeringSpec</p> Field Description Default Validation <code>subnets</code> string array Subnets is the list of subnets to advertise from current VPC to the peer VPC MaxItems: 10 MinItems: 1"},{"location":"reference/api/#vpcpeering","title":"VPCPeering","text":"<p>VPCPeering represents a peering between two VPCs with corresponding filtering rules. Minimal example of the VPC peering showing vpc-1 to vpc-2 peering with all subnets allowed:</p> <pre><code>spec:\n  permit:\n  - vpc-1: {}\n    vpc-2: {}\n</code></pre> Field Description Default Validation <code>apiVersion</code> string <code>vpc.githedgehog.com/v1beta1</code> <code>kind</code> string <code>VPCPeering</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> VPCPeeringSpec Spec is the desired state of the VPCPeering <code>status</code> VPCPeeringStatus Status is the observed state of the VPCPeering"},{"location":"reference/api/#vpcpeeringspec","title":"VPCPeeringSpec","text":"<p>VPCPeeringSpec defines the desired state of VPCPeering</p> <p>Appears in: - VPCPeering</p> Field Description Default Validation <code>remote</code> string <code>permit</code> map[string]VPCPeer array Permit defines a list of the peering policies - which VPC subnets will have access to the peer VPC subnets. MaxItems: 10 MinItems: 1"},{"location":"reference/api/#vpcpeeringstatus","title":"VPCPeeringStatus","text":"<p>VPCPeeringStatus defines the observed state of VPCPeering</p> <p>Appears in: - VPCPeering</p>"},{"location":"reference/api/#vpcspec","title":"VPCSpec","text":"<p>VPCSpec defines the desired state of VPC. At least one subnet is required.</p> <p>Appears in: - VPC</p> Field Description Default Validation <code>subnets</code> object (keys:string, values:VPCSubnet) Subnets is the list of VPC subnets to configure <code>ipv4Namespace</code> string IPv4Namespace is the name of the IPv4Namespace this VPC belongs to (if not specified, \"default\" is used) <code>vlanNamespace</code> string VLANNamespace is the name of the VLANNamespace this VPC belongs to (if not specified, \"default\" is used) <code>defaultIsolated</code> boolean DefaultIsolated sets default behavior for isolated mode for the subnets (disabled by default) <code>defaultRestricted</code> boolean DefaultRestricted sets default behavior for restricted mode for the subnets (disabled by default) <code>permit</code> string array array Permit defines a list of the access policies between the subnets within the VPC - each policy is a list of subnets that have access to each other.It's applied on top of the subnet isolation flag and if subnet isn't isolated it's not required to have it in a permit list while if vpc is markedas isolated it's required to have it in a permit list to have access to other subnets. <code>staticRoutes</code> VPCStaticRoute array StaticRoutes is the list of additional static routes for the VPC"},{"location":"reference/api/#vpcstaticroute","title":"VPCStaticRoute","text":"<p>VPCStaticRoute defines the static route for the VPC</p> <p>Appears in: - VPCSpec</p> Field Description Default Validation <code>prefix</code> string Prefix for the static route (mandatory), e.g. 10.42.0.0/24 <code>nextHops</code> string array NextHops for the static route (at least one is required), e.g. 10.99.0.0"},{"location":"reference/api/#vpcstatus","title":"VPCStatus","text":"<p>VPCStatus defines the observed state of VPC</p> <p>Appears in: - VPC</p>"},{"location":"reference/api/#vpcsubnet","title":"VPCSubnet","text":"<p>VPCSubnet defines the VPC subnet configuration</p> <p>Appears in: - VPCSpec</p> Field Description Default Validation <code>subnet</code> string Subnet is the subnet CIDR block, such as \"10.0.0.0/24\", should belong to the IPv4Namespace and be unique within the namespace <code>gateway</code> string Gateway (optional) for the subnet, if not specified, the first IP (e.g. 10.0.0.1) in the subnet is used as the gateway <code>dhcp</code> VPCDHCP DHCP is the on-demand DHCP configuration for the subnet <code>vlan</code> integer VLAN is the VLAN ID for the subnet, should belong to the VLANNamespace and be unique within the namespace <code>isolated</code> boolean Isolated is the flag to enable isolated mode for the subnet which means no access to and from the other subnets within the VPC <code>restricted</code> boolean Restricted is the flag to enable restricted mode for the subnet which means no access between hosts within the subnet itself"},{"location":"reference/api/#wiringgithedgehogcomv1beta1","title":"wiring.githedgehog.com/v1beta1","text":"<p>Package v1beta1 contains API Schema definitions for the wiring v1beta1 API group. It is public API group mainly for the underlay definition including Switches, Server, wiring between them and etc. Intended to be used by the user.</p>"},{"location":"reference/api/#resource-types_3","title":"Resource Types","text":"<ul> <li>Connection</li> <li>Server</li> <li>Switch</li> <li>SwitchGroup</li> <li>SwitchProfile</li> <li>VLANNamespace</li> </ul>"},{"location":"reference/api/#baseportname","title":"BasePortName","text":"<p>BasePortName defines the full name of the switch port</p> <p>Appears in: - ConnExternalLink - ConnFabricLinkSwitch - ConnStaticExternalLinkSwitch - ServerToSwitchLink - SwitchToSwitchLink</p> Field Description Default Validation <code>port</code> string Port defines the full name of the switch port in the format of \"device/port\", such as \"spine-1/Ethernet1\".SONiC port name is used as a port name and switch name should be same as the name of the Switch object."},{"location":"reference/api/#connbundled","title":"ConnBundled","text":"<p>ConnBundled defines the bundled connection (port channel, single server to a single switch with multiple links)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>links</code> ServerToSwitchLink array Links is the list of server-to-switch links <code>mtu</code> integer MTU is the MTU to be configured on the switch port or port channel"},{"location":"reference/api/#conneslag","title":"ConnESLAG","text":"<p>ConnESLAG defines the ESLAG connection (port channel, single server to 2-4 switches with multiple links)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>links</code> ServerToSwitchLink array Links is the list of server-to-switch links MinItems: 2  <code>mtu</code> integer MTU is the MTU to be configured on the switch port or port channel <code>fallback</code> boolean Fallback is the optional flag that used to indicate one of the links in LACP port channel to be used as a fallback link"},{"location":"reference/api/#connexternal","title":"ConnExternal","text":"<p>ConnExternal defines the external connection (single switch to a single external device with a single link)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>link</code> ConnExternalLink Link is the external connection link"},{"location":"reference/api/#connexternallink","title":"ConnExternalLink","text":"<p>ConnExternalLink defines the external connection link</p> <p>Appears in: - ConnExternal</p> Field Description Default Validation <code>switch</code> BasePortName"},{"location":"reference/api/#connfabric","title":"ConnFabric","text":"<p>ConnFabric defines the fabric connection (single spine to a single leaf with at least one link)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>links</code> FabricLink array Links is the list of spine-to-leaf links MinItems: 1"},{"location":"reference/api/#connfabriclinkswitch","title":"ConnFabricLinkSwitch","text":"<p>ConnFabricLinkSwitch defines the switch side of the fabric link</p> <p>Appears in: - FabricLink</p> Field Description Default Validation <code>port</code> string Port defines the full name of the switch port in the format of \"device/port\", such as \"spine-1/Ethernet1\".SONiC port name is used as a port name and switch name should be same as the name of the Switch object. <code>ip</code> string IP is the IP address of the switch side of the fabric link (switch port configuration) Pattern: <code>^((25[0-5]\\|(2[0-4]\\|1\\d\\|[1-9]\\|)\\d)\\.?\\b)\\{4\\}/([1-2]?[0-9]\\|3[0-2])$</code>"},{"location":"reference/api/#connmclag","title":"ConnMCLAG","text":"<p>ConnMCLAG defines the MCLAG connection (port channel, single server to pair of switches with multiple links)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>links</code> ServerToSwitchLink array Links is the list of server-to-switch links MinItems: 2  <code>mtu</code> integer MTU is the MTU to be configured on the switch port or port channel <code>fallback</code> boolean Fallback is the optional flag that used to indicate one of the links in LACP port channel to be used as a fallback link"},{"location":"reference/api/#connmclagdomain","title":"ConnMCLAGDomain","text":"<p>ConnMCLAGDomain defines the MCLAG domain connection which makes two switches into a single logical switch or redundancy group and allows to use MCLAG connections to connect servers in a multi-homed way.</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>peerLinks</code> SwitchToSwitchLink array PeerLinks is the list of peer links between the switches, used to pass server traffic between switch MinItems: 1  <code>sessionLinks</code> SwitchToSwitchLink array SessionLinks is the list of session links between the switches, used only to pass MCLAG control plane and BGPtraffic between switches MinItems: 1"},{"location":"reference/api/#connstaticexternal","title":"ConnStaticExternal","text":"<p>ConnStaticExternal defines the static external connection (single switch to a single external device with a single link)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>link</code> ConnStaticExternalLink Link is the static external connection link <code>withinVPC</code> string WithinVPC is the optional VPC name to provision the static external connection within the VPC VRF instead of default one to make resource available to the specific VPC"},{"location":"reference/api/#connstaticexternallink","title":"ConnStaticExternalLink","text":"<p>ConnStaticExternalLink defines the static external connection link</p> <p>Appears in: - ConnStaticExternal</p> Field Description Default Validation <code>switch</code> ConnStaticExternalLinkSwitch Switch is the switch side of the static external connection link"},{"location":"reference/api/#connstaticexternallinkswitch","title":"ConnStaticExternalLinkSwitch","text":"<p>ConnStaticExternalLinkSwitch defines the switch side of the static external connection link</p> <p>Appears in: - ConnStaticExternalLink</p> Field Description Default Validation <code>port</code> string Port defines the full name of the switch port in the format of \"device/port\", such as \"spine-1/Ethernet1\".SONiC port name is used as a port name and switch name should be same as the name of the Switch object. <code>ip</code> string IP is the IP address of the switch side of the static external connection link (switch port configuration) Pattern: <code>^((25[0-5]\\|(2[0-4]\\|1\\d\\|[1-9]\\|)\\d)\\.?\\b)\\{4\\}/([1-2]?[0-9]\\|3[0-2])$</code> <code>nextHop</code> string NextHop is the next hop IP address for static routes that will be created for the subnets Pattern: <code>^((25[0-5]\\|(2[0-4]\\|1\\d\\|[1-9]\\|)\\d)\\.?\\b)\\{4\\}$</code> <code>subnets</code> string array Subnets is the list of subnets that will get static routes using the specified next hop <code>vlan</code> integer VLAN is the optional VLAN ID to be configured on the switch port"},{"location":"reference/api/#connunbundled","title":"ConnUnbundled","text":"<p>ConnUnbundled defines the unbundled connection (no port channel, single server to a single switch with a single link)</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>link</code> ServerToSwitchLink Link is the server-to-switch link <code>mtu</code> integer MTU is the MTU to be configured on the switch port or port channel"},{"location":"reference/api/#connvpcloopback","title":"ConnVPCLoopback","text":"<p>ConnVPCLoopback defines the VPC loopback connection (multiple port pairs on a single switch) that enables automated workaround named \"VPC Loopback\" that allow to avoid switch hardware limitations and traffic going through CPU in some cases</p> <p>Appears in: - ConnectionSpec</p> Field Description Default Validation <code>links</code> SwitchToSwitchLink array Links is the list of VPC loopback links MinItems: 1"},{"location":"reference/api/#connection","title":"Connection","text":"<p>Connection object represents a logical and physical connections between any devices in the Fabric (Switch, Server and External objects). It's needed to define all physical and logical connections between the devices in the Wiring Diagram. Connection type is defined by the top-level field in the ConnectionSpec. Exactly one of them could be used in a single Connection object.</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>Connection</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> ConnectionSpec Spec is the desired state of the Connection <code>status</code> ConnectionStatus Status is the observed state of the Connection"},{"location":"reference/api/#connectionspec","title":"ConnectionSpec","text":"<p>ConnectionSpec defines the desired state of Connection</p> <p>Appears in: - Connection</p> Field Description Default Validation <code>unbundled</code> ConnUnbundled Unbundled defines the unbundled connection (no port channel, single server to a single switch with a single link) <code>bundled</code> ConnBundled Bundled defines the bundled connection (port channel, single server to a single switch with multiple links) <code>mclag</code> ConnMCLAG MCLAG defines the MCLAG connection (port channel, single server to pair of switches with multiple links) <code>eslag</code> ConnESLAG ESLAG defines the ESLAG connection (port channel, single server to 2-4 switches with multiple links) <code>mclagDomain</code> ConnMCLAGDomain MCLAGDomain defines the MCLAG domain connection which makes two switches into a single logical switch for server multi-homing <code>fabric</code> ConnFabric Fabric defines the fabric connection (single spine to a single leaf with at least one link) <code>vpcLoopback</code> ConnVPCLoopback VPCLoopback defines the VPC loopback connection (multiple port pairs on a single switch) for automated workaround <code>external</code> ConnExternal External defines the external connection (single switch to a single external device with a single link) <code>staticExternal</code> ConnStaticExternal StaticExternal defines the static external connection (single switch to a single external device with a single link)"},{"location":"reference/api/#connectionstatus","title":"ConnectionStatus","text":"<p>ConnectionStatus defines the observed state of Connection</p> <p>Appears in: - Connection</p>"},{"location":"reference/api/#fabriclink","title":"FabricLink","text":"<p>FabricLink defines the fabric connection link</p> <p>Appears in: - ConnFabric</p> Field Description Default Validation <code>spine</code> ConnFabricLinkSwitch Spine is the spine side of the fabric link <code>leaf</code> ConnFabricLinkSwitch Leaf is the leaf side of the fabric link"},{"location":"reference/api/#server","title":"Server","text":"<p>Server is the Schema for the servers API</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>Server</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> ServerSpec Spec is desired state of the server <code>status</code> ServerStatus Status is the observed state of the server"},{"location":"reference/api/#serverfacingconnectionconfig","title":"ServerFacingConnectionConfig","text":"<p>ServerFacingConnectionConfig defines any server-facing connection (unbundled, bundled, mclag, etc.) configuration</p> <p>Appears in: - ConnBundled - ConnESLAG - ConnMCLAG - ConnUnbundled</p> Field Description Default Validation <code>mtu</code> integer MTU is the MTU to be configured on the switch port or port channel"},{"location":"reference/api/#serverspec","title":"ServerSpec","text":"<p>ServerSpec defines the desired state of Server</p> <p>Appears in: - Server</p> Field Description Default Validation <code>description</code> string Description is a description of the server <code>profile</code> string Profile is the profile of the server, name of the ServerProfile object to be used for this server, currently not used by the Fabric"},{"location":"reference/api/#serverstatus","title":"ServerStatus","text":"<p>ServerStatus defines the observed state of Server</p> <p>Appears in: - Server</p>"},{"location":"reference/api/#servertoswitchlink","title":"ServerToSwitchLink","text":"<p>ServerToSwitchLink defines the server-to-switch link</p> <p>Appears in: - ConnBundled - ConnESLAG - ConnMCLAG - ConnUnbundled</p> Field Description Default Validation <code>server</code> BasePortName Server is the server side of the connection <code>switch</code> BasePortName Switch is the switch side of the connection"},{"location":"reference/api/#switch","title":"Switch","text":"<p>Switch is the Schema for the switches API</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>Switch</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> SwitchSpec Spec is desired state of the switch <code>status</code> SwitchStatus Status is the observed state of the switch"},{"location":"reference/api/#switchboot","title":"SwitchBoot","text":"<p>Appears in: - SwitchSpec</p> Field Description Default Validation <code>serial</code> string Identify switch by serial number <code>mac</code> string Identify switch by MAC address of the management port"},{"location":"reference/api/#switchgroup","title":"SwitchGroup","text":"<p>SwitchGroup is the marker API object to group switches together, switch can belong to multiple groups</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>SwitchGroup</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> SwitchGroupSpec Spec is the desired state of the SwitchGroup <code>status</code> SwitchGroupStatus Status is the observed state of the SwitchGroup"},{"location":"reference/api/#switchgroupspec","title":"SwitchGroupSpec","text":"<p>SwitchGroupSpec defines the desired state of SwitchGroup</p> <p>Appears in: - SwitchGroup</p>"},{"location":"reference/api/#switchgroupstatus","title":"SwitchGroupStatus","text":"<p>SwitchGroupStatus defines the observed state of SwitchGroup</p> <p>Appears in: - SwitchGroup</p>"},{"location":"reference/api/#switchprofile","title":"SwitchProfile","text":"<p>SwitchProfile represents switch capabilities and configuration</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>SwitchProfile</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> SwitchProfileSpec <code>status</code> SwitchProfileStatus"},{"location":"reference/api/#switchprofileconfig","title":"SwitchProfileConfig","text":"<p>Defines switch-specific configuration options</p> <p>Appears in: - SwitchProfileSpec</p> Field Description Default Validation <code>maxPathsEBGP</code> integer MaxPathsIBGP defines the maximum number of IBGP paths to be configured"},{"location":"reference/api/#switchprofilefeatures","title":"SwitchProfileFeatures","text":"<p>Defines features supported by a specific switch which is later used for roles and Fabric API features usage validation</p> <p>Appears in: - SwitchProfileSpec</p> Field Description Default Validation <code>subinterfaces</code> boolean Subinterfaces defines if switch supports subinterfaces <code>vxlan</code> boolean VXLAN defines if switch supports VXLANs <code>acls</code> boolean ACLs defines if switch supports ACLs"},{"location":"reference/api/#switchprofileport","title":"SwitchProfilePort","text":"<p>Defines a switch port configuration Only one of Profile or Group can be set</p> <p>Appears in: - SwitchProfileSpec</p> Field Description Default Validation <code>nos</code> string NOSName defines how port is named in the NOS <code>baseNOSName</code> string BaseNOSName defines the base NOS name that could be used together with the profile to generate the actual NOS name (e.g. breakouts) <code>label</code> string Label defines the physical port label you can see on the actual switch <code>group</code> string If port isn't directly manageable, group defines the group it belongs to, exclusive with profile <code>profile</code> string If port is directly configurable, profile defines the profile it belongs to, exclusive with group <code>management</code> boolean Management defines if port is a management port, it's a special case and it can't have a group or profile <code>oniePortName</code> string OniePortName defines the ONIE port name for management ports only"},{"location":"reference/api/#switchprofileportgroup","title":"SwitchProfilePortGroup","text":"<p>Defines a switch port group configuration</p> <p>Appears in: - SwitchProfileSpec</p> Field Description Default Validation <code>nos</code> string NOSName defines how group is named in the NOS <code>profile</code> string Profile defines the possible configuration profile for the group, could only have speed profile"},{"location":"reference/api/#switchprofileportprofile","title":"SwitchProfilePortProfile","text":"<p>Defines a switch port profile configuration</p> <p>Appears in: - SwitchProfileSpec</p> Field Description Default Validation <code>speed</code> SwitchProfilePortProfileSpeed Speed defines the speed configuration for the profile, exclusive with breakout <code>breakout</code> SwitchProfilePortProfileBreakout Breakout defines the breakout configuration for the profile, exclusive with speed <code>autoNegAllowed</code> boolean AutoNegAllowed defines if configuring auto-negotiation is allowed for the port <code>autoNegDefault</code> boolean AutoNegDefault defines the default auto-negotiation state for the port"},{"location":"reference/api/#switchprofileportprofilebreakout","title":"SwitchProfilePortProfileBreakout","text":"<p>Defines a switch port profile breakout configuration</p> <p>Appears in: - SwitchProfilePortProfile</p> Field Description Default Validation <code>default</code> string Default defines the default breakout mode for the profile <code>supported</code> object (keys:string, values:SwitchProfilePortProfileBreakoutMode) Supported defines the supported breakout modes for the profile with the NOS name offsets"},{"location":"reference/api/#switchprofileportprofilebreakoutmode","title":"SwitchProfilePortProfileBreakoutMode","text":"<p>Defines a switch port profile breakout mode configuration</p> <p>Appears in: - SwitchProfilePortProfileBreakout</p> Field Description Default Validation <code>offsets</code> string array Offsets defines the breakout NOS port name offset from the port NOS Name for each breakout mode"},{"location":"reference/api/#switchprofileportprofilespeed","title":"SwitchProfilePortProfileSpeed","text":"<p>Defines a switch port profile speed configuration</p> <p>Appears in: - SwitchProfilePortProfile</p> Field Description Default Validation <code>default</code> string Default defines the default speed for the profile <code>supported</code> string array Supported defines the supported speeds for the profile"},{"location":"reference/api/#switchprofilespec","title":"SwitchProfileSpec","text":"<p>SwitchProfileSpec defines the desired state of SwitchProfile</p> <p>Appears in: - SwitchProfile</p> Field Description Default Validation <code>displayName</code> string DisplayName defines the human-readable name of the switch <code>otherNames</code> string array OtherNames defines alternative names for the switch <code>features</code> SwitchProfileFeatures Features defines the features supported by the switch <code>config</code> SwitchProfileConfig Config defines the switch-specific configuration options <code>ports</code> object (keys:string, values:SwitchProfilePort) Ports defines the switch port configuration <code>portGroups</code> object (keys:string, values:SwitchProfilePortGroup) PortGroups defines the switch port group configuration <code>portProfiles</code> object (keys:string, values:SwitchProfilePortProfile) PortProfiles defines the switch port profile configuration <code>nosType</code> NOSType NOSType defines the NOS type to be used for the switch <code>platform</code> string Platform is what expected to be request by ONIE and displayed in the NOS"},{"location":"reference/api/#switchprofilestatus","title":"SwitchProfileStatus","text":"<p>SwitchProfileStatus defines the observed state of SwitchProfile</p> <p>Appears in: - SwitchProfile</p>"},{"location":"reference/api/#switchredundancy","title":"SwitchRedundancy","text":"<p>SwitchRedundancy is the switch redundancy configuration which includes name of the redundancy group switch belongs to and its type, used both for MCLAG and ESLAG connections. It defines how redundancy will be configured and handled on the switch as well as which connection types will be available. If not specified, switch will not be part of any redundancy group. If name isn't empty, type must be specified as well and name should be the same as one of the SwitchGroup objects.</p> <p>Appears in: - SwitchSpec</p> Field Description Default Validation <code>group</code> string Group is the name of the redundancy group switch belongs to <code>type</code> RedundancyType Type is the type of the redundancy group, could be mclag or eslag"},{"location":"reference/api/#switchrole","title":"SwitchRole","text":"<p>Underlying type: string</p> <p>SwitchRole is the role of the switch, could be spine, server-leaf or border-leaf or mixed-leaf</p> <p>Validation: - Enum: [spine server-leaf border-leaf mixed-leaf virtual-edge]</p> <p>Appears in: - SwitchSpec</p> Field Description <code>spine</code> <code>server-leaf</code> <code>border-leaf</code> <code>mixed-leaf</code> <code>virtual-edge</code>"},{"location":"reference/api/#switchspec","title":"SwitchSpec","text":"<p>SwitchSpec defines the desired state of Switch</p> <p>Appears in: - Switch</p> Field Description Default Validation <code>role</code> SwitchRole Role is the role of the switch, could be spine, server-leaf or border-leaf or mixed-leaf Enum: [spine server-leaf border-leaf mixed-leaf virtual-edge] Required: {}  <code>description</code> string Description is a description of the switch <code>profile</code> string Profile is the profile of the switch, name of the SwitchProfile object to be used for this switch, currently not used by the Fabric <code>groups</code> string array Groups is a list of switch groups the switch belongs to <code>redundancy</code> SwitchRedundancy Redundancy is the switch redundancy configuration including name of the redundancy group switch belongs to and its type, used both for MCLAG and ESLAG connections <code>vlanNamespaces</code> string array VLANNamespaces is a list of VLAN namespaces the switch is part of, their VLAN ranges could not overlap <code>asn</code> integer ASN is the ASN of the switch <code>ip</code> string IP is the IP of the switch that could be used to access it from other switches and control nodes in the Fabric <code>vtepIP</code> string VTEPIP is the VTEP IP of the switch <code>protocolIP</code> string ProtocolIP is used as BGP Router ID for switch configuration <code>portGroupSpeeds</code> object (keys:string, values:string) PortGroupSpeeds is a map of port group speeds, key is the port group name, value is the speed, such as '\"2\": 10G' <code>portSpeeds</code> object (keys:string, values:string) PortSpeeds is a map of port speeds, key is the port name, value is the speed <code>portBreakouts</code> object (keys:string, values:string) PortBreakouts is a map of port breakouts, key is the port name, value is the breakout configuration, such as \"1/55: 4x25G\" <code>portAutoNegs</code> object (keys:string, values:boolean) PortAutoNegs is a map of port auto negotiation, key is the port name, value is true or false <code>boot</code> SwitchBoot Boot is the boot/provisioning information of the switch"},{"location":"reference/api/#switchstatus","title":"SwitchStatus","text":"<p>SwitchStatus defines the observed state of Switch</p> <p>Appears in: - Switch</p>"},{"location":"reference/api/#switchtoswitchlink","title":"SwitchToSwitchLink","text":"<p>SwitchToSwitchLink defines the switch-to-switch link</p> <p>Appears in: - ConnMCLAGDomain - ConnVPCLoopback</p> Field Description Default Validation <code>switch1</code> BasePortName Switch1 is the first switch side of the connection <code>switch2</code> BasePortName Switch2 is the second switch side of the connection"},{"location":"reference/api/#vlannamespace","title":"VLANNamespace","text":"<p>VLANNamespace is the Schema for the vlannamespaces API</p> Field Description Default Validation <code>apiVersion</code> string <code>wiring.githedgehog.com/v1beta1</code> <code>kind</code> string <code>VLANNamespace</code> <code>metadata</code> ObjectMeta Refer to Kubernetes API documentation for fields of <code>metadata</code>. <code>spec</code> VLANNamespaceSpec Spec is the desired state of the VLANNamespace <code>status</code> VLANNamespaceStatus Status is the observed state of the VLANNamespace"},{"location":"reference/api/#vlannamespacespec","title":"VLANNamespaceSpec","text":"<p>VLANNamespaceSpec defines the desired state of VLANNamespace</p> <p>Appears in: - VLANNamespace</p> Field Description Default Validation <code>ranges</code> VLANRange array Ranges is a list of VLAN ranges to be used in this namespace, couldn't overlap between each other and with Fabric reserved VLAN ranges MaxItems: 20 MinItems: 1"},{"location":"reference/api/#vlannamespacestatus","title":"VLANNamespaceStatus","text":"<p>VLANNamespaceStatus defines the observed state of VLANNamespace</p> <p>Appears in: - VLANNamespace</p>"},{"location":"reference/cli/","title":"Fabric CLI","text":"<p>Under construction.</p> <p>Currently Fabric CLI is represented by a kubectl plugin <code>kubectl-fabric</code> automatically installed on the Control Node. It is a wrapper around <code>kubectl</code> and Kubernetes client which allows to manage Fabric resources in a more convenient way. Fabric CLI only provides a subset of the functionality available via Fabric API and is focused on simplifying objects creation and some manipulation with the already existing objects while main get/list/update operations are expected to be done using <code>kubectl</code>.</p> <pre><code>core@control-1 ~ $ kubectl fabric\nNAME:\n   kubectl fabric - Hedgehog Fabric API kubectl plugin\n\nUSAGE:\n   kubectl fabric [global options] command [command options]\n\nVERSION:\n   v0.53.1\n\nCOMMANDS:\n   vpc               VPC commands\n   switch, sw        Switch commands\n   connection, conn  Connection commands\n   switchgroup, sg   SwitchGroup commands\n   external, ext     External commands\n   inspect, i        Inspect Fabric API Objects and Primitives\n   help, h           Shows a list of commands or help for one command\n\nGLOBAL OPTIONS:\n   --verbose, -v  verbose output (includes debug) (default: true)\n   --help, -h     show help\n   --version, -V  print the version\n</code></pre>"},{"location":"reference/cli/#vpc","title":"VPC","text":"<p>Create VPC named <code>vpc-1</code> with subnet <code>10.0.1.0/24</code> and VLAN <code>1001</code> with DHCP enabled and DHCP range starting from <code>10.0.1.10</code> (optional):</p> <pre><code>core@control-1 ~ $ kubectl fabric vpc create --name vpc-1 --subnet 10.0.1.0/24 --vlan 1001 --dhcp --dhcp-start 10.0.1.10\n</code></pre> <p>Attach previously created VPC to the server <code>server-01</code> (which is connected to the Fabric using the <code>server-01--mclag--leaf-01--leaf-02</code> Connection):</p> <pre><code>core@control-1 ~ $ kubectl fabric vpc attach --vpc-subnet vpc-1/default --connection server-01--mclag--leaf-01--leaf-02\n</code></pre> <p>To peer VPC with another VPC (e.g. <code>vpc-2</code>) use the following command:</p> <pre><code>core@control-1 ~ $ kubectl fabric vpc peer --vpc vpc-1 --vpc vpc-2\n</code></pre>"},{"location":"reference/profiles/","title":"Switch Profiles Catalog","text":"<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>"},{"location":"reference/profiles/#celestica-ds3000","title":"Celestica DS3000","text":"<p>Profile Name (to use in switch.spec.profile): celestica-ds3000</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/2 2 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/3 3 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/4 4 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/5 5 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/6 6 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/7 7 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/8 8 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/9 9 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/10 10 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/11 11 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/12 12 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/13 13 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/14 14 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/15 15 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/16 16 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/17 17 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/18 18 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/19 19 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/20 20 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/21 21 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/22 22 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/23 23 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/24 24 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/25 25 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/26 26 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/27 27 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/28 28 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/29 29 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/30 30 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/31 31 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/32 32 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/33 33 Direct 10G 1G, 10G"},{"location":"reference/profiles/#celestica-ds4000","title":"Celestica DS4000","text":"<p>Profile Name (to use in switch.spec.profile): celestica-ds4000</p> <p>Supported features:</p> <ul> <li>Subinterfaces: false</li> <li>VXLAN: false</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/2 2 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/3 3 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/4 4 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/5 5 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/6 6 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/7 7 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/8 8 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/9 9 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/10 10 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/11 11 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/12 12 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/13 13 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/14 14 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/15 15 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/16 16 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/17 17 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/18 18 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/19 19 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/20 20 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/21 21 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/22 22 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/23 23 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/24 24 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/25 25 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/26 26 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/27 27 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/28 28 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/29 29 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/30 30 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/31 31 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/32 32 Breakout 1x400G 1x100G, 1x10G, 1x25G, 1x400G, 1x40G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/33 33 Direct 10G 1G, 10G"},{"location":"reference/profiles/#dell-s5232f-on","title":"Dell S5232F-ON","text":"<p>Profile Name (to use in switch.spec.profile): dell-s5232f-on</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/2 2 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/3 3 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/4 4 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/5 5 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/6 6 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/7 7 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/8 8 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/9 9 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/10 10 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/11 11 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/12 12 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/13 13 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/14 14 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/15 15 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/16 16 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/17 17 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/18 18 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/19 19 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/20 20 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/21 21 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/22 22 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/23 23 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/24 24 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/25 25 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/26 26 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/27 27 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/28 28 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/29 29 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/30 30 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/31 31 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/32 32 Direct 100G 40G, 100G E1/33 33 Direct 10G 1G, 10G E1/34 34 Direct 10G 1G, 10G"},{"location":"reference/profiles/#dell-s5248f-on","title":"Dell S5248F-ON","text":"<p>Profile Name (to use in switch.spec.profile): dell-s5248f-on</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Port Group 1 25G 10G, 25G E1/2 2 Port Group 1 25G 10G, 25G E1/3 3 Port Group 1 25G 10G, 25G E1/4 4 Port Group 1 25G 10G, 25G E1/5 5 Port Group 2 25G 10G, 25G E1/6 6 Port Group 2 25G 10G, 25G E1/7 7 Port Group 2 25G 10G, 25G E1/8 8 Port Group 2 25G 10G, 25G E1/9 9 Port Group 3 25G 10G, 25G E1/10 10 Port Group 3 25G 10G, 25G E1/11 11 Port Group 3 25G 10G, 25G E1/12 12 Port Group 3 25G 10G, 25G E1/13 13 Port Group 4 25G 10G, 25G E1/14 14 Port Group 4 25G 10G, 25G E1/15 15 Port Group 4 25G 10G, 25G E1/16 16 Port Group 4 25G 10G, 25G E1/17 17 Port Group 5 25G 10G, 25G E1/18 18 Port Group 5 25G 10G, 25G E1/19 19 Port Group 5 25G 10G, 25G E1/20 20 Port Group 5 25G 10G, 25G E1/21 21 Port Group 6 25G 10G, 25G E1/22 22 Port Group 6 25G 10G, 25G E1/23 23 Port Group 6 25G 10G, 25G E1/24 24 Port Group 6 25G 10G, 25G E1/25 25 Port Group 7 25G 10G, 25G E1/26 26 Port Group 7 25G 10G, 25G E1/27 27 Port Group 7 25G 10G, 25G E1/28 28 Port Group 7 25G 10G, 25G E1/29 29 Port Group 8 25G 10G, 25G E1/30 30 Port Group 8 25G 10G, 25G E1/31 31 Port Group 8 25G 10G, 25G E1/32 32 Port Group 8 25G 10G, 25G E1/33 33 Port Group 9 25G 10G, 25G E1/34 34 Port Group 9 25G 10G, 25G E1/35 35 Port Group 9 25G 10G, 25G E1/36 36 Port Group 9 25G 10G, 25G E1/37 37 Port Group 10 25G 10G, 25G E1/38 38 Port Group 10 25G 10G, 25G E1/39 39 Port Group 10 25G 10G, 25G E1/40 40 Port Group 10 25G 10G, 25G E1/41 41 Port Group 11 25G 10G, 25G E1/42 42 Port Group 11 25G 10G, 25G E1/43 43 Port Group 11 25G 10G, 25G E1/44 44 Port Group 11 25G 10G, 25G E1/45 45 Port Group 12 25G 10G, 25G E1/46 46 Port Group 12 25G 10G, 25G E1/47 47 Port Group 12 25G 10G, 25G E1/48 48 Port Group 12 25G 10G, 25G E1/49 49 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/50 50 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/51 51 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/52 52 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/53 53 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/54 54 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/55 55 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/56 56 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G"},{"location":"reference/profiles/#dell-z9332f-on","title":"Dell Z9332F-ON","text":"<p>Profile Name (to use in switch.spec.profile): dell-z9332f-on</p> <p>Supported features:</p> <ul> <li>Subinterfaces: false</li> <li>VXLAN: false</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/2 2 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/3 3 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/4 4 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/5 5 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/6 6 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/7 7 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/8 8 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/9 9 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/10 10 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/11 11 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/12 12 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/13 13 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/14 14 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/15 15 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/16 16 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/17 17 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/18 18 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/19 19 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/20 20 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/21 21 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/22 22 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/23 23 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/24 24 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/25 25 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/26 26 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/27 27 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/28 28 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/29 29 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/30 30 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/31 31 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/32 32 Breakout 1x400G 1x100G, 1x10G, 1x200G, 1x25G, 1x400G, 1x40G, 1x50G, 2x100G, 2x200G, 2x40G, 4x100G, 4x10G, 4x25G, 8x10G, 8x25G, 8x50G E1/33 M1 Direct 10G 1G, 10G E1/34 M2 Direct 10G 1G, 10G"},{"location":"reference/profiles/#edgecore-dcs203","title":"Edgecore DCS203","text":"<p>Profile Name (to use in switch.spec.profile): edgecore-dcs203</p> <p>Other names: Edgecore AS7326-56X</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Port Group 1 25G 10G, 25G E1/2 2 Port Group 1 25G 10G, 25G E1/3 3 Port Group 1 25G 10G, 25G E1/4 4 Port Group 1 25G 10G, 25G E1/5 5 Port Group 1 25G 10G, 25G E1/6 6 Port Group 1 25G 10G, 25G E1/7 7 Port Group 1 25G 10G, 25G E1/8 8 Port Group 1 25G 10G, 25G E1/9 9 Port Group 1 25G 10G, 25G E1/10 10 Port Group 1 25G 10G, 25G E1/11 11 Port Group 1 25G 10G, 25G E1/12 12 Port Group 1 25G 10G, 25G E1/13 13 Port Group 2 25G 10G, 25G E1/14 14 Port Group 2 25G 10G, 25G E1/15 15 Port Group 2 25G 10G, 25G E1/16 16 Port Group 2 25G 10G, 25G E1/17 17 Port Group 2 25G 10G, 25G E1/18 18 Port Group 2 25G 10G, 25G E1/19 19 Port Group 2 25G 10G, 25G E1/20 20 Port Group 2 25G 10G, 25G E1/21 21 Port Group 2 25G 10G, 25G E1/22 22 Port Group 2 25G 10G, 25G E1/23 23 Port Group 2 25G 10G, 25G E1/24 24 Port Group 2 25G 10G, 25G E1/25 25 Port Group 3 25G 10G, 25G E1/26 26 Port Group 3 25G 10G, 25G E1/27 27 Port Group 3 25G 10G, 25G E1/28 28 Port Group 3 25G 10G, 25G E1/29 29 Port Group 3 25G 10G, 25G E1/30 30 Port Group 3 25G 10G, 25G E1/31 31 Port Group 3 25G 10G, 25G E1/32 32 Port Group 3 25G 10G, 25G E1/33 33 Port Group 3 25G 10G, 25G E1/34 34 Port Group 3 25G 10G, 25G E1/35 35 Port Group 3 25G 10G, 25G E1/36 36 Port Group 3 25G 10G, 25G E1/37 37 Port Group 4 25G 10G, 25G E1/38 38 Port Group 4 25G 10G, 25G E1/39 39 Port Group 4 25G 10G, 25G E1/40 40 Port Group 4 25G 10G, 25G E1/41 41 Port Group 4 25G 10G, 25G E1/42 42 Port Group 4 25G 10G, 25G E1/43 43 Port Group 4 25G 10G, 25G E1/44 44 Port Group 4 25G 10G, 25G E1/45 45 Port Group 4 25G 10G, 25G E1/46 46 Port Group 4 25G 10G, 25G E1/47 47 Port Group 4 25G 10G, 25G E1/48 48 Port Group 4 25G 10G, 25G E1/49 49 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/50 50 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/51 51 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/52 52 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/53 53 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/54 54 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/55 55 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/56 56 Direct 100G 40G, 100G E1/57 57 Direct 10G 1G, 10G E1/58 58 Direct 10G 1G, 10G"},{"location":"reference/profiles/#edgecore-dcs204","title":"Edgecore DCS204","text":"<p>Profile Name (to use in switch.spec.profile): edgecore-dcs204</p> <p>Other names: Edgecore AS7726-32X</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/2 2 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/3 3 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/4 4 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/5 5 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/6 6 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/7 7 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/8 8 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/9 9 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/10 10 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/11 11 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/12 12 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/13 13 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/14 14 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/15 15 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/16 16 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/17 17 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/18 18 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/19 19 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/20 20 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/21 21 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/22 22 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/23 23 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/24 24 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/25 25 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/26 26 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/27 27 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/28 28 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/29 29 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/30 30 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/31 31 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/32 32 Direct 100G 40G, 100G E1/33 33 Direct 10G 1G, 10G E1/34 34 Direct 10G 1G, 10G"},{"location":"reference/profiles/#edgecore-dcs501","title":"Edgecore DCS501","text":"<p>Profile Name (to use in switch.spec.profile): edgecore-dcs501</p> <p>Other names: Edgecore AS7712-32X</p> <p>Supported features:</p> <ul> <li>Subinterfaces: false</li> <li>VXLAN: false</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/2 2 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/3 3 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/4 4 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/5 5 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/6 6 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/7 7 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/8 8 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/9 9 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/10 10 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/11 11 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/12 12 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/13 13 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/14 14 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/15 15 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/16 16 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/17 17 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/18 18 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/19 19 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/20 20 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/21 21 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/22 22 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/23 23 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/24 24 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/25 25 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/26 26 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/27 27 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/28 28 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/29 29 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/30 30 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/31 31 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/32 32 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G"},{"location":"reference/profiles/#edgecore-eps203","title":"Edgecore EPS203","text":"<p>Profile Name (to use in switch.spec.profile): edgecore-eps203</p> <p>Other names: Edgecore AS4630-54NPE</p> <p>Supported features:</p> <ul> <li>Subinterfaces: false</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/2 2 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/3 3 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/4 4 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/5 5 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/6 6 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/7 7 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/8 8 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/9 9 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/10 10 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/11 11 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/12 12 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/13 13 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/14 14 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/15 15 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/16 16 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/17 17 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/18 18 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/19 19 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/20 20 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/21 21 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/22 22 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/23 23 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/24 24 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/25 25 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/26 26 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/27 27 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/28 28 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/29 29 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/30 30 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/31 31 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/32 32 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/33 33 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/34 34 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/35 35 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/36 36 Direct 2.5G 1G, 2.5G, AutoNeg supported (default: true) E1/37 37 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/38 38 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/39 39 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/40 40 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/41 41 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/42 42 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/43 43 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/44 44 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/45 45 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/46 46 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/47 47 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/48 48 Direct 10G 1G, 10G, AutoNeg supported (default: true) E1/49 49 Direct 25G 1G, 10G, 25G E1/50 50 Direct 25G 1G, 10G, 25G E1/51 51 Direct 25G 1G, 10G, 25G E1/52 52 Direct 25G 1G, 10G, 25G E1/53 53 Direct 100G 40G, 100G E1/54 54 Direct 100G 40G, 100G"},{"location":"reference/profiles/#supermicro-sse-c4632sb","title":"Supermicro SSE-C4632SB","text":"<p>Profile Name (to use in switch.spec.profile): supermicro-sse-c4632sb</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: true</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/2 2 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/3 3 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/4 4 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/5 5 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/6 6 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/7 7 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/8 8 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/9 9 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/10 10 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/11 11 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/12 12 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/13 13 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/14 14 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/15 15 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/16 16 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/17 17 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/18 18 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/19 19 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/20 20 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/21 21 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/22 22 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/23 23 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/24 24 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/25 25 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/26 26 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/27 27 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/28 28 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/29 29 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/30 30 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/31 31 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/32 32 Breakout 1x100G 1x100G, 1x40G, 4x10G, 4x25G E1/33 33 Direct 10G 1G, 10G"},{"location":"reference/profiles/#virtual-switch","title":"Virtual Switch","text":"<p>Profile Name (to use in switch.spec.profile): vs</p> <p>Supported features:</p> <ul> <li>Subinterfaces: true</li> <li>VXLAN: true</li> <li>ACLs: false</li> </ul> <p>Available Ports:</p> <p>Label column is a port label on a physical switch.</p> Port Label Type Group Default Supported M1 Management E1/1 1 Port Group 1 25G 10G, 25G E1/2 2 Port Group 1 25G 10G, 25G E1/3 3 Port Group 1 25G 10G, 25G E1/4 4 Port Group 1 25G 10G, 25G E1/5 5 Port Group 2 25G 10G, 25G E1/6 6 Port Group 2 25G 10G, 25G E1/7 7 Port Group 2 25G 10G, 25G E1/8 8 Port Group 2 25G 10G, 25G E1/9 9 Port Group 3 25G 10G, 25G E1/10 10 Port Group 3 25G 10G, 25G E1/11 11 Port Group 3 25G 10G, 25G E1/12 12 Port Group 3 25G 10G, 25G E1/13 13 Port Group 4 25G 10G, 25G E1/14 14 Port Group 4 25G 10G, 25G E1/15 15 Port Group 4 25G 10G, 25G E1/16 16 Port Group 4 25G 10G, 25G E1/17 17 Port Group 5 25G 10G, 25G E1/18 18 Port Group 5 25G 10G, 25G E1/19 19 Port Group 5 25G 10G, 25G E1/20 20 Port Group 5 25G 10G, 25G E1/21 21 Port Group 6 25G 10G, 25G E1/22 22 Port Group 6 25G 10G, 25G E1/23 23 Port Group 6 25G 10G, 25G E1/24 24 Port Group 6 25G 10G, 25G E1/25 25 Port Group 7 25G 10G, 25G E1/26 26 Port Group 7 25G 10G, 25G E1/27 27 Port Group 7 25G 10G, 25G E1/28 28 Port Group 7 25G 10G, 25G E1/29 29 Port Group 8 25G 10G, 25G E1/30 30 Port Group 8 25G 10G, 25G E1/31 31 Port Group 8 25G 10G, 25G E1/32 32 Port Group 8 25G 10G, 25G E1/33 33 Port Group 9 25G 10G, 25G E1/34 34 Port Group 9 25G 10G, 25G E1/35 35 Port Group 9 25G 10G, 25G E1/36 36 Port Group 9 25G 10G, 25G E1/37 37 Port Group 10 25G 10G, 25G E1/38 38 Port Group 10 25G 10G, 25G E1/39 39 Port Group 10 25G 10G, 25G E1/40 40 Port Group 10 25G 10G, 25G E1/41 41 Port Group 11 25G 10G, 25G E1/42 42 Port Group 11 25G 10G, 25G E1/43 43 Port Group 11 25G 10G, 25G E1/44 44 Port Group 11 25G 10G, 25G E1/45 45 Port Group 12 25G 10G, 25G E1/46 46 Port Group 12 25G 10G, 25G E1/47 47 Port Group 12 25G 10G, 25G E1/48 48 Port Group 12 25G 10G, 25G E1/49 49 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/50 50 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/51 51 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/52 52 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/53 53 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/54 54 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/55 55 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G E1/56 56 Breakout 1x100G 1x100G, 1x10G, 1x25G, 1x40G, 1x50G, 2x50G, 4x10G, 4x25G"},{"location":"release-notes/","title":"Release notes","text":""},{"location":"release-notes/#2409","title":"24.09","text":""},{"location":"release-notes/#device-support","title":"Device Support","text":"<ul> <li>Dell Z9332 as a spine-only switch</li> </ul>"},{"location":"release-notes/#fabric-lifecycle-management","title":"Fabric Lifecycle Management","text":"<ul> <li>Installer ISO builder for zero-touch control node installation</li> <li>CLI for exporting Wiring Diagram</li> <li>CLI for exporting Fabricator configs</li> <li>Automated update mechanism from B1 release, including airgap support</li> </ul>"},{"location":"release-notes/#software-versions","title":"Software versions","text":"<ul> <li>fabricator/hhfab: v0.32.1</li> <li>fabric: v0.58.0</li> <li>broadcom sonic: 4.4.0</li> <li>flatcar: v4081.2.0</li> <li>k8s (k3s): v1.31.1-k3s1</li> </ul>"},{"location":"release-notes/#beta-1","title":"Beta-1","text":""},{"location":"release-notes/#device-support_1","title":"Device support","text":"<ul> <li>Celestica DS4000 as a spine</li> </ul>"},{"location":"release-notes/#sonic","title":"SONiC","text":"<ul> <li>Broadcom SONiC 4.4.0 support</li> </ul>"},{"location":"release-notes/#fabric-provisioning-management","title":"Fabric provisioning, management","text":"<ul> <li>Out-of-band management network connectivity</li> <li>Deprecated support for in-band management network connectivity, chain boot, and front-panel boot until further notice</li> <li>Automatic zero touch switch provisioning [ ZTP ] is based on the serial number or the first management interface MAC address</li> <li>Full support for airgap installations and upgrades by default</li> <li>Self-contained USB image generation for control node installation</li> <li>Automated in-place upgrades for control node(s) moving forward</li> </ul>"},{"location":"release-notes/#api","title":"API","text":"<ul> <li>API version v1beta1</li> <li>Guaranteed backward compatibility moving forward</li> </ul>"},{"location":"release-notes/#alpha-7","title":"Alpha-7","text":""},{"location":"release-notes/#device-support_2","title":"Device Support","text":"<p>New devices supported by the fabric:</p> <ul> <li> <p>Clos Spine</p> <ul> <li>Celestica DS3000</li> <li>Edgecore AS7712-32X-EC</li> <li>Supermicro SSE-C4632SB</li> </ul> </li> <li> <p>Clos Leaf</p> <ul> <li>Celestica DS3000</li> <li>Supermicro SSE-C4632SB</li> </ul> </li> <li> <p>Collapsed Core ToR</p> <ul> <li>Celestica DS3000</li> <li>Supermicro SSE-C4632SB</li> </ul> </li> </ul>"},{"location":"release-notes/#switchprofiles","title":"SwitchProfiles","text":"<ul> <li>Metadata describing switch capabilities, feature capacities, and resource naming mapping.</li> <li>Switch Profiles are used for providing normalized name/id mapping, validation and internal resource management.</li> <li>Switch Profiles are Mandatory. Each switch model must have a corresponding switch profile to be supported by the fabric.</li> <li>Each switch defined in the wiring diagram should be pointing to the switch profile document.</li> <li>Detailed overview</li> <li>Catalog of switch profiles</li> </ul>"},{"location":"release-notes/#new-universal-port-naming-scheme","title":"New Universal Port Naming Scheme","text":"<ul> <li><code>E&lt;asic&gt;/&lt;port&gt;/&lt;breakout&gt;</code> or <code>M&lt;port&gt;</code></li> <li>Enabled via switch profiles</li> </ul>"},{"location":"release-notes/#improved-per-switch-modelplatform-validation","title":"Improved per switch-model/platform validation","text":"<ul> <li>Enabled via switch profiles</li> </ul>"},{"location":"release-notes/#vpc","title":"VPC","text":"<ul> <li>It\u2019s now possible to explicitly specify a gateway to use in VPC subnets</li> <li>StaticExternal now supports default routes</li> </ul>"},{"location":"release-notes/#inspection-cli","title":"Inspection CLI","text":"<p>CLI commands are intended to navigate fabric configuration and state and allow introspection of the dependencies and cross-domain checking:</p> <ul> <li>Fabric (overall control nodes and switches overview incl. status, serials, etc.)</li> <li>Switch (status, used ports, counters, etc.)</li> <li>Switch sort (connection if used in one, counters, VPC and External attachments, etc.)</li> <li>Server (connection if used in one, VPC attachments, etc.)</li> <li>Connection (incl. VPC and External attachments, Loobpback Workaround usage, etc.)</li> <li>VPC/VPCSubnet (incl. where is it attached and what's reachable from it)</li> <li>IP Address (incl. IPv4Namespace, VPCSubnet and DHCPLease or External/StaticExternal usage)</li> <li>MAC Address (incl. switch ports and DHCP leases)</li> <li>Access between pair of IPs, Server names or VPCSubnets (everything except external IPs will be translated to VPCSubnets)</li> </ul>"},{"location":"release-notes/#observability","title":"Observability","text":"<ul> <li>Example Grafana Dashboards added to the docs</li> <li>Syslog (<code>/var/log/syslog</code>) is now could be collected from all switches and forwarded to Loki targets</li> </ul>"},{"location":"release-notes/#bug-fixes","title":"Bug Fixes","text":"<ul> <li>Fixed: Restricted subnet isn't accessible from other subnets of the same VPC</li> </ul>"},{"location":"release-notes/#alpha-6","title":"Alpha-6","text":""},{"location":"release-notes/#observability_1","title":"Observability","text":""},{"location":"release-notes/#telemetry-prometheus-exporter","title":"Telemetry - Prometheus Exporter","text":"<ul> <li> <p>Hedgehog Fabric Control Plane Agents on switches function as Prometheus Exporters</p> </li> <li> <p>Telemetry data provided by Broadcom SONiC is now supported:</p> <ul> <li>port and interface status and counters</li> <li>transceiver state</li> <li>environmental information (temperature, fans, psu, etc.)</li> <li>BGP state and counters</li> </ul> </li> <li> <p>Export to Prometheus using Prometheus Remote-Write API or any API-compatible platform</p> </li> </ul>"},{"location":"release-notes/#logging","title":"Logging","text":"<ul> <li> <p>Grafana Alloy is supported as a certified logging agent that is installed and managed by the Fabric</p> </li> <li> <p>Data collected</p> <ul> <li>Agent logs</li> <li>Agent, switch, and host-level metrics</li> </ul> </li> <li> <p>Export to API-compliant platforms and products such as Prometheus, Loki, Grafana Cloud, or any LGTM stack</p> </li> </ul>"},{"location":"release-notes/#agent-status-api-enhancements","title":"Agent Status API Enhancements","text":"<ul> <li>Ports status and counters</li> <li>Port breakout status and counters</li> <li>Transceiver status and counters</li> <li>Environmental and platform information</li> <li>LLDP neighbors</li> </ul>"},{"location":"release-notes/#networking-enhancements","title":"Networking enhancements","text":"<ul> <li>Multiple direct control links per switch are now supported</li> <li>Custom static routes could be installed into VPC using API</li> <li>ExternalAttachment could be configured without VLAN now</li> </ul>"},{"location":"release-notes/#other-improvements","title":"Other improvements","text":"<ul> <li>PXE boot with HTTP</li> <li>The <code>hhfab</code> and <code>hhfctl</code> (kubectl plugin) are now published for Linux/MacOS amd64/arm64</li> <li>Switch users can now be configured as part of installation preparation  (username, password hash, role, and public   keys)</li> </ul>"},{"location":"release-notes/#bugs-fixed","title":"Bugs fixed","text":"<ul> <li>DHCP service assigning IP multiple times if restarted in between</li> <li>Remote peering was configured as a local</li> </ul>"},{"location":"release-notes/#alpha-5","title":"Alpha-5","text":""},{"location":"release-notes/#open-source","title":"Open Source","text":"<ul> <li>Apache License 2.0</li> <li>The main repos are public:<ul> <li>Fabric</li> <li>Fabricator</li> <li>Das-boot</li> <li>Toolbox</li> <li>Docs</li> </ul> </li> <li>Items not open-sourced:<ul> <li>HONIE with front panel booting support</li> </ul> </li> </ul>"},{"location":"release-notes/#dhcppxe-boot-support-for-multi-homed-connections","title":"DHCP/PXE boot support for multi-homed connections","text":"<ul> <li>PXE URL support for on-demand DHCP service</li> <li>LACP link (MCLAG and ESLAG) fallback allows support of one of the links without the use of a host-level bond</li> </ul>"},{"location":"release-notes/#improvements","title":"Improvements","text":"<ul> <li>Native VLAN support for server-facing connections</li> <li>Extended wiring validation at hhfab init/build time</li> <li>External peering failover in case of using remote peering on the same switches as external connectivity</li> </ul>"},{"location":"release-notes/#alpha-4","title":"Alpha-4","text":""},{"location":"release-notes/#documentation","title":"Documentation","text":"<ul> <li>Fabric API reference</li> </ul>"},{"location":"release-notes/#host-connectivity-dual-homing-improvements","title":"Host connectivity dual homing improvements","text":"<ul> <li>ESI for VXLAN-based BGP EVPN</li> <li>Support in Fabric and VLAB</li> <li>Host connectivity Redundancy Groups</li> <li>Groups LEAF switches to provide multi-homed connectivity to the Fabric</li> <li>2-4 switches per group</li> <li>Support for MCLAG and ESLAG (EVPN MH / ESI)</li> <li>A single redundancy group can only support multi-homing of one type (ESLAG or MCLAG)</li> <li>Multiple types of redundancy groups can be used in the fabric simultaneously</li> </ul>"},{"location":"release-notes/#improved-vpc-security-policy-better-zero-trust","title":"Improved VPC security policy - better Zero Trust","text":"<ul> <li>Inter-VPC<ul> <li>Allow inter-VPC and external peering with per subnet control</li> </ul> </li> <li>Intra-VPC intra-subnet policies<ul> <li>Isolated Subnets<ul> <li>subnets isolated by default from other subnets in the VPC</li> <li>require a user-defined explicitly permit list to allow communications to other subnets within the VPC</li> <li>can be set on individual subnets within VPC or per entire VPC - off by default</li> <li>Inter-VPC and external peering configurations are not affected and work the same as before</li> </ul> </li> <li>Restricted Subnets<ul> <li>Hosts within a subnet have no mutual reachability</li> <li>Hosts within a subnet can be reached by members of other subnets or peered VPCs as specified by the policy</li> <li>Inter-VPC and external peering configurations are not affected and work the same as before</li> </ul> </li> <li>Permit Lists<ul> <li>Intra-VPC Permit Lists govern connectivity between subnets within the VPC for isolated subnets</li> <li>Inter-VPC Permit Lists govern which subnets of one VPC have access to some subnets of the other VPC for finer-grained control of inter-VPC and external peering</li> </ul> </li> </ul> </li> </ul>"},{"location":"release-notes/#static-external-connection","title":"Static External Connection","text":"<ul> <li>Allows access between hosts within the VPC and devices attached to a switch with user-defined static routes</li> </ul>"},{"location":"release-notes/#internal-improvements","title":"Internal Improvements","text":"<ul> <li>A new, more reliable automated ID allocation system</li> <li>Extra validation of object lifecycle (e.g., object-in-use removal validation)</li> </ul>"},{"location":"release-notes/#known-issues","title":"Known Issues","text":"<ul> <li>External Peering Failover<ul> <li>Conditions: ExternalPeering is specified for the VPC, and the same VPC has Border Leaf VPCPeering</li> <li>Issue: Detaching ExternalPeering may cause VPCPeering on the Border Leaf group to stop working</li> <li>Workaround: VPCPeering on the Border Leaf group should be recreated</li> </ul> </li> </ul>"},{"location":"release-notes/#alpha-3","title":"Alpha-3","text":""},{"location":"release-notes/#sonic-support","title":"SONiC support","text":"<ul> <li>Broadcom Enterprise SONiC 4.2.0 (previously 4.1.1)</li> </ul>"},{"location":"release-notes/#multiple-ipv4-namespaces","title":"Multiple IPv4 namespaces","text":"<ul> <li>Support for multiple overlapping IPv4 addresses in the Fabric</li> <li>Integrated with on-demand DHCP Service (see below)</li> <li>All IPv4 addresses within a given VPC must be unique</li> <li>Only VPCs with non-overlapping IPv4 subnets can peer within the Fabric</li> <li>An external NAT device is required for peering of VPCs with overlapping subnets</li> </ul>"},{"location":"release-notes/#hedgehog-fabric-dhcp-and-ipam-service","title":"Hedgehog Fabric DHCP and IPAM Service","text":"<ul> <li>Custom DHCP server executing in the controllers</li> <li>Multiple IPv4 namespaces with overlapping subnets</li> <li>Multiple VLAN namespaces with overlapping VLAN ranges</li> <li>DHCP leases exposed through the Fabric API</li> <li>Available for VLAB as well as the Fabric</li> </ul>"},{"location":"release-notes/#hedgehog-fabric-ntp-service","title":"Hedgehog Fabric NTP Service","text":"<ul> <li>Custom NTP servers at the controller</li> <li>Switches automatically configured to use control node as NTP server</li> <li>NTP servers can be configured to sync to external time/NTP server</li> </ul>"},{"location":"release-notes/#staticexternal-connections","title":"StaticExternal connections","text":"<ul> <li>Directly connect external infrastructure services (such as NTP, DHCP, DNS) to the Fabric</li> <li>No BGP is required, just automatically configured  static routes</li> </ul>"},{"location":"release-notes/#dhcp-relay-to-3rd-party-dhcp-service","title":"DHCP Relay to 3rd party DHCP service","text":"<p>Support for 3rd party DHCP server (DHCP Relay config) through the API</p>"},{"location":"release-notes/#alpha-2","title":"Alpha-2","text":""},{"location":"release-notes/#controller","title":"Controller","text":"<p>A single controller. No controller redundancy.</p>"},{"location":"release-notes/#controller-connectivity","title":"Controller connectivity","text":"<p>For CLOS/LEAF-SPINE fabrics, it is recommended that the controller connects to one or more leaf switches in the fabric on front-facing data ports. Connection to two or more leaf switches is recommended for redundancy and performance. No port break-out functionality is supported for controller connectivity.</p> <p>Spine controller connectivity is not supported.</p> <p>For Collapsed Core topology, the controller can connect on front-facing data ports, as described above, or on management ports. Note that every switch in the collapsed core topology must be connected to the controller.</p> <p>Management port connectivity can also be supported for CLOS/LEAF-SPINE topology but requires all switches connected to the controllers via management ports. No chain booting is possible for this configuration.</p>"},{"location":"release-notes/#controller-requirements","title":"Controller requirements","text":"<ul> <li>One  1 gig+ port per to connect to each controller attached switch</li> <li>One+ 1 gig+ ports connecting to the external management network.</li> <li>4 Cores, 12GB RAM, 100GB SSD.</li> </ul>"},{"location":"release-notes/#chain-booting","title":"Chain booting","text":"<p>Switches not directly connecting to the controllers can chain boot via the data network.</p>"},{"location":"release-notes/#topology-support","title":"Topology support","text":"<p>CLOS/LEAF-SPINE and Collapsed Core topologies are supported.</p>"},{"location":"release-notes/#leaf-roles-for-clos-topology","title":"LEAF Roles for CLOS topology","text":"<p>server leaf, border leaf, and mixed leaf modes are supported.</p>"},{"location":"release-notes/#collapsed-core-topology","title":"Collapsed Core Topology","text":"<p>Two ToR/LEAF switches with MCLAG server connection.</p>"},{"location":"release-notes/#server-multihoming","title":"Server multihoming","text":"<p>MCLAG-only.</p>"},{"location":"release-notes/#device-support_3","title":"Device support","text":""},{"location":"release-notes/#leafs","title":"LEAFs","text":"<ul> <li> <p>DELL:</p> <ul> <li>S5248F-ON</li> <li>S5232F-ON</li> </ul> </li> <li> <p>Edge-Core:</p> <ul> <li>DCS204 (AS7726-32X)</li> <li>DCS203 (AS7326-56X)</li> <li>EPS203 (AS4630-54NPE)</li> </ul> </li> </ul>"},{"location":"release-notes/#spines","title":"SPINEs","text":"<ul> <li>DELL:<ul> <li>S5232F-ON</li> </ul> </li> <li>Edge-Core:<ul> <li>DCS204 (AS7726-32X)</li> </ul> </li> </ul>"},{"location":"release-notes/#underlay-configuration","title":"Underlay configuration:","text":"<p>Port speed, port group speed, port breakouts are configurable through the API</p>"},{"location":"release-notes/#vpc-overlay-implementation","title":"VPC (overlay) Implementation","text":"<p>VXLAN-based BGP eVPN.</p>"},{"location":"release-notes/#multi-subnet-vpcs","title":"Multi-subnet VPCs","text":"<p>A VPC consists of subnets, each with a user-specified VLAN for external host/server connectivity.</p>"},{"location":"release-notes/#multiple-ip-address-namespaces","title":"Multiple IP address namespaces","text":"<p>Multiple IP address namespaces are supported per fabric. Each VPC belongs to the corresponding IPv4 namespace. There are no subnet overlaps within a single IPv4 namespace. IP address namespaces can mutually overlap.</p>"},{"location":"release-notes/#vlan-namespace","title":"VLAN Namespace","text":"<p>VLAN Namespaces guarantee the uniqueness of VLANs for a set of participating devices. Each switch belongs to a list of VLAN namespaces with non-overlapping VLAN ranges. Each VPC belongs to the VLAN namespace. There are no VLAN overlaps within a single VLAN namespace.</p> <p>This feature is useful when multiple VM-management domains (like separate VMware clusters connect to the fabric).</p>"},{"location":"release-notes/#switch-groups","title":"Switch Groups","text":"<p>Each switch belongs to a list of switch groups used for identifying redundancy groups for things like external connectivity.</p>"},{"location":"release-notes/#mutual-vpc-peering","title":"Mutual VPC Peering","text":"<p>VPC peering is supported and possible between a pair of VPCs that belong to the same IPv4 and VLAN namespaces.</p>"},{"location":"release-notes/#external-vpc-peering","title":"External VPC Peering","text":"<p>VPC peering provides the means of peering with external networking devices (edge routers, firewalls, or data center interconnects). VPC egress/ingress is pinned to a specific group of the border or mixed leaf switches. Multiple \u201cexternal systems\u201d with multiple devices/links in each of them are supported.</p> <p>The user controls what subnets/prefixes to import and export from/to the external system.</p> <p>No NAT function is supported for external peering.</p>"},{"location":"release-notes/#host-connectivity","title":"Host connectivity","text":"<p>Servers can be attached as Unbundled, Bundled (LAG) and MCLAG</p>"},{"location":"release-notes/#dhcp-service","title":"DHCP Service","text":"<p>VPC is provided with an optional DHCP service with simple IPAM</p>"},{"location":"release-notes/#local-vpc-peering-loopbacks","title":"Local VPC peering loopbacks","text":"<p>To enable local inter-vpc peering that allows routing of traffic between VPCs, local loopbacks are required to overcome silicon limitations.</p>"},{"location":"release-notes/#scale","title":"Scale","text":"<ul> <li>Maximum fabric size: 20 LEAF/ToR switches.</li> <li>Routes per switch: 64k</li> <li>[ silicon platform limitation in Trident 3; limits to number of endpoints in the fabric  ]</li> <li>Total VPCs per switch: up to 1000</li> <li>[ Including VPCs attached at the given switch and VPCs peered with ]</li> <li>Total VPCs per VLAN namespace: up to 3000</li> <li>[ assuming 1 subnet per VPC ]</li> <li>Total VPCs per fabric:  unlimited</li> <li>[ if using multiple VLAN namespaces ]</li> <li>VPC subnets per switch: up to 3000</li> <li>VPC subnets per VLAN namespace up to 3000</li> <li>Subnets per VPC: up to 20</li> <li>[ just a validation; the current design allows up to 100, but it could be increased even more in the future ]</li> <li>VPC Slots per remote peering @ switch: 2</li> <li>Max VPC loopbacks per switch: 500</li> <li>[ VPC loopback workarounds per switch are needed for local peering when both VPCs are attached to the switch or for external peering with VPC attached on the same switch that is peering with external ]</li> </ul>"},{"location":"release-notes/#software-versions_1","title":"Software versions","text":"<ul> <li>Fabric: v0.23.0</li> <li>Das-boot: v0.11.4</li> <li>Fabricator: v0.8.0</li> <li>K3s: v1.27.4-k3s1</li> <li>Zot: v1.4.3</li> <li>SONiC</li> <li>Broadcom Enterprise Base 4.1.1</li> <li>Broadcom Enterprise Campus 4.1.1</li> </ul>"},{"location":"release-notes/#known-limitations","title":"Known Limitations","text":"<ul> <li>MTU setting inflexibility:</li> <li>Fabric MTU is 9100 and not configurable right now (A3 planned)</li> <li>Server-facing MTU is 9136 and not configurable right now (A3+)</li> <li>no support for Access VLANs for attaching servers (A3 planned)</li> <li>VPC peering is enabled on all subnets of the participating VPCs. No subnet selection for peering. (A3 planned)</li> <li>peering with external is only possible with a VLAN (by design)</li> <li>If you have VPCs with remote peering on a switch group, you can't attach those VPCs on that switch group (by definition of remote peering)</li> <li>if a group of VPCs has remote peering on a switch group, any other VPC that will peer with those VPCs remotely will need to use the same switch group (by design)</li> <li>if VPC peers with external, it can only be remotely peered with on the same switches that have a connection to that external (by design)</li> <li>the server-facing connection object is immutable as it\u2019s very easy to get into a deadlock, re-create to change it (A3+)</li> </ul>"},{"location":"release-notes/#alpha-1","title":"Alpha-1","text":"<ul> <li> <p>Controller:</p> <ul> <li>A single controller connecting to each switch management port. No redundancy.</li> </ul> </li> <li> <p>Controller requirements:</p> <ul> <li>One 1 gig port per switch</li> <li>One+ 1 gig+ ports connecting to the external management network.</li> <li>4 Cores, 12GB RAM, 100GB SSD.</li> </ul> </li> <li> <p>Seeder:</p> <ul> <li>Seeder and Controller functions co-resident on the control node. Switch booting and ZTP on management ports directly connected to the controller.</li> </ul> </li> <li> <p>HHFab - the fabricator:</p> <ul> <li>An operational tool to generate, initiate, and maintain the fabric software appliance.  Allows fabrication of the environment-specific image with all of the required underlay and security configuration baked in.</li> </ul> </li> <li> <p>DHCP Service:</p> <ul> <li>A simple DHCP server for assigning IP addresses to hosts connecting to the fabric, optimized for use with VPC overlay.</li> </ul> </li> <li> <p>Topology:</p> <ul> <li>Support for a Collapsed Core topology with 2 switch nodes.</li> </ul> </li> <li> <p>Underlay:</p> <ul> <li>A simple single-VRF network with a BGP control plane.  IPv4 support only.</li> </ul> </li> <li> <p>External connectivity:</p> <ul> <li>An edge router must be connected to selected ports of one or both switches.  IPv4 support only.</li> </ul> </li> <li> <p>Dual-homing:</p> <ul> <li>L2 Dual homing with MCLAG is implemented to connect servers, storage, and other devices in the data center.  NIC bonding and LACP configuration at the host are required.</li> </ul> </li> <li> <p>VPC overlay implementation:</p> <ul> <li>VPC is implemented as a set of ACLs within the underlay VRF. External connectivity to the VRF is performed via internally managed VLANs.  IPv4 support only.</li> </ul> </li> <li> <p>VPC Peering:</p> <ul> <li>VPC peering is performed via ACLs with no fine-grained control.</li> </ul> </li> <li> <p>NAT</p> <ul> <li>DNAT + SNAT are supported per VPC. SNAT and DNAT can't be enabled per VPC simultaneously.</li> </ul> </li> <li> <p>Hardware support:</p> <ul> <li>Please see the supported hardware list.</li> </ul> </li> <li> <p>Virtual Lab:</p> <ul> <li>A simulation of the two-node Collapsed Core Topology as a virtual environment. Designed for use as a network simulation, a configuration scratchpad, or a training/demonstration tool.  Minimum requirements: 8 cores, 24GB RAM, 100GB SSD</li> </ul> </li> <li> <p>Limitations:</p> <ul> <li>40 VPCs max</li> <li>50 VPC peerings</li> <li>[ 768 ACL entry platform limitation from Broadcom ]</li> </ul> </li> <li> <p>Software versions:</p> <ul> <li>Fabricator: v0.5.2</li> <li>Fabric: v0.18.6</li> <li>Das-boot: v0.8.2</li> <li>K3s: v1.27.4-k3s1</li> <li>Zot: v1.4.3</li> <li>SONiC: Broadcom Enterprise Base 4.1.1</li> </ul> </li> </ul>"},{"location":"troubleshooting/overview/","title":"Troubleshooting","text":"<p>Under construction.</p>"},{"location":"user-guide/connections/","title":"Connections","text":"<p><code>Connection</code> objects represent logical and physical connections between the devices in the Fabric (<code>Switch</code>, <code>Server</code> and <code>External</code> objects) and are needed to define all the connections in the Wiring Diagram.</p> <p>All connections reference switch or server ports. Only port names defined by switch profiles can be used in the wiring diagram for the switches. NOS (or any other) port names aren't supported. Currently, server ports aren't validated by the Fabric API other than for uniqueness. See the Switch Profiles and Port Naming section for more details.</p> <p>There are several types of connections.</p>"},{"location":"user-guide/connections/#workload-server-connections","title":"Workload server connections","text":"<p>Server connections are used to connect workload servers to switches.</p>"},{"location":"user-guide/connections/#unbundled","title":"Unbundled","text":"<p>Unbundled server connections are used to connect servers to a single switch using a single port.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: server-4--unbundled--s5248-02\n  namespace: default\nspec:\n  unbundled:\n    link: # Defines a single link between a server and a switch\n      server:\n        port: server-4/enp2s1\n      switch:\n        port: s5248-02/Ethernet3\n</code></pre>"},{"location":"user-guide/connections/#bundled","title":"Bundled","text":"<p>Bundled server connections are used to connect servers to a single switch using multiple ports (port channel, LAG).</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: server-3--bundled--s5248-01\n  namespace: default\nspec:\n  bundled:\n    links: # Defines multiple links between a single server and a single switch\n    - server:\n        port: server-3/enp2s1\n      switch:\n        port: s5248-01/Ethernet3\n    - server:\n        port: server-3/enp2s2\n      switch:\n        port: s5248-01/Ethernet4\n</code></pre>"},{"location":"user-guide/connections/#mclag","title":"MCLAG","text":"<p>MCLAG server connections are used to connect servers to a pair of switches using multiple ports (Dual-homing). Switches should be configured as an MCLAG pair which requires them to be in a single redundancy group of type <code>mclag</code> and a Connection with type <code>mclag-domain</code> between them. MCLAG switches should also have the same <code>spec.ASN</code> and <code>spec.VTEPIP</code>.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: server-1--mclag--s5248-01--s5248-02\n  namespace: default\nspec:\n  mclag:\n    links: # Defines multiple links between a single server and a pair of switches\n    - server:\n        port: server-1/enp2s1\n      switch:\n        port: s5248-01/Ethernet1\n    - server:\n        port: server-1/enp2s2\n      switch:\n        port: s5248-02/Ethernet1\n</code></pre>"},{"location":"user-guide/connections/#eslag","title":"ESLAG","text":"<p>ESLAG server connections are used to connect servers to the 2-4 switches using multiple ports (Multi-homing). Switches should belong to the same redundancy group with type <code>eslag</code>, but contrary to the MCLAG case, no other configuration is required.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: server-1--eslag--s5248-01--s5248-02\n  namespace: default\nspec:\n  eslag:\n    links: # Defines multiple links between a single server and a 2-4 switches\n    - server:\n        port: server-1/enp2s1\n      switch:\n        port: s5248-01/Ethernet1\n    - server:\n        port: server-1/enp2s2\n      switch:\n        port: s5248-02/Ethernet1\n</code></pre>"},{"location":"user-guide/connections/#switch-connections-fabric-facing","title":"Switch connections (fabric-facing)","text":"<p>Switch connections are used to connect switches to each other and provide any needed \"service\" connectivity to implement the Fabric features.</p>"},{"location":"user-guide/connections/#fabric","title":"Fabric","text":"<p>A Fabric Connection is used between a specific pair of spine and leaf switches, representing all of the wires between them.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: s5232-01--fabric--s5248-01\n  namespace: default\nspec:\n  fabric:\n    links: # Defines multiple links between a spine-leaf pair of switches with IP addresses\n    - leaf:\n        ip: 172.30.30.1/31\n        port: s5248-01/Ethernet48\n      spine:\n        ip: 172.30.30.0/31\n        port: s5232-01/Ethernet0\n    - leaf:\n        ip: 172.30.30.3/31\n        port: s5248-01/Ethernet56\n      spine:\n        ip: 172.30.30.2/31\n        port: s5232-01/Ethernet4\n</code></pre>"},{"location":"user-guide/connections/#mclag-domain","title":"MCLAG-Domain","text":"<p>MCLAG-Domain connections define a pair of MCLAG switches with Session and Peer link between them. Switches should be configured as an MCLAG, pair which requires them to be in a single redundancy group of type <code>mclag</code> and Connection with type <code>mclag-domain</code> between them. MCLAG switches should also have the same <code>spec.ASN</code> and <code>spec.VTEPIP</code>.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: s5248-01--mclag-domain--s5248-02\n  namespace: default\nspec:\n  mclagDomain:\n    peerLinks: # Defines multiple links between a pair of MCLAG switches for Peer link\n    - switch1:\n        port: s5248-01/Ethernet72\n      switch2:\n        port: s5248-02/Ethernet72\n    - switch1:\n        port: s5248-01/Ethernet73\n      switch2:\n        port: s5248-02/Ethernet73\n    sessionLinks: # Defines multiple links between a pair of MCLAG switches for Session link\n    - switch1:\n        port: s5248-01/Ethernet74\n      switch2:\n        port: s5248-02/Ethernet74\n    - switch1:\n        port: s5248-01/Ethernet75\n      switch2:\n        port: s5248-02/Ethernet75\n</code></pre>"},{"location":"user-guide/connections/#vpc-loopback","title":"VPC-Loopback","text":"<p>VPC-Loopback connections are required in order to implement a workaround for the local VPC peering (when both VPC are attached to the same switch), which is caused by a hardware limitation of the currently supported switches.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: s5248-01--vpc-loopback\n  namespace: default\nspec:\n  vpcLoopback:\n    links: # Defines multiple loopbacks on a single switch\n    - switch1:\n        port: s5248-01/Ethernet16\n      switch2:\n        port: s5248-01/Ethernet17\n    - switch1:\n        port: s5248-01/Ethernet18\n      switch2:\n        port: s5248-01/Ethernet19\n</code></pre>"},{"location":"user-guide/connections/#connecting-fabric-to-the-outside-world","title":"Connecting Fabric to the outside world","text":"<p>Connections in this section provide connectivity to the outside world. For example, they can be connections to the Internet, to other networks, or to some other systems such as DHCP, NTP, LMA, or AAA services.</p>"},{"location":"user-guide/connections/#staticexternal","title":"StaticExternal","text":"<p><code>StaticExternal</code> connections provide a simple way to connect things like DHCP servers directly to the Fabric by connecting them to specific switch ports.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: third-party-dhcp-server--static-external--s5248-04\n  namespace: default\nspec:\n  staticExternal:\n    link:\n      switch:\n        port: s5248-04/Ethernet1 # Switch port to use\n        ip: 172.30.50.5/24 # IP address that will be assigned to the switch port\n        vlan: 1005 # Optional VLAN ID to use for the switch port; if 0, no VLAN is configured\n        subnets: # List of subnets to route to the switch port using static routes and next hop\n          - 10.99.0.1/24\n          - 10.199.0.100/32\n        nextHop: 172.30.50.1 # Next hop IP address to use when configuring static routes for the \"subnets\" list\n</code></pre> <p>Additionally, it's possible to configure <code>StaticExternal</code> within the VPC to provide access to the third-party resources within a specific VPC, with the rest of the YAML configuration remaining unchanged.</p> <pre><code>...\nspec:\n  staticExternal:\n    withinVPC: vpc-1 # VPC name to attach the static external to\n    link:\n      ...\n</code></pre>"},{"location":"user-guide/connections/#external","title":"External","text":"<p>Connection to external systems, such as edge/provider routers using BGP peering and configuring Inbound/Outbound communities as well as granularly controlling what gets advertised and which routes are accepted.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: s5248-03--external--5835\n  namespace: default\nspec:\n  external:\n    link: # Defines a single link between a switch and an external system\n      switch:\n        port: s5248-03/Ethernet3\n</code></pre>"},{"location":"user-guide/devices/","title":"Switches and Servers","text":"<p>All devices in a Hedgehog Fabric are divided into two groups: switches and servers, represented by the corresponding <code>Switch</code> and <code>Server</code> objects in the API. These objects are needed to define all of the participants of the Fabric and their roles in the Wiring Diagram, together with <code>Connection</code> objects (see Connections).</p>"},{"location":"user-guide/devices/#switches","title":"Switches","text":"<p>Switches are the main building blocks of the Fabric. They are represented by <code>Switch</code> objects in the API. These objects consist of basic metadata like name, description, role, serial, management port mac, as well as port group speeds, port breakouts, ASN, IP addresses, and more. Additionally, a <code>Switch</code> contains a reference to a <code>SwitchProfile</code> object that defines the switch model and capabilities. More details can be found in the Switch Profiles and Port Naming section.</p> <p>In order for the fabric to manage a switch the profile needs to include either the <code>serial</code> or <code>mac</code> need to be defined in the YAML doc.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Switch\nmetadata:\n  name: s5248-01\n  namespace: default\nspec:\n  boot: # at least one of the serial or mac needs to be defined\n    serial: XYZPDQ1234\n    mac: 00:11:22:33:44:55 # Usually the first management port MAC address\n  profile: dell-s5248f-on # Mandatory reference to the SwitchProfile object defining the switch model and capabilities\n  asn: 65101 # ASN of the switch\n  description: leaf-1\n  ip: 172.30.10.100/32 # Switch IP that will be accessible from the Control Node\n  portBreakouts: # Configures port breakouts for the switch, see the SwitchProfile for available options\n    E1/55: 4x25G\n  portGroupSpeeds: # Configures port group speeds for the switch, see the SwitchProfile for available options\n    \"1\": 10G\n    \"2\": 10G\n  portSpeeds: # Configures port speeds for the switch, see the SwitchProfile for available options\n    E1/1: 25G\n  protocolIP: 172.30.11.100/32 # Used as BGP router ID\n  role: server-leaf # Role of the switch, one of server-leaf, border-leaf and mixed-leaf\n  vlanNamespaces: # Defines which VLANs could be used to attach servers\n  - default\n  vtepIP: 172.30.12.100/32\n  groups: # Defines which groups the switch belongs to, by referring to SwitchGroup objects\n  - some-group\n  redundancy: # Optional field to define that switch belongs to the redundancy group\n    group: eslag-1 # Name of the redundancy group\n    type: eslag # Type of the redundancy group, one of mclag or eslag\n</code></pre> <p>The <code>SwitchGroup</code> is just a marker at that point and doesn't have any configuration options.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: SwitchGroup\nmetadata:\n  name: border\n  namespace: default\nspec: {}\n</code></pre>"},{"location":"user-guide/devices/#redundancy-groups","title":"Redundancy Groups","text":"<p>Redundancy groups are used to define the redundancy between switches. It's a regular <code>SwitchGroup</code> used by multiple switches and currently it could be MCLAG or ESLAG (EVPN MH / ESI). A switch can only belong to a single redundancy group.</p> <p>MCLAG is only supported for pairs of switches and ESLAG is supported for up to 4 switches. Multiple types of redundancy groups can be used in the fabric simultaneously.</p> <p>Connections with types <code>mclag</code> and <code>eslag</code> are used to define the servers connections to switches. They are only supported if the switch belongs to a redundancy group with the corresponding type.</p> <p>In order to define a MCLAG or ESLAG redundancy group, you need to create a <code>SwitchGroup</code> object and assign it to the switches using the <code>redundancy</code> field.</p> <p>Example of switch configured for ESLAG:</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: SwitchGroup\nmetadata:\n  name: eslag-1\n  namespace: default\nspec: {}\n---\napiVersion: wiring.githedgehog.com/v1beta1\nkind: Switch\nmetadata:\n  name: s5248-03\n  namespace: default\nspec:\n  ...\n  redundancy:\n    group: eslag-1\n    type: eslag\n  ...\n</code></pre> <p>And example of switch configured for MCLAG:</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: SwitchGroup\nmetadata:\n  name: mclag-1\n  namespace: default\nspec: {}\n---\napiVersion: wiring.githedgehog.com/v1beta1\nkind: Switch\nmetadata:\n  name: s5248-01\n  namespace: default\nspec:\n  ...\n  redundancy:\n    group: mclag-1\n    type: mclag\n  ...\n</code></pre> <p>In case of MCLAG it's required to have a special connection with type <code>mclag-domain</code> that defines the peer and session links between switches. For more details, see Connections.</p>"},{"location":"user-guide/devices/#servers","title":"Servers","text":"<p>Regular workload server:</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Server\nmetadata:\n  name: server-1\n  namespace: default\nspec:\n  description: MH s5248-01/E1 s5248-02/E1\n</code></pre>"},{"location":"user-guide/external/","title":"External Peering","text":"<p>Hedgehog Fabric uses the Border Leaf concept to exchange VPC routes outside the Fabric and provide L3 connectivity. The <code>External Peering</code> feature allows you to set up an external peering endpoint and to enforce several policies between internal and external endpoints.</p> <p>Note</p> <p>Hedgehog Fabric does not operate Edge side devices.</p>"},{"location":"user-guide/external/#overview","title":"Overview","text":"<p>Traffic exits from the Fabric on Border Leaves that are connected with Edge devices. Border Leaves are suitable to terminate L2VPN connections, to distinguish VPC L3 routable traffic towards Edge devices, and to land VPC servers. Border Leaves (or Borders) can connect to several Edge devices.</p> <p>Note</p> <p>External Peering is only available on the switch devices that are capable for sub-interfaces.</p>"},{"location":"user-guide/external/#connect-border-leaf-to-edge-device","title":"Connect Border Leaf to Edge device","text":"<p>In order to distinguish VPC 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>"},{"location":"user-guide/external/#control-plane","title":"Control Plane","text":"<p>The Fabric shares VPC routes with Edge devices via BGP. Peering is done over VLAN in IPv4 Unicast AFI/SAFI.</p>"},{"location":"user-guide/external/#data-plane","title":"Data Plane","text":"<p>VPC L3 routable traffic will be tagged with VLAN and sent to Edge device. Later processing of VPC traffic (NAT, PBR, etc) should happen on Edge devices.</p>"},{"location":"user-guide/external/#vpc-access-to-edge-device","title":"VPC access to Edge device","text":"<p>Each VPC within the Fabric can be allowed to access Edge devices. Additional filtering can be applied to the routes that the VPC can export to Edge devices and import from the Edge devices.</p>"},{"location":"user-guide/external/#api-and-implementation","title":"API and implementation","text":""},{"location":"user-guide/external/#external","title":"External","text":"<p>General configuration starts with the specification of <code>External</code> objects. Each object of <code>External</code> type can represent a set of Edge devices, or a single BGP instance on Edge device, or any other united Edge entities that can be described with the following configuration:</p> <ul> <li>Name of <code>External</code></li> <li>Inbound routes marked with the dedicated BGP community</li> <li>Outbound routes marked with the dedicated community</li> </ul> <p>Each <code>External</code> should be bound to some VPC IP Namespace, otherwise prefixes overlap may happen.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: External\nmetadata:\n  name: default--5835\nspec:\n  ipv4Namespace: # VPC IP Namespace\n  inboundCommunity: # BGP Standard Community of routes from Edge devices\n  outboundCommunity: # BGP Standard Community required to be assigned on prefixes advertised from Fabric\n</code></pre>"},{"location":"user-guide/external/#connection","title":"Connection","text":"<p>A <code>Connection</code> of type <code>external</code> is used to identify the switch port on Border leaf that is cabled with an Edge device.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: # specified or generated\nspec:\n  external:\n    link:\n      switch:\n        port: # SwitchName/EthernetXXX\n</code></pre>"},{"location":"user-guide/external/#external-attachment","title":"External Attachment","text":"<p><code>External Attachment</code> defines BGP Peering and traffic connectivity between a Border leaf and <code>External</code>. Attachments are bound to a <code>Connection</code> with type <code>external</code> and they specify an optional <code>vlan</code> that will be used to segregate particular Edge peering.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: ExternalAttachment\nmetadata:\n  name: #\nspec:\n  connection: # Name of the Connection with type external\n  external: # Name of the External to pick config\n  neighbor:\n    asn: # Edge device ASN\n    ip: # IP address of Edge device to peer with\n  switch:\n    ip: # IP address on the Border Leaf to set up BGP peering\n    vlan: # VLAN (optional) ID to tag control and data traffic, use 0 for untagged\n</code></pre> <p>Several <code>External Attachment</code> can be configured for the same <code>Connection</code> but for different <code>vlan</code>.</p>"},{"location":"user-guide/external/#external-vpc-peering","title":"External VPC Peering","text":"<p>To allow a specific VPC to have access to Edge devices, bind the VPC to a specific <code>External</code> object. To do so, define an <code>External Peering</code> object.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: ExternalPeering\nmetadata:\n  name: # Name of ExternalPeering\nspec:\n  permit:\n    external:\n      name: # External Name\n      prefixes: # List of prefixes (routes) to be allowed to pick up from External\n      - # IPv4 prefix\n    vpc:\n      name: # VPC Name\n      subnets: # List of VPC subnets name to be allowed to have access to External (Edge)\n      - # Name of the subnet within VPC\n</code></pre> <p><code>Prefixes</code> is the list of subnets to permit from the External to the VPC. It matches any prefix length less than or equal to 32, effectively permitting all prefixes within the specified one. Use <code>0.0.0.0/0</code> for any route, including the default route.</p> <p>This example allows any IPv4 prefix that came from <code>External</code>:</p> <pre><code>spec:\n  permit:\n    external:\n      name: ###\n      prefixes:\n      - prefix: 0.0.0.0/0 # Any route will be allowed including default route\n</code></pre> <p>This example allows all prefixes that match the default route, with any prefix length:</p> <pre><code>spec:\n  permit:\n    external:\n      name: ###\n      prefixes:\n      - prefix: 77.0.0.0/8 # Any route that belongs to the specified prefix is allowed (such as 77.0.0.0/8 or 77.1.2.0/24)\n</code></pre>"},{"location":"user-guide/external/#examples","title":"Examples","text":"<p>This example shows how to peer with the <code>External</code> object with name <code>HedgeEdge</code>, given a Fabric VPC with name <code>vpc-1</code> on the Border Leaf <code>switchBorder</code> that has a cable connecting it to an Edge device on the port <code>Ethernet42</code>. Specifying <code>vpc-1</code> is required to receive any prefixes advertised from the <code>External</code>.</p>"},{"location":"user-guide/external/#fabric-api-configuration","title":"Fabric API configuration","text":""},{"location":"user-guide/external/#external_1","title":"External","text":"<pre><code># kubectl fabric external create --name hedgeedge --ipns default --in 65102:5000 --out 5000:65102\n</code></pre> <pre><code>- apiVersion: vpc.githedgehog.com/v1beta1\n  kind: External\n  metadata:\n    creationTimestamp: \"2024-11-26T21:24:32Z\"\n    generation: 1\n    labels:\n      fabric.githedgehog.com/ipv4ns: default\n    name: hedgeedge\n    namespace: default\n    resourceVersion: \"57628\"\n    uid: a0662988-73d0-45b3-afc0-0d009cd91ebd\n  spec:\n    inboundCommunity: 65102:5000\n    ipv4Namespace: default\n    outboundCommunity: 5000:6510\n</code></pre>"},{"location":"user-guide/external/#connection_1","title":"Connection","text":"<p>Connection should be specified in the <code>wiring</code> diagram.</p> <pre><code>###\n### switchBorder--external--HedgeEdge\n###\napiVersion: wiring.githedgehog.com/v1beta1\nkind: Connection\nmetadata:\n  name: switchBorder--external--HedgeEdge\nspec:\n  external:\n    link:\n      switch:\n        port: switchBorder/Ethernet42\n</code></pre>"},{"location":"user-guide/external/#externalattachment","title":"ExternalAttachment","text":"<p>Specified in <code>wiring</code> diagram</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: ExternalAttachment\nmetadata:\n  name: switchBorder--HedgeEdge\nspec:\n  connection: switchBorder--external--HedgeEdge\n  external: HedgeEdge\n  neighbor:\n    asn: 65102\n    ip: 100.100.0.6\n  switch:\n    ip: 100.100.0.1/24\n    vlan: 100\n</code></pre>"},{"location":"user-guide/external/#externalpeering","title":"ExternalPeering","text":"<pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: ExternalPeering\nmetadata:\n  name: vpc-1--HedgeEdge\nspec:\n  permit:\n    external:\n      name: HedgeEdge\n      prefixes:\n      - prefix: 0.0.0.0/0\n    vpc:\n      name: vpc-1\n      subnets:\n      - default\n</code></pre>"},{"location":"user-guide/external/#example-edge-side-bgp-configuration-based-on-sonic-os","title":"Example Edge side BGP configuration based on SONiC OS","text":"<p>Warning</p> <p>Hedgehog does not recommend using the following configuration for production. It is only provided as an example of Edge Peer configuration.</p> <p>Interface configuration:</p> <pre><code>interface Ethernet2.100\n encapsulation dot1q vlan-id 100\n description switchBorder--Ethernet42\n no shutdown\n ip vrf forwarding VrfHedge\n ip address 100.100.0.6/24\n</code></pre> <p>BGP configuration:</p> <pre><code>!\nrouter bgp 65102 vrf VrfHedge\n log-neighbor-changes\n timers 60 180\n !\n address-family ipv4 unicast\n  maximum-paths 64\n  maximum-paths ibgp 1\n  import vrf VrfPublic\n !\n neighbor 100.100.0.1\n  remote-as 65103\n  !\n  address-family ipv4 unicast\n   activate\n   route-map HedgeIn in\n   route-map HedgeOut out\n   send-community both\n !\n</code></pre> <p>Route Map configuration:</p> <pre><code>route-map HedgeIn permit 10\n match community Hedgehog\n!\nroute-map HedgeOut permit 10\n set community 65102:5000\n!\n\nbgp community-list standard HedgeIn permit 5000:65102\n</code></pre>"},{"location":"user-guide/grafana/","title":"Grafana Dashboards","text":"<p>To provide monitoring for most critical metrics from the switches managed by Hedgehog Fabric there are several Dashboards that may be used in Grafana deployments. Make sure that you've enabled metrics and logs collection for the switches in the Fabric that is described in Fabric Config section.</p>"},{"location":"user-guide/grafana/#variables","title":"Variables","text":"<p>List of common variables used in Hedgehog Grafana dashboards</p> <ul> <li>env (Label: Env): <code>label_values(env)</code> - Environment to monitor</li> <li>node (Label: Switch): <code>label_values(hostname)</code> - Switch Name</li> <li>vrf (Label: VRF): <code>label_values(vrf)</code> - VRF name (Multi-value)</li> <li>neighbor (Label: Neighbor): <code>label_values(neighbor)</code> - BGP Neighbor IP address(Multi-value)</li> <li>interface (Label: Interface): <code>label_values(interface)</code> - Switch Interface name as defined in wiring (Multi-value)</li> <li>file (Label: File): <code>label_valuse(filename)</code> - Name of Logs file to inspect (Loki)</li> </ul>"},{"location":"user-guide/grafana/#switch-critical-resources","title":"Switch Critical Resources","text":"<p>This table reports usage and capacity of ASIC's programmable resources  such as:</p> <ul> <li>ACLs</li> <li>IPv4 Routes</li> <li>IPv4 Nexthops</li> <li>IPv4 Neihbours</li> <li>IPMC Table</li> <li>FDB</li> </ul> <p>JSON</p>"},{"location":"user-guide/grafana/#fabric","title":"Fabric","text":"<p>Fabric underlay and external peering monitoring. Including reporing for:</p> <ul> <li>BGP Neighbors</li> <li>BGP Session state</li> <li>Number of BGP Updates and Prefixes sent/received for each BGP Neighbor</li> <li>Keepalive counters</li> </ul> <p>JSON</p>"},{"location":"user-guide/grafana/#interfaces","title":"Interfaces","text":"<p>Switch interfaces monitoring visualization that includes:</p> <ul> <li>Interface Oper/Admin state</li> <li>Total input/output packets counter</li> <li>Input/output PPS/Bits rate</li> <li>Interface utilization</li> <li>Counters for Unicast/Broadcast/Multicast packets</li> <li>Errors and discards counters</li> </ul> <p>JSON</p>"},{"location":"user-guide/grafana/#logs","title":"Logs","text":"<p>System and fabric logs:</p> <ul> <li>Kernel and BGP logs from Syslog</li> <li>Errors in agent and syslog</li> <li>Full output of defined file</li> </ul> <p>JSON</p>"},{"location":"user-guide/grafana/#platform","title":"Platform","text":"<p>Information from PSU, temperature sensors and fan trays:</p> <ul> <li>Input/output PSU voltage</li> <li>Fan speed</li> <li>Temperature from switch sensors (CPU, PSU, etc)</li> <li>For transceivers with DOM - optic sensor temperature</li> </ul> <p>JSON</p>"},{"location":"user-guide/grafana/#node-exporter","title":"Node Exporter","text":"<p>Grafana Node Exporter Full is an opensource Grafana board that provide visualizations for monitoring Linux nodes. In particular case Node Exporter is used to track SONiC OS own stats such as</p> <ul> <li>Memory/disks usage</li> <li>CPU/System utilization</li> <li>Networking stats (traffic that hits SONiC interfaces) ...</li> </ul> <p>JSON</p>"},{"location":"user-guide/harvester/","title":"Using VPCs with Harvester","text":"<p>This section contains an example of how Hedgehog Fabric can be used with Harvester or any hypervisor on the servers connected to Fabric. It assumes that you have already installed Fabric and have some servers running Harvester attached to it.</p> <p>You need to define a <code>Server</code> object for each server running Harvester and a <code>Connection</code> object for each server connection to the switches.</p> <p>You can have multiple VPCs created and attached to the <code>Connections</code> to the servers to make them available to the VMs in Harvester or any other hypervisor.</p>"},{"location":"user-guide/harvester/#configure-harvester","title":"Configure Harvester","text":""},{"location":"user-guide/harvester/#add-a-cluster-network","title":"Add a Cluster Network","text":"<p>From the \"Cluster Networks/Configs\" side menu, create a new Cluster Network.</p> <p></p> <p>Here is a cleaned-up version of what the CRD looks like:</p> <pre><code>apiVersion: network.harvesterhci.io/v1beta1\nkind: ClusterNetwork\nmetadata:\n  name: testnet\n</code></pre>"},{"location":"user-guide/harvester/#add-a-network-config","title":"Add a Network Config","text":"<p>Click \"Create Network Config\". Add your connections and select the bonding type.</p> <p></p> <p>The resulting CRD (cleaned up) looks like the following:</p> <pre><code>apiVersion: network.harvesterhci.io/v1beta1\nkind: VlanConfig\nmetadata:\n  name: testconfig\n  labels:\n    network.harvesterhci.io/clusternetwork: testnet\nspec:\n  clusterNetwork: testnet\n  uplink:\n    bondOptions:\n      miimon: 100\n      mode: 802.3ad\n    linkAttributes:\n      txQLen: -1\n    nics:\n      - enp5s0f0\n      - enp3s0f1\n</code></pre>"},{"location":"user-guide/harvester/#add-vlan-based-vm-networks","title":"Add VLAN based VM Networks","text":"<p>Browse over to \"VM Networks\" and add one network for each VLAN you want to support. Assign them to the cluster network.</p> <p> </p> <p>Here is what the CRDs will look like for both VLANs:</p> <pre><code>apiVersion: k8s.cni.cncf.io/v1\nkind: NetworkAttachmentDefinition\nmetadata:\n  labels:\n    network.harvesterhci.io/clusternetwork: testnet\n    network.harvesterhci.io/ready: 'true'\n    network.harvesterhci.io/type: L2VlanNetwork\n    network.harvesterhci.io/vlan-id: '1001'\n  name: testnet1001\n  namespace: default\nspec:\n  config: &gt;-\n    {\"cniVersion\":\"0.3.1\",\"name\":\"testnet1001\",\"type\":\"bridge\",\"bridge\":\"testnet-br\",\"promiscMode\":true,\"vlan\":1001,\"ipam\":{}}\n</code></pre> <pre><code>apiVersion: k8s.cni.cncf.io/v1\nkind: NetworkAttachmentDefinition\nmetadata:\n  name: testnet1000\n  labels:\n    network.harvesterhci.io/clusternetwork: testnet\n    network.harvesterhci.io/ready: 'true'\n    network.harvesterhci.io/type: L2VlanNetwork\n    network.harvesterhci.io/vlan-id: '1000'\n    #  key: string\n  namespace: default\nspec:\n  config: &gt;-\n    {\"cniVersion\":\"0.3.1\",\"name\":\"testnet1000\",\"type\":\"bridge\",\"bridge\":\"testnet-br\",\"promiscMode\":true,\"vlan\":1000,\"ipam\":{}}\n</code></pre>"},{"location":"user-guide/harvester/#using-the-vpcs","title":"Using the VPCs","text":"<p>Now you can choose the new VM Networks when creating a VM in Harvester, and have them created as part of the VPC.</p>"},{"location":"user-guide/overview/","title":"Overview","text":"<p>This chapter gives an overview of the main features of Hedgehog Fabric and their usage.</p>"},{"location":"user-guide/profiles/","title":"Switch Profiles and Port Naming","text":""},{"location":"user-guide/profiles/#switch-profiles","title":"Switch Profiles","text":"<p>All supported switches have a <code>SwitchProfile</code> that defines the switch model, supported features, and available ports with supported configurations such as port group and speeds as well as port breakouts. <code>SwitchProfiles</code> available in-cluster or generated documentation can be found in the Reference section.</p> <p>Each switch used in the wiring diagram should have a <code>SwitchProfile</code> references in the <code>spec.profile</code> of the <code>Switch</code> object.</p> <p>Switch profile defines what features and ports are available on the switch. Based on the ports data in the profile, it's possible to set port speeds (for non-breakout and non-group ports), port group speeds and port breakout modes in the <code>Switch</code> object in the Fabric API.</p>"},{"location":"user-guide/profiles/#port-naming","title":"Port Naming","text":"<p>Each switch port is named using one of the the following formats:</p> <ul> <li> <p><code>M&lt;management-port-number&gt;</code></p> <ul> <li><code>&lt;management-port-number&gt;</code> is the management port number starting from <code>1</code> (usually only one named <code>1</code> for most   switches)</li> </ul> </li> <li> <p><code>E&lt;asic-or-chassis-number&gt;/&lt;port-number&gt;[/&lt;breakout&gt;][.&lt;subinterface.]</code></p> <ul> <li><code>&lt;asic-or-chassis-number&gt;</code> is the ASIC or chassis number (usually only one named <code>1</code> for the most switches)</li> <li><code>&lt;port-number&gt;</code> is the port number on the ASIC or chassis, starting from <code>1</code></li> <li>optional <code>/&lt;breakout&gt;</code> is the breakout number for the port, starting from <code>1</code>, only for breakout ports and always consecutive numbers independent of the lanes allocation and other implementation details</li> <li>optional <code>.&lt;subinterface&gt;</code> is the subinterface number for the port</li> </ul> </li> </ul> <p>Examples of port names:</p> <ul> <li><code>M1</code> - management port</li> <li><code>E1/1</code> - port <code>1</code> on the ASIC or chassis <code>1</code>, usually a first port on the switch</li> <li><code>E1/55/1</code> - first breakout port of the switch port <code>55</code> on the ASIC or chassis <code>1</code></li> </ul>"},{"location":"user-guide/profiles/#available-ports","title":"Available Ports","text":"<p>Each switch profile defines a set of ports available on the switch. Ports could be divided into the following types.</p>"},{"location":"user-guide/profiles/#directly-configurable-ports","title":"Directly configurable ports","text":"<p>Non-breakout and non-group ports. Would have a reference to the port profile with default and available speeds. Could be configured by setting the speed in the <code>Switch</code> object in the Fabric API:</p> <pre><code>.spec:\n  portSpeeds:\n    E1/1: 25G\n</code></pre>"},{"location":"user-guide/profiles/#port-groups","title":"Port groups","text":"<p>Ports that belong to a port group, non-breakout and not directly configurable. Would have a reference to the port group which will have a reference to the port profile with default and available speeds. Port couldn't be configured directly, speed configuration is applied to the whole group in the <code>Switch</code> object in the Fabric API:</p> <pre><code>.spec:\n  portGroupSpeeds:\n    \"1\": 10G\n</code></pre> <p>It'll set the speed of all ports in the group <code>1</code> to <code>10G</code>, e.g. if the group <code>1</code> contains ports <code>E1/1</code>, <code>E1/2</code>, <code>E1/3</code> and <code>E1/4</code>, all of them will be set to <code>10G</code> speed.</p>"},{"location":"user-guide/profiles/#breakout-ports","title":"Breakout ports","text":"<p>Ports that are breakouts and non-group ports. Would have a reference to the port profile with default and available breakout modes. Could be configured by setting the breakout mode in the <code>Switch</code> object in the Fabric API:</p> <pre><code>.spec:\n  portBreakouts:\n    E1/55: 4x25G\n</code></pre> <p>Configuring a port breakout mode will make \"breakout\" ports available for use in the wiring diagram. The breakout ports are named as <code>E&lt;asic-or-chassis-number&gt;/&lt;port-number&gt;/&lt;breakout&gt;</code>, e.g. <code>E1/55/1</code>, <code>E1/55/2</code>, <code>E1/55/3</code>, <code>E1/55/4</code> for the example above. Omitting the breakout number is allowed for the first breakout port, e.g. <code>E1/55</code> is the same as <code>E1/55/1</code>. The breakout ports are always consecutive numbers independent of the lanes allocation and other implementation details.</p>"},{"location":"user-guide/shrink-expand/","title":"Fabric Shrink/Expand","text":"<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 cabled and connected.</p> <p>This article uses terms that can be found in the Hedgehog Concepts, the User Guide documentation, and the Fabric API reference.</p>"},{"location":"user-guide/shrink-expand/#add-a-switch-to-the-existing-fabric","title":"Add a switch to the existing fabric","text":"<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 User Guide.</p> <p>Note</p> <p>If the<code>Switch</code> will be used in <code>ESLAG</code> or <code>MCLAG</code> groups, appropriate groups should exist. Redundancy groups should be specified in the <code>Switch</code> object before creation.</p> <p>After the <code>Switch</code> object has been created, you can define and create dedicated device <code>Connections</code>. The types of the connections may differ based on the <code>Switch</code> role given to the device. For more details, refer to Connections section.</p> <p>Note</p> <p>Switch devices should be booted in <code>ONIE</code> installation mode to install SONiC OS and configure the Fabric Agent.</p> <p>Ensure the management port of the switch is connected to fabric management network.</p>"},{"location":"user-guide/shrink-expand/#remove-a-switch-from-the-existing-fabric","title":"Remove a switch from the existing fabric","text":"<p>Before you decommission a switch from the Hedgehog Fabric, several preparation steps are necessary.</p> <p>Warning</p> <p>Currently the <code>Wiring</code> diagram used for initial deployment is saved in <code>/var/lib/rancher/k3s/server/manifests/hh-wiring.yaml</code> on the <code>Control</code> node. Fabric will sustain objects within the original wiring diagram. In order to remove any object, first remove the dedicated API objects from this file. It is recommended to reapply <code>hh-wiring.yaml</code> after changing its internals.</p> <ul> <li>If the <code>Switch</code> is a <code>Leaf</code> switch (including <code>Mixed</code> and <code>Border</code> leaf configurations), remove all <code>VPCAttachments</code> bound to all switches <code>Connections</code>.</li> <li>If the <code>Switch</code> was used for <code>ExternalPeering</code>, remove all <code>ExternalAttachment</code> objects that are bound to the <code>Connections</code> of the <code>Switch</code>.</li> <li>Remove all connections of the <code>Switch</code>.</li> <li>At last, remove the <code>Switch</code> and <code>Agent</code> objects.</li> </ul>"},{"location":"user-guide/vpcs/","title":"VPCs and Namespaces","text":""},{"location":"user-guide/vpcs/#vpc","title":"VPC","text":"<p>A Virtual Private Cloud (VPC) is similar to a public cloud VPC. It provides an isolated private network with support for multiple subnets, each with user-defined VLANs and optional DHCP services.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: VPC\nmetadata:\n  name: vpc-1\n  namespace: default\nspec:\n  ipv4Namespace: default # Limits which subnets can the VPC use to guarantee non-overlapping IPv4 ranges\n  vlanNamespace: default # Limits which Vlan Ids can the VPC use to guarantee non-overlapping VLANs\n\n  defaultIsolated: true # Sets default behavior for the current VPC subnets to be isolated\n  defaultRestricted: true # Sets default behavior for the current VPC subnets to be restricted\n\n  subnets:\n    default: # Each subnet is named, \"default\" subnet isn't required, but actively used by CLI\n      dhcp:\n        enable: true # On-demand DHCP server\n        range: # Optionally, start/end range could be specified, otherwise all available IPs are used\n          start: 10.10.1.10\n          end: 10.10.1.99\n        options: # Optional, additional DHCP options to enable for DHCP server, only available when enable is true\n          pxeURL: tftp://10.10.10.99/bootfilename # PXEURL (optional) to identify the PXE server to use to boot hosts; HTTP query strings are not supported\n          dnsServers: # (optional) configure DNS servers\n            - 1.1.1.1\n          timeServers: # (optional) configure Time (NTP) Servers\n            - 1.1.1.1\n          interfaceMTU: 1500 # (optional) configure the MTU (default is 9036); doesn't affect the actual MTU of the switch interfaces\n      subnet: 10.10.1.0/24 # User-defined subnet from ipv4 namespace\n      gateway: 10.10.1.1 # User-defined gateway (optional, default is .1)\n      vlan: 1001 # User-defined VLAN from VLAN namespace\n      isolated: true # Makes subnet isolated from other subnets within the VPC (doesn't affect VPC peering)\n      restricted: true # Causes all hosts in the subnet to be isolated from each other\n\n    thrird-party-dhcp: # Another subnet\n      dhcp:\n        relay: 10.99.0.100/24 # Use third-party DHCP server (DHCP relay configuration), access to it could be enabled using StaticExternal connection\n      subnet: \"10.10.2.0/24\"\n      vlan: 1002\n\n    another-subnet: # Minimal configuration is just a name, subnet and VLAN\n      subnet: 10.10.100.0/24\n      vlan: 1100\n\n  permit: # Defines which subnets of the current VPC can communicate to each other, applied on top of subnets \"isolated\" flag (doesn't affect VPC peering)\n    - [subnet-1, subnet-2, subnet-3] # 1, 2 and 3 subnets can communicate to each other\n    - [subnet-4, subnet-5] # Possible to define multiple lists\n\n  staticRoutes: # Optional, static routes to be added to the VPC\n    - prefix: 10.100.0.0/24 # Destination prefix\n      nextHops: # Next hop IP addresses\n        - 10.200.0.0\n</code></pre>"},{"location":"user-guide/vpcs/#isolated-and-restricted-subnets-permit-lists","title":"Isolated and restricted subnets, permit lists","text":"<p>Subnets can be isolated and restricted, with the ability to define permit lists to allow communication between specific isolated subnets. The permit list is applied on top of the isolated flag and doesn't affect VPC peering.</p> <p>Isolated subnet means that the subnet has no connectivity with other subnets within the VPC, but it could still be allowed by permit lists.</p> <p>Restricted subnet means that all hosts in the subnet are isolated from each other within the subnet.</p> <p>A Permit list contains a list. Every element of the list is a set of subnets that can communicate with each other.</p>"},{"location":"user-guide/vpcs/#third-party-dhcp-server-configuration","title":"Third-party DHCP server configuration","text":"<p>In case you use a third-party DHCP server, by configuring <code>spec.subnets.&lt;subnet&gt;.dhcp.relay</code>, additional information is added to the DHCP packet forwarded to the DHCP server to make it possible to identify the VPC and subnet. This information is added under the RelayAgentInfo (option 82) in the DHCP packet. The relay sets two suboptions in the packet:</p> <ul> <li>VirtualSubnetSelection (suboption 151) is populated with the VRF which uniquely identifies a VPC on the Hedgehog   Fabric and will be in <code>VrfV&lt;VPC-name&gt;</code> format, for example <code>VrfVvpc-1</code> for a VPC named <code>vpc-1</code> in the Fabric API.</li> <li>CircuitID (suboption 1) identifies the VLAN which, together with the VRF (VPC) name, maps to a specific VPC subnet.</li> </ul>"},{"location":"user-guide/vpcs/#vpcattachment","title":"VPCAttachment","text":"<p>A VPCAttachment represents a specific VPC subnet assignment to the <code>Connection</code> object which means a binding between an exact server port and a VPC. It basically leads to the VPC being available on the specific server port(s) on a subnet VLAN.</p> <p>VPC could be attached to a switch that is part of the VLAN namespace used by the VPC.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: VPCAttachment\nmetadata:\n  name: vpc-1-server-1--mclag--s5248-01--s5248-02\n  namespace: default\nspec:\n  connection: server-1--mclag--s5248-01--s5248-02 # Connection name representing the server port(s)\n  subnet: vpc-1/default # VPC subnet name\n  nativeVLAN: true # (Optional) if true, the port will be configured as a native VLAN port (untagged)\n</code></pre>"},{"location":"user-guide/vpcs/#vpcpeering","title":"VPCPeering","text":"<p>A VPCPeering enables VPC-to-VPC connectivity. There are two types of VPC peering:</p> <ul> <li>Local: peering is implemented on the same switches where VPCs are attached</li> <li>Remote: peering is implemented on the border/mixed leaves defined by the <code>SwitchGroup</code> object</li> </ul> <p>VPC peering is only possible between VPCs attached to the same IPv4 namespace (see IPv4Namespace)</p>"},{"location":"user-guide/vpcs/#local-vpc-peering","title":"Local VPC peering","text":"<pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: VPCPeering\nmetadata:\n  name: vpc-1--vpc-2\n  namespace: default\nspec:\n  permit: # Defines a pair of VPCs to peer\n  - vpc-1: {} # Meaning all subnets of two VPCs will be able to communicate with each other\n    vpc-2: {} # See \"Subnet filtering\" for more advanced configuration\n</code></pre>"},{"location":"user-guide/vpcs/#remote-vpc-peering","title":"Remote VPC peering","text":"<pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: VPCPeering\nmetadata:\n  name: vpc-1--vpc-2\n  namespace: default\nspec:\n  permit:\n  - vpc-1: {}\n    vpc-2: {}\n  remote: border # Indicates a switch group to implement the peering on\n</code></pre>"},{"location":"user-guide/vpcs/#subnet-filtering","title":"Subnet filtering","text":"<p>It's possible to specify which specific subnets of the peering VPCs could communicate to each other using the <code>permit</code> field.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: VPCPeering\nmetadata:\n  name: vpc-1--vpc-2\n  namespace: default\nspec:\n  permit: # subnet-1 and subnet-2 of vpc-1 could communicate to subnet-3 of vpc-2 as well as subnet-4 of vpc-2 could communicate to subnet-5 and subnet-6 of vpc-2\n  - vpc-1:\n      subnets: [subnet-1, subnet-2]\n    vpc-2:\n      subnets: [subnet-3]\n  - vpc-1:\n      subnets: [subnet-4]\n    vpc-2:\n      subnets: [subnet-5, subnet-6]\n</code></pre>"},{"location":"user-guide/vpcs/#ipv4namespace","title":"IPv4Namespace","text":"<p>An <code>IPv4Namespace</code> defines a set of (non-overlapping) IPv4 address ranges available for use by VPC subnets. Each VPC belongs to a specific IPv4 namespace. Therefore, its subnet prefixes must be from that IPv4 namespace.</p> <pre><code>apiVersion: vpc.githedgehog.com/v1beta1\nkind: IPv4Namespace\nmetadata:\n  name: default\n  namespace: default\nspec:\n  subnets: # List of prefixes that VPCs can pick their subnets from\n  - 10.10.0.0/16\n</code></pre>"},{"location":"user-guide/vpcs/#vlannamespace","title":"VLANNamespace","text":"<p>A <code>VLANNamespace</code> defines a set of VLAN ranges available for attaching servers to switches. Each switch can belong to one or more disjoint VLANNamespaces.</p> <pre><code>apiVersion: wiring.githedgehog.com/v1beta1\nkind: VLANNamespace\nmetadata:\n  name: default\n  namespace: default\nspec:\n  ranges: # List of VLAN ranges that VPCs can pick their subnet VLANs from\n  - from: 1000\n    to: 2999\n</code></pre>"},{"location":"vlab/demo/","title":"Demo on VLAB","text":""},{"location":"vlab/demo/#goals","title":"Goals","text":"<p>The goal of this demo is to show how to use VPCs, attach and peer them and run test connectivity between the servers. Examples are based on the default VLAB topology.</p> <p>You can find instructions on how to setup VLAB in the Overview and Running VLAB sections.</p>"},{"location":"vlab/demo/#default-topology","title":"Default topology","text":"<p>The default topology is Spine-Leaf with 2 spines, 2 MCLAG leaves, 2 ESLAG leaves and 1 non-MCLAG leaf. Optionally, you can choose to run the default Collapsed Core topology using flag <code>--fabric-mode collapsed-core</code> (or <code>-m collapsed-core</code>) which only consists of 2 switches.</p> <p>For more details on customizing topologies see the Running VLAB section.</p> <p>In the default topology, the following Control Node and Switch VMs are created, the Control Node is connected to every switch, the lines are ommitted for clarity:</p> <pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n\n    L1([MCLAG Leaf 1])\n    L2([MCLAG Leaf 2])\n    L3([ESLAG Leaf 3])\n    L4([ESLAG Leaf 4])\n    L5([Leaf 5])\n\n\n    L1 &amp; L2 &amp; L5 &amp; L3 &amp; L4 --&gt; S1 &amp; S2</code></pre> <p>As well as the following test servers, as above Control Node connections are omitted:</p> <pre><code>graph TD\n    S1([Spine 1])\n    S2([Spine 2])\n    L1([MCLAG Leaf 1])\n    L2([MCLAG Leaf 2])\n    L3([ESLAG Leaf 3])\n    L4([ESLAG Leaf 4])\n    L5([Leaf 5])\n\n    TS1[Server 1]\n    TS2[Server 2]\n    TS3[Server 3]\n    TS4[Server 4]\n    TS5[Server 5]\n    TS6[Server 6]\n    TS7[Server 7]\n    TS8[Server 8]\n    TS9[Server 9]\n    TS10[Server 10]\n\n    subgraph MCLAG\n    L1\n    L2\n    end\n    TS3 --&gt; L1\n    TS1 --&gt; L1\n    TS1 --&gt; L2\n\n    TS2 --&gt; L1\n    TS2 --&gt; L2\n\n    TS4 --&gt; L2\n\n    subgraph ESLAG\n    L3\n    L4\n    end\n\n    TS7 --&gt; L3\n    TS5 --&gt; L3\n    TS5 --&gt; L4\n    TS6 --&gt; L3\n    TS6 --&gt; L4\n\n    TS8 --&gt; L4\n    TS9 --&gt; L5\n    TS10 --&gt; L5\n\n    L1 &amp; L2 &amp; L2 &amp; L3 &amp; L4 &amp; L5 &lt;----&gt; S1 &amp; S2</code></pre>"},{"location":"vlab/demo/#utility-based-vpc-creation","title":"Utility based VPC creation","text":""},{"location":"vlab/demo/#setup-vpcs","title":"Setup VPCs","text":"<p><code>hhfab vlab</code> includes a utility to create VPCs in vlab. This utility is a <code>hhfab vlab</code> sub-command. <code>hhfab vlab setup-vpcs</code>.</p> <pre><code>NAME:\n   hhfab vlab setup-vpcs - setup VPCs and VPCAttachments for all servers and configure networking on them\n\nUSAGE:\n   hhfab vlab setup-vpcs [command options]\n\nOPTIONS:\n   --dns-servers value, --dns value [ --dns-servers value, --dns value ]    DNS servers for VPCs advertised by DHCP\n   --force-clenup, -f                                                       start with removing all existing VPCs and VPCAttachments (default: false)\n   --help, -h                                                               show help\n   --interface-mtu value, --mtu value                                       interface MTU for VPCs advertised by DHCP (default: 0)\n   --ipns value                                                             IPv4 namespace for VPCs (default: \"default\")\n   --name value, -n value                                                   name of the VM or HW to access\n   --servers-per-subnet value, --servers value                              number of servers per subnet (default: 1)\n   --subnets-per-vpc value, --subnets value                                 number of subnets per VPC (default: 1)\n   --time-servers value, --ntp value [ --time-servers value, --ntp value ]  Time servers for VPCs advertised by DHCP\n   --vlanns value                                                           VLAN namespace for VPCs (default: \"default\")\n   --wait-switches-ready, --wait                                            wait for switches to be ready before and after configuring VPCs and VPCAttachments (default: true)\n\n   Global options:\n\n   --brief, -b      brief output (only warn and error) (default: false) [$HHFAB_BRIEF]\n   --cache-dir DIR  use cache dir DIR for caching downloaded files (default: \"/home/ubuntu/.hhfab-cache\") [$HHFAB_CACHE_DIR]\n   --verbose, -v    verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]\n   --workdir PATH   run as if hhfab was started in PATH instead of the current working directory (default: \"/home/ubuntu\") [$HHFAB_WORK_DIR]\n</code></pre>"},{"location":"vlab/demo/#setup-peering","title":"Setup Peering","text":"<p><code>hhfab vlab</code> includes a utility to create VPC peerings in VLAB. This utility is a <code>hhfab vlab</code> sub-command. <code>hhfab vlab setup-peerings</code>.</p> <pre><code>NAME:\n   hhfab vlab setup-peerings - setup VPC and External Peerings per requests (remove all if empty)\n\nUSAGE:\n   Setup test scenario with VPC/External Peerings by specifying requests in the format described below.\n\n   Example command:\n\n   $ hhfab vlab setup-peerings 1+2 2+4:r=border 1~as5835 2~as5835:subnets=sub1,sub2:prefixes=0.0.0.0/0,22.22.22.0/24\n\n   Which will produce:\n   1. VPC peering between vpc-01 and vpc-02\n   2. Remote VPC peering between vpc-02 and vpc-04 on switch group named border\n   3. External peering for vpc-01 with External as5835 with default vpc subnet and any routes from external permitted\n   4. External peering for vpc-02 with External as5835 with subnets sub1 and sub2 exposed from vpc-02 and default route\n      from external permitted as well any route that belongs to 22.22.22.0/24\n\n   VPC Peerings:\n\n   1+2 -- VPC peering between vpc-01 and vpc-02\n   demo-1+demo-2 -- VPC peering between demo-1 and demo-2\n   1+2:r -- remote VPC peering between vpc-01 and vpc-02 on switch group if only one switch group is present\n   1+2:r=border -- remote VPC peering between vpc-01 and vpc-02 on switch group named border\n   1+2:remote=border -- same as above\n\n   External Peerings:\n\n   1~as5835 -- external peering for vpc-01 with External as5835\n   1~ -- external peering for vpc-1 with external if only one external is present for ipv4 namespace of vpc-01, allowing\n     default subnet and any route from external\n   1~:subnets=default@prefixes=0.0.0.0/0 -- external peering for vpc-1 with auth external with default vpc subnet and\n     default route from external permitted\n   1~as5835:subnets=default,other:prefixes=0.0.0.0/0_le32_ge32,22.22.22.0/24 -- same but with more details\n   1~as5835:s=default,other:p=0.0.0.0/0_le32_ge32,22.22.22.0/24 -- same as above\n\nOPTIONS:\n   --help, -h                     show help\n   --name value, -n value         name of the VM or HW to access\n   --wait-switches-ready, --wait  wait for switches to be ready before before and after configuring peerings (default: true)\n\n   Global options:\n\n   --brief, -b      brief output (only warn and error) (default: false) [$HHFAB_BRIEF]\n   --cache-dir DIR  use cache dir DIR for caching downloaded files (default: \"/home/ubuntu/.hhfab-cache\") [$HHFAB_CACHE_DIR]\n   --verbose, -v    verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]\n   --workdir PATH   run as if hhfab was started in PATH instead of the current working directory (default: \"/home/ubuntu\") [$HHFAB_WORK_DIR]\n</code></pre>"},{"location":"vlab/demo/#test-connectivity","title":"Test Connectivity","text":"<p><code>hhfab vlab</code> includes a utility to test connectivity between servers inside VLAB. This utility is a <code>hhfab vlab</code> sub-command. <code>hhfab vlab test-connectivity</code>.</p> <pre><code>NAME:\n   hhfab vlab test-connectivity - test connectivity between all servers\n\nUSAGE:\n   hhfab vlab test-connectivity [command options]\n\nOPTIONS:\n   --curls value                  number of curl tests to run for each server to test external connectivity (0 to disable) (default: 3)\n   --help, -h                     show help\n   --iperfs value                 seconds of iperf3 test to run between each pair of reachable servers (0 to disable) (default: 10)\n   --iperfs-speed value           minimum speed in Mbits/s for iperf3 test to consider successful (0 to not check speeds) (default: 7000)\n   --name value, -n value         name of the VM or HW to access\n   --pings value                  number of pings to send between each pair of servers (0 to disable) (default: 5)\n   --wait-switches-ready, --wait  wait for switches to be ready before testing connectivity (default: true)\n\n   Global options:\n\n   --brief, -b      brief output (only warn and error) (default: false) [$HHFAB_BRIEF]\n   --cache-dir DIR  use cache dir DIR for caching downloaded files (default: \"/home/ubuntu/.hhfab-cache\") [$HHFAB_CACHE_DIR]\n   --verbose, -v    verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]\n   --workdir PATH   run as if hhfab was started in PATH instead of the current working directory (default: \"/home/ubuntu\") [$HHFAB_WORK_DIR]\n</code></pre>"},{"location":"vlab/demo/#manual-vpc-creation","title":"Manual VPC creation","text":""},{"location":"vlab/demo/#creating-and-attaching-vpcs","title":"Creating and attaching VPCs","text":"<p>You can create and attach VPCs to the VMs using the <code>kubectl fabric vpc</code> command on the Control Node or outside of the cluster using the kubeconfig. For example, run the following commands to create 2 VPCs with a single subnet each, a DHCP server enabled with its optional IP address range start defined, and to attach them to some of the test servers:</p> <pre><code>core@control-1 ~ $ kubectl get conn | grep server\nserver-01--mclag--leaf-01--leaf-02   mclag          5h13m\nserver-02--mclag--leaf-01--leaf-02   mclag          5h13m\nserver-03--unbundled--leaf-01        unbundled      5h13m\nserver-04--bundled--leaf-02          bundled        5h13m\nserver-05--unbundled--leaf-03        unbundled      5h13m\nserver-06--bundled--leaf-03          bundled        5h13m\n\ncore@control-1 ~ $ kubectl fabric vpc create --name vpc-1 --subnet 10.0.1.0/24 --vlan 1001 --dhcp --dhcp-start 10.0.1.10\n06:48:46 INF VPC created name=vpc-1\n\ncore@control-1 ~ $ kubectl fabric vpc create --name vpc-2 --subnet 10.0.2.0/24 --vlan 1002 --dhcp --dhcp-start 10.0.2.10\n06:49:04 INF VPC created name=vpc-2\n\ncore@control-1 ~ $ kubectl fabric vpc attach --vpc-subnet vpc-1/default --connection server-01--mclag--leaf-01--leaf-02\n06:49:24 INF VPCAttachment created name=vpc-1--default--server-01--mclag--leaf-01--leaf-02\n\ncore@control-1 ~ $ kubectl fabric vpc attach --vpc-subnet vpc-2/default --connection server-02--mclag--leaf-01--leaf-02\n06:49:34 INF VPCAttachment created name=vpc-2--default--server-02--mclag--leaf-01--leaf-02\n</code></pre> <p>The VPC subnet should belong to an IPv4Namespace, the default one in the VLAB is <code>10.0.0.0/16</code>:</p> <pre><code>core@control-1 ~ $ kubectl get ipns\nNAME      SUBNETS           AGE\ndefault   [\"10.0.0.0/16\"]   5h14m\n</code></pre> <p>After you created the VPCs and VPCAttachments, you can check the status of the agents to make sure that the requested configuration was applied to the switches:</p> <pre><code>core@control-1 ~ $ kubectl get agents\nNAME       ROLE          DESCR           APPLIED   APPLIEDG   CURRENTG   VERSION\nleaf-01    server-leaf   VS-01 MCLAG 1   2m2s      5          5          v0.23.0\nleaf-02    server-leaf   VS-02 MCLAG 1   2m2s      4          4          v0.23.0\nleaf-03    server-leaf   VS-03           112s      5          5          v0.23.0\nspine-01   spine         VS-04           16m       3          3          v0.23.0\nspine-02   spine         VS-05           18m       4          4          v0.23.0\n</code></pre> <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>"},{"location":"vlab/demo/#setting-up-networking-on-test-servers","title":"Setting up networking on test servers","text":"<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 pre-installed by Fabricator on test servers, <code>hhnet</code>.</p> <p>For <code>server-01</code>:</p> <pre><code>core@server-01 ~ $ hhnet cleanup\ncore@server-01 ~ $ hhnet bond 1001 enp2s1 enp2s2\n10.0.1.10/24\ncore@server-01 ~ $ ip a\n...\n3: enp2s1: &lt;BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000\n    link/ether 06:5a:e8:38:3b:ea brd ff:ff:ff:ff:ff:ff permaddr 0c:20:12:fe:01:01\n4: enp2s2: &lt;BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000\n    link/ether 06:5a:e8:38:3b:ea brd ff:ff:ff:ff:ff:ff permaddr 0c:20:12:fe:01:02\n6: bond0: &lt;BROADCAST,MULTICAST,MASTER,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP group default qlen 1000\n    link/ether 06:5a:e8:38:3b:ea brd ff:ff:ff:ff:ff:ff\n    inet6 fe80::45a:e8ff:fe38:3bea/64 scope link\n       valid_lft forever preferred_lft forever\n7: bond0.1001@bond0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP group default qlen 1000\n    link/ether 06:5a:e8:38:3b:ea brd ff:ff:ff:ff:ff:ff\n    inet 10.0.1.10/24 metric 1024 brd 10.0.1.255 scope global dynamic bond0.1001\n       valid_lft 86396sec preferred_lft 86396sec\n    inet6 fe80::45a:e8ff:fe38:3bea/64 scope link\n       valid_lft forever preferred_lft forever\n</code></pre> <p>And for <code>server-02</code>:</p> <pre><code>core@server-02 ~ $ hhnet cleanup\ncore@server-02 ~ $ hhnet bond 1002 enp2s1 enp2s2\n10.0.2.10/24\ncore@server-02 ~ $ ip a\n...\n3: enp2s1: &lt;BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000\n    link/ether 5e:10:b1:f7:d0:4c brd ff:ff:ff:ff:ff:ff permaddr 0c:20:12:fe:02:01\n4: enp2s2: &lt;BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000\n    link/ether 5e:10:b1:f7:d0:4c brd ff:ff:ff:ff:ff:ff permaddr 0c:20:12:fe:02:02\n8: bond0: &lt;BROADCAST,MULTICAST,MASTER,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP group default qlen 1000\n    link/ether 5e:10:b1:f7:d0:4c brd ff:ff:ff:ff:ff:ff\n    inet6 fe80::5c10:b1ff:fef7:d04c/64 scope link\n       valid_lft forever preferred_lft forever\n9: bond0.1002@bond0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc noqueue state UP group default qlen 1000\n    link/ether 5e:10:b1:f7:d0:4c brd ff:ff:ff:ff:ff:ff\n    inet 10.0.2.10/24 metric 1024 brd 10.0.2.255 scope global dynamic bond0.1002\n       valid_lft 86185sec preferred_lft 86185sec\n    inet6 fe80::5c10:b1ff:fef7:d04c/64 scope link\n       valid_lft forever preferred_lft forever\n</code></pre>"},{"location":"vlab/demo/#testing-connectivity-before-peering","title":"Testing connectivity before peering","text":"<p>You can test connectivity between the servers before peering the switches using the <code>ping</code> command:</p> <pre><code>core@server-01 ~ $ ping 10.0.2.10\nPING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.\nFrom 10.0.1.1 icmp_seq=1 Destination Net Unreachable\nFrom 10.0.1.1 icmp_seq=2 Destination Net Unreachable\nFrom 10.0.1.1 icmp_seq=3 Destination Net Unreachable\n^C\n--- 10.0.2.10 ping statistics ---\n3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2003ms\n</code></pre> <pre><code>core@server-02 ~ $ ping 10.0.1.10\nPING 10.0.1.10 (10.0.1.10) 56(84) bytes of data.\nFrom 10.0.2.1 icmp_seq=1 Destination Net Unreachable\nFrom 10.0.2.1 icmp_seq=2 Destination Net Unreachable\nFrom 10.0.2.1 icmp_seq=3 Destination Net Unreachable\n^C\n--- 10.0.1.10 ping statistics ---\n3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2004ms\n</code></pre>"},{"location":"vlab/demo/#peering-vpcs-and-testing-connectivity","title":"Peering VPCs and testing connectivity","text":"<p>To enable connectivity between the VPCs, peer them using <code>kubectl fabric vpc peer</code>:</p> <pre><code>core@control-1 ~ $ kubectl fabric vpc peer --vpc vpc-1 --vpc vpc-2\n07:04:58 INF VPCPeering created name=vpc-1--vpc-2\n</code></pre> <p>Make sure to wait until the peering is applied to the switches using <code>kubectl get agents</code> command. After that, you can test connectivity between the servers again:</p> <pre><code>core@server-01 ~ $ ping 10.0.2.10\nPING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.\n64 bytes from 10.0.2.10: icmp_seq=1 ttl=62 time=6.25 ms\n64 bytes from 10.0.2.10: icmp_seq=2 ttl=62 time=7.60 ms\n64 bytes from 10.0.2.10: icmp_seq=3 ttl=62 time=8.60 ms\n^C\n--- 10.0.2.10 ping statistics ---\n3 packets transmitted, 3 received, 0% packet loss, time 2004ms\nrtt min/avg/max/mdev = 6.245/7.481/8.601/0.965 ms\n</code></pre> <pre><code>core@server-02 ~ $ ping 10.0.1.10\nPING 10.0.1.10 (10.0.1.10) 56(84) bytes of data.\n64 bytes from 10.0.1.10: icmp_seq=1 ttl=62 time=5.44 ms\n64 bytes from 10.0.1.10: icmp_seq=2 ttl=62 time=6.66 ms\n64 bytes from 10.0.1.10: icmp_seq=3 ttl=62 time=4.49 ms\n^C\n--- 10.0.1.10 ping statistics ---\n3 packets transmitted, 3 received, 0% packet loss, time 2004ms\nrtt min/avg/max/mdev = 4.489/5.529/6.656/0.886 ms\n</code></pre> <p>If you delete the VPC peering with <code>kubectl delete</code> applied to the relevant object and wait for the agent to apply the configuration on the switches, you can observe that connectivity is lost again:</p> <pre><code>core@control-1 ~ $ kubectl delete vpcpeering/vpc-1--vpc-2\nvpcpeering.vpc.githedgehog.com \"vpc-1--vpc-2\" deleted\n</code></pre> <pre><code>core@server-01 ~ $ ping 10.0.2.10\nPING 10.0.2.10 (10.0.2.10) 56(84) bytes of data.\nFrom 10.0.1.1 icmp_seq=1 Destination Net Unreachable\nFrom 10.0.1.1 icmp_seq=2 Destination Net Unreachable\nFrom 10.0.1.1 icmp_seq=3 Destination Net Unreachable\n^C\n--- 10.0.2.10 ping statistics ---\n3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2004ms\n</code></pre> <p>You can see duplicate packets in the output of the <code>ping</code> command between some of the servers. This is expected behavior and is caused by the limitations in the VLAB environment.</p> <pre><code>core@server-01 ~ $ ping 10.0.5.10\nPING 10.0.5.10 (10.0.5.10) 56(84) bytes of data.\n64 bytes from 10.0.5.10: icmp_seq=1 ttl=62 time=9.58 ms\n64 bytes from 10.0.5.10: icmp_seq=1 ttl=62 time=9.58 ms (DUP!)\n64 bytes from 10.0.5.10: icmp_seq=2 ttl=62 time=6.99 ms\n64 bytes from 10.0.5.10: icmp_seq=2 ttl=62 time=6.99 ms (DUP!)\n64 bytes from 10.0.5.10: icmp_seq=3 ttl=62 time=9.59 ms\n64 bytes from 10.0.5.10: icmp_seq=3 ttl=62 time=9.60 ms (DUP!)\n^C\n--- 10.0.5.10 ping statistics ---\n3 packets transmitted, 3 received, +3 duplicates, 0% packet loss, time 2003ms\nrtt min/avg/max/mdev = 6.987/8.720/9.595/1.226 ms\n</code></pre>"},{"location":"vlab/demo/#using-vpcs-with-overlapping-subnets","title":"Using VPCs with overlapping subnets","text":"<p>First, create a second IPv4Namespace with the same subnet as the default one:</p> <pre><code>core@control-1 ~ $ kubectl get ipns\nNAME      SUBNETS           AGE\ndefault   [\"10.0.0.0/16\"]   24m\n\ncore@control-1 ~ $ cat &lt;&lt;EOF &gt; ipns-2.yaml\napiVersion: vpc.githedgehog.com/v1beta1\nkind: IPv4Namespace\nmetadata:\n  name: ipns-2\n  namespace: default\nspec:\n  subnets:\n  - 10.0.0.0/16\nEOF\n\ncore@control-1 ~ $ kubectl apply -f ipns-2.yaml\nipv4namespace.vpc.githedgehog.com/ipns-2 created\n\ncore@control-1 ~ $ kubectl get ipns\nNAME      SUBNETS           AGE\ndefault   [\"10.0.0.0/16\"]   30m\nipns-2    [\"10.0.0.0/16\"]   8s\n</code></pre> <p>Let's assume that <code>vpc-1</code> already exists and is attached to <code>server-01</code> (see Creating and attaching VPCs). Now we can create <code>vpc-3</code> with the same subnet as <code>vpc-1</code> (but in the different IPv4Namespace) and attach it to the <code>server-03</code>:</p> <pre><code>core@control-1 ~ $ cat &lt;&lt;EOF &gt; vpc-3.yaml\napiVersion: vpc.githedgehog.com/v1beta1\nkind: VPC\nmetadata:\n  name: vpc-3\n  namespace: default\nspec:\n  ipv4Namespace: ipns-2\n  subnets:\n    default:\n      dhcp:\n        enable: true\n        range:\n          start: 10.0.1.10\n      subnet: 10.0.1.0/24\n      vlan: 2001\n  vlanNamespace: default\nEOF\n\ncore@control-1 ~ $ kubectl apply -f vpc-3.yaml\n</code></pre> <p>At that point you can setup networking on <code>server-03</code> the same as you did for <code>server-01</code> and <code>server-02</code> in a previous section. Once you have configured networking, <code>server-01</code> and <code>server-03</code> have IP addresses from the same subnets.</p>"},{"location":"vlab/overview/","title":"VLAB Overview","text":"<p>It's possible to run Hedgehog Fabric in a fully virtual environment using QEMU/KVM and SONiC Virtual Switch (VS). It's a great way to try out Fabric and learn about its look and feel, API, and capabilities. It's not suitable for any data plane or performance testing, or for production use.</p> <p>In the VLAB all switches start as empty VMs with only the ONIE image on them, and they go through the whole discovery, boot and installation process like on real hardware.</p>"},{"location":"vlab/overview/#hhfab","title":"HHFAB","text":"<p>Hedgehog maintains a utility to install and configure VLAB, called <code>hhfab</code>, aka Fabricator.</p> <p>The <code>hhfab</code> CLI provides a special command <code>vlab</code> to manage the virtual labs. It allows you to run sets of virtual machines to simulate the Fabric infrastructure including control node, switches, test servers and it automatically runs the installer to get Fabric up and running.</p> <p>You can find more information about getting <code>hhfab</code> in the download section.</p>"},{"location":"vlab/overview/#system-requirements","title":"System Requirements","text":"<p>Currently, it's only tested on Ubuntu 22.04 LTS, but should work on any Linux distribution with QEMU/KVM support and fairly up-to-date packages.</p> <p>The following packages needs to be installed: <code>qemu-kvm socat</code>. Docker is also required, to login into the OCI registry.</p> <p>By default, the VLAB topology is Spine-Leaf with 2 spines, 2 MCLAG leaves and 1 non-MCLAG leaf. Optionally, you can choose to run the default Collapsed Core topology using flag <code>--fabric-mode collapsed-core</code> (or <code>-m collapsed-core</code>) which only consists of 2 switches.</p> <p>You can calculate the system requirements based on the allocated resources to the VMs using the following table:</p> Device vCPU RAM Disk Control Node 6 6GB 100GB Test Server 2 768MB 10GB Switch 4 5GB 50GB <p>These numbers give approximately the following requirements for the default topologies:</p> <ul> <li>Spine-Leaf: 38 vCPUs, 36352 MB, 410 GB disk</li> <li>Collapsed Core: 22 vCPUs, 19456 MB, 240 GB disk</li> </ul> <p>Usually, none of the VMs will reach 100% utilization of the allocated resources, but as a rule of thumb you should make sure that you have at least allocated RAM and disk space for all VMs.</p> <p>NVMe SSD for VM disks is highly recommended.</p>"},{"location":"vlab/overview/#installing-prerequisites","title":"Installing Prerequisites","text":"<p>To run VLAB, your system needs <code>docker</code>,<code>qemu</code>,<code>kvm</code>, and <code>hhfab</code>. On Ubuntu 22.04 LTS you can install all required packages using the following commands:</p>"},{"location":"vlab/overview/#docker","title":"Docker","text":"<pre><code>curl -fsSL https://get.docker.com -o install-docker.sh\nsudo sh install-docker.sh\nsudo usermod -aG docker $USER\nnewgrp docker\n</code></pre>"},{"location":"vlab/overview/#qemukvm","title":"Qemu/KVM","text":"<pre><code>sudo apt install -y qemu-kvm swtpm-tools tpm2-tools socat\nsudo usermod -aG kvm $USER\nnewgrp kvm\nkvm-ok\n</code></pre> <p>Good output of the <code>kvm-ok</code> command should look like this:</p> <pre><code>ubuntu@docs:~$ kvm-ok\nINFO: /dev/kvm exists\nKVM acceleration can be used\n</code></pre>"},{"location":"vlab/overview/#oras","title":"Oras","text":"<p>For convenience Hedgehog provides a script to install <code>oras</code>:</p> <pre><code>curl -fsSL https://i.hhdev.io/oras | bash\n</code></pre>"},{"location":"vlab/overview/#hhfab_1","title":"Hhfab","text":"<p>You need a GitHub access token to download <code>hhfab</code>, please submit a ticket using the Hedgehog Support Portal. Once in possession of the credentials, use the provided username and token to log into the GitHub container registry:</p> <pre><code>docker login ghcr.io --username provided_username --password provided_token\n</code></pre> <p>Once logged in, download and run the script:</p> <pre><code>curl -fsSL https://i.hhdev.io/hhfab | bash\n</code></pre>"},{"location":"vlab/overview/#next-steps","title":"Next steps","text":"<ul> <li>Configure and Run VLAB</li> </ul>"},{"location":"vlab/running/","title":"Running VLAB","text":"<p>Make sure to follow the prerequisites and check system requirements in the VLAB Overview section before running VLAB.</p>"},{"location":"vlab/running/#initialize-vlab","title":"Initialize VLAB","text":"<p>First, initialize Fabricator by running <code>hhfab init --dev</code>. This command creates the <code>fab.yaml</code> file, which is the main configuration file for the fabric. This command supports several customization options that are listed in the output of <code>hhfab init --help</code>.</p> <pre><code>ubuntu@docs:~$ hhfab init --dev\n11:26:52 INF Hedgehog Fabricator version=v0.30.0\n11:26:52 INF Generated initial config\n11:26:52 INF Adjust configs (incl. credentials, modes, subnets, etc.) file=fab.yaml\n11:26:52 INF Include wiring files (.yaml) or adjust imported ones dir=include\n</code></pre>"},{"location":"vlab/running/#vlab-topology","title":"VLAB Topology","text":"<p>By default, <code>hhfab init</code> creates 2 spines, 2 MCLAG leaves and 1 non-MCLAG leaf with 2 fabric connections (between each spine and leaf), 2 MCLAG peer links and 2 MCLAG session links as well as 2 loopbacks per leaf for implementing VPC loopback workaround. To generate the preceding topology, <code>hhfab vlab gen</code>. You can also configure the number of spines, leafs, connections, and so on. For example, flags <code>--spines-count</code> and <code>--mclag-leafs-count</code> allow you to set the number of spines and MCLAG leaves, respectively. For complete options, <code>hhfab vlab gen -h</code>.</p> <p><pre><code>ubuntu@docs:~$ hhfab vlab gen\n21:27:16 INF Hedgehog Fabricator version=v0.30.0\n21:27:16 INF Building VLAB wiring diagram fabricMode=spine-leaf\n21:27:16 INF &gt;&gt;&gt; spinesCount=2 fabricLinksCount=2\n21:27:16 INF &gt;&gt;&gt; eslagLeafGroups=2\n21:27:16 INF &gt;&gt;&gt; mclagLeafsCount=2 mclagSessionLinks=2 mclagPeerLinks=2\n21:27:16 INF &gt;&gt;&gt; orphanLeafsCount=1 vpcLoopbacks=2\n21:27:16 INF &gt;&gt;&gt; mclagServers=2 eslagServers=2 unbundledServers=1 bundledServers=1\n21:27:16 INF Generated wiring file name=vlab.generated.yaml\n</code></pre> You can jump to the instructions to start VLAB, or see the next section for customizing the topology.</p>"},{"location":"vlab/running/#collapsed-core","title":"Collapsed Core","text":"<p>If a Collapsed Core topology is desired, after the <code>hhfab init --dev</code> step, edit the resulting <code>fab.yaml</code> file and change the <code>mode: spine-leaf</code> to <code>mode: collapsed-core</code>:</p> <pre><code>ubuntu@docs:~$ hhfab vlab gen\n11:39:02 INF Hedgehog Fabricator version=v0.30.0\n11:39:02 INF Building VLAB wiring diagram fabricMode=collapsed-core\n11:39:02 INF &gt;&gt;&gt; mclagLeafsCount=2 mclagSessionLinks=2 mclagPeerLinks=2\n11:39:02 INF &gt;&gt;&gt; orphanLeafsCount=0 vpcLoopbacks=2\n11:39:02 INF &gt;&gt;&gt; mclagServers=2 eslagServers=2 unbundledServers=1 bundledServers=1\n11:39:02 INF Generated wiring file name=vlab.generated.yaml\n</code></pre>"},{"location":"vlab/running/#custom-spine-leaf","title":"Custom Spine Leaf","text":"<p>Or you can run custom topology with 2 spines, 4 MCLAG leaves and 2 non-MCLAG leaves using flags:</p> <pre><code>ubuntu@docs:~$ hhfab vlab gen --mclag-leafs-count 4 --orphan-leafs-count 2\n11:41:06 INF Hedgehog Fabricator version=v0.30.0\n11:41:06 INF Building VLAB wiring diagram fabricMode=spine-leaf\n11:41:06 INF &gt;&gt;&gt; spinesCount=2 fabricLinksCount=2\n11:41:06 INF &gt;&gt;&gt; eslagLeafGroups=\"\"\n11:41:06 INF &gt;&gt;&gt; mclagLeafsCount=4 mclagSessionLinks=2 mclagPeerLinks=2\n11:41:06 INF &gt;&gt;&gt; orphanLeafsCount=2 vpcLoopbacks=2\n11:41:06 INF &gt;&gt;&gt; mclagServers=2 eslagServers=2 unbundledServers=1 bundledServers=1\n11:41:06 INF Generated wiring file name=vlab.generated.yaml\n</code></pre> <p>Additionally, you can pass extra Fabric configuration items using flags on <code>init</code> command or by passing a configuration file. For more information, refer to the Fabric Configuration section.</p> <p>Once you have initialized the VLAB, download the artifacts and build the installer using <code>hhfab build</code>. This command automatically downloads all required artifacts from the OCI registry and builds the installer and all other prerequisites for running the VLAB.</p>"},{"location":"vlab/running/#build-the-installer-and-start-vlab","title":"Build the Installer and Start VLAB","text":"<p>To build and start the virtual machines, use <code>hhfab vlab up</code>. For successive runs, use the <code>--kill-stale</code> flag to ensure that any virtual machines from a previous run are gone. <code>hhfab vlab up</code> runs in the foreground and does not return, which allows you to stop all VLAB VMs by simply pressing <code>Ctrl + C</code>. <pre><code>ubuntu@docs:~$ hhfab vlab up\n11:48:22 INF Hedgehog Fabricator version=v0.30.0\n11:48:22 INF Wiring hydrated successfully mode=if-not-present\n11:48:22 INF VLAB config created file=vlab/config.yaml\n11:48:22 INF Downloader cache=/home/ubuntu/.hhfab-cache/v1 repo=ghcr.io prefix=githedgehog\n11:48:22 INF Building installer control=control-1\n11:48:22 INF Adding recipe bin to installer control=control-1\n11:48:24 INF Adding k3s and tools to installer control=control-1\n11:48:25 INF Adding zot to installer control=control-1\n11:48:25 INF Adding cert-manager to installer control=control-1\n11:48:26 INF Adding config and included wiring to installer control=control-1\n11:48:26 INF Adding airgap artifacts to installer control=control-1\n11:48:36 INF Archiving installer path=/home/ubuntu/result/control-1-install.tgz control=control-1\n11:48:45 INF Creating ignition path=/home/ubuntu/result/control-1-install.ign control=control-1\n11:48:46 INF Taps and bridge are ready count=8\n11:48:46 INF Downloader cache=/home/ubuntu/.hhfab-cache/v1 repo=ghcr.io prefix=githedgehog\n11:48:46 INF Preparing new vm=control-1 type=control\n11:48:51 INF Preparing new vm=server-01 type=server\n11:48:52 INF Preparing new vm=server-02 type=server\n11:48:54 INF Preparing new vm=server-03 type=server\n11:48:55 INF Preparing new vm=server-04 type=server\n11:48:57 INF Preparing new vm=server-05 type=server\n11:48:58 INF Preparing new vm=server-06 type=server\n11:49:00 INF Preparing new vm=server-07 type=server\n11:49:01 INF Preparing new vm=server-08 type=server\n11:49:03 INF Preparing new vm=server-09 type=server\n11:49:04 INF Preparing new vm=server-10 type=server\n11:49:05 INF Preparing new vm=leaf-01 type=switch\n11:49:06 INF Preparing new vm=leaf-02 type=switch\n11:49:06 INF Preparing new vm=leaf-03 type=switch\n11:49:06 INF Preparing new vm=leaf-04 type=switch\n11:49:06 INF Preparing new vm=leaf-05 type=switch\n11:49:06 INF Preparing new vm=spine-01 type=switch\n11:49:06 INF Preparing new vm=spine-02 type=switch\n11:49:06 INF Starting VMs count=18 cpu=\"54 vCPUs\" ram=\"49664 MB\" disk=\"550 GB\"\n11:49:59 INF Uploading control install vm=control-1 type=control\n11:53:39 INF Running control install vm=control-1 type=control\n11:53:40 INF control-install: 01:53:39 INF Hedgehog Fabricator Recipe version=v0.30.0 vm=control-1\n11:53:40 INF control-install: 01:53:39 INF Running control node installation vm=control-1\n12:00:32 INF control-install: 02:00:31 INF Control node installation complete vm=control-1\n12:00:32 INF Control node is ready vm=control-1 type=control\n12:00:32 INF All VMs are ready\n</code></pre> When the message <code>INF Control node is ready vm=control-1 type=control</code> from the installer's output means that the installer has finished. After this line has been displayed, you can get into the control node and other VMs to watch the Fabric coming up and switches getting provisioned. See Accessing the VLAB.</p>"},{"location":"vlab/running/#enable-outside-connectivity-from-vlab-vms","title":"Enable Outside connectivity from VLAB VMs","text":"<p>By default, all test server VMs are isolated and have no connectivity to the host or the Internet. You can configure enable connectivity using <code>hhfab vlab up --restrict-servers=false</code> to allow the test servers to access the Internet and the host. When you enable connectivity, VMs get a default route pointing to the host, which means that in case of the VPC peering you need to configure test server VMs to use the VPC attachment as a default route (or just some specific subnets).</p>"},{"location":"vlab/running/#accessing-the-vlab","title":"Accessing the VLAB","text":"<p>The <code>hhfab vlab</code> command provides <code>ssh</code> and <code>serial</code> subcommands to access the VMs. You can use <code>ssh</code> to get into the control node and test servers after the VMs are started. You can use <code>serial</code> to get into the switch VMs while they are provisioning and installing the software. After switches are installed you can use <code>ssh</code> to get into them.</p> <p>You can select device you want to access or pass the name using the <code>--vm</code> flag.</p> <pre><code>ubuntu@docs:~$ hhfab vlab ssh\nUse the arrow keys to navigate: \u2193 \u2191 \u2192 \u2190  and / toggles search\nSSH to VM:\n  \ud83e\udd94 control-1\n  server-01\n  server-02\n  server-03\n  server-04\n  server-05\n  server-06\n  leaf-01\n  leaf-02\n  leaf-03\n  spine-01\n  spine-02\n\n----------- VM Details ------------\nID:             0\nName:           control-1\nReady:          true\nBasedir:        .hhfab/vlab-vms/control-1\n</code></pre>"},{"location":"vlab/running/#default-credentials","title":"Default credentials","text":"<p>Fabricator creates default users and keys for you to login into the control node and test servers as well as for the SONiC Virtual Switches.</p> <p>The default user with password-less sudo for the control node and test servers is <code>core</code> with password <code>HHFab.Admin!</code>. The admin user with full access and password-less sudo for the switches is <code>admin</code> with password <code>HHFab.Admin!</code>. The read-only, non-sudo user with access to the switch CLI is <code>op</code> with password <code>HHFab.Op!</code>.</p>"},{"location":"vlab/running/#use-kubectl-to-interact-with-the-fabric","title":"Use Kubectl to Interact with the Fabric","text":"<p>On the control node you have access to kubectl, Fabric CLI, and k9s to manage the Fabric. To view information about the switches run <code>kubectl get agents -o wide</code>. After the control node is available it usually takes about 10-15 minutes for the switches to get installed.</p> <p>After the switches are provisioned, the command returns something like this:</p> <pre><code>core@control-1 ~ $ kubectl get agents -o wide\nNAME       ROLE          DESCR           HWSKU                      ASIC   HEARTBEAT   APPLIED   APPLIEDG   CURRENTG   VERSION   SOFTWARE                ATTEMPT   ATTEMPTG   AGE\nleaf-01    server-leaf   VS-01 MCLAG 1   DellEMC-S5248f-P-25G-DPB   vs     30s         5m5s      4          4          v0.23.0   4.1.1-Enterprise_Base   5m5s      4          10m\nleaf-02    server-leaf   VS-02 MCLAG 1   DellEMC-S5248f-P-25G-DPB   vs     27s         3m30s     3          3          v0.23.0   4.1.1-Enterprise_Base   3m30s     3          10m\nleaf-03    server-leaf   VS-03           DellEMC-S5248f-P-25G-DPB   vs     18s         3m52s     4          4          v0.23.0   4.1.1-Enterprise_Base   3m52s     4          10m\nspine-01   spine         VS-04           DellEMC-S5248f-P-25G-DPB   vs     26s         3m59s     3          3          v0.23.0   4.1.1-Enterprise_Base   3m59s     3          10m\nspine-02   spine         VS-05           DellEMC-S5248f-P-25G-DPB   vs     19s         3m53s     4          4          v0.23.0   4.1.1-Enterprise_Base   3m53s     4          10m\n</code></pre> <p>The <code>Heartbeat</code> column shows how long ago the switch has sent the heartbeat to the control node. The <code>Applied</code> column shows how long ago the switch has applied the configuration. <code>AppliedG</code> shows the generation of the configuration applied. <code>CurrentG</code> shows the generation of the configuration the switch is supposed to run. Different values for <code>AppliedG</code> and <code>CurrentG</code> mean that the switch is in the process of applying the configuration.</p> <p>At that point Fabric is ready and you can use <code>kubectl</code> and <code>kubectl fabric</code> to manage the Fabric. You can find more about managing the Fabric in the Running Demo and User Guide sections.</p>"},{"location":"vlab/running/#getting-main-fabric-objects","title":"Getting main Fabric objects","text":"<p>You can list the main Fabric objects by running <code>kubectl get</code> on the control node. You can find more details about using the Fabric in the User Guide, Fabric API and Fabric CLI sections.</p> <p>For example, to get the list of switches, run:</p> <pre><code>core@control-1 ~ $ kubectl get switch\nNAME       ROLE          DESCR           GROUPS   LOCATIONUUID                           AGE\nleaf-01    server-leaf   VS-01 MCLAG 1            5e2ae08a-8ba9-599a-ae0f-58c17cbbac67   6h10m\nleaf-02    server-leaf   VS-02 MCLAG 1            5a310b84-153e-5e1c-ae99-dff9bf1bfc91   6h10m\nleaf-03    server-leaf   VS-03                    5f5f4ad5-c300-5ae3-9e47-f7898a087969   6h10m\nspine-01   spine         VS-04                    3e2c4992-a2e4-594b-bbd1-f8b2fd9c13da   6h10m\nspine-02   spine         VS-05                    96fbd4eb-53b5-5a4c-8d6a-bbc27d883030   6h10m\n</code></pre> <p>Similarly, to get the list of servers, run:</p> <pre><code>core@control-1 ~ $ kubectl get server\nNAME        TYPE      DESCR                        AGE\ncontrol-1   control   Control node                 6h10m\nserver-01             S-01 MCLAG leaf-01 leaf-02   6h10m\nserver-02             S-02 MCLAG leaf-01 leaf-02   6h10m\nserver-03             S-03 Unbundled leaf-01       6h10m\nserver-04             S-04 Bundled leaf-02         6h10m\nserver-05             S-05 Unbundled leaf-03       6h10m\nserver-06             S-06 Bundled leaf-03         6h10m\n</code></pre> <p>For connections, use:</p> <pre><code>core@control-1 ~ $ kubectl get connection\nNAME                                 TYPE           AGE\nleaf-01--mclag-domain--leaf-02       mclag-domain   6h11m\nleaf-01--vpc-loopback                vpc-loopback   6h11m\nleaf-02--vpc-loopback                vpc-loopback   6h11m\nleaf-03--vpc-loopback                vpc-loopback   6h11m\nserver-01--mclag--leaf-01--leaf-02   mclag          6h11m\nserver-02--mclag--leaf-01--leaf-02   mclag          6h11m\nserver-03--unbundled--leaf-01        unbundled      6h11m\nserver-04--bundled--leaf-02          bundled        6h11m\nserver-05--unbundled--leaf-03        unbundled      6h11m\nserver-06--bundled--leaf-03          bundled        6h11m\nspine-01--fabric--leaf-01            fabric         6h11m\nspine-01--fabric--leaf-02            fabric         6h11m\nspine-01--fabric--leaf-03            fabric         6h11m\nspine-02--fabric--leaf-01            fabric         6h11m\nspine-02--fabric--leaf-02            fabric         6h11m\nspine-02--fabric--leaf-03            fabric         6h11m\n</code></pre> <p>For IPv4 and VLAN namespaces, use:</p> <pre><code>core@control-1 ~ $ kubectl get ipns\nNAME      SUBNETS           AGE\ndefault   [\"10.0.0.0/16\"]   6h12m\n\ncore@control-1 ~ $ kubectl get vlanns\nNAME      AGE\ndefault   6h12m\n</code></pre>"},{"location":"vlab/running/#reset-vlab","title":"Reset VLAB","text":"<p>If VLAB is currently running, press <code>Ctrl + C</code> to stop it. To reset VLAB and start over run <code>hhfab init -f</code>. This option forces the process to overwrite your existing configuration in <code>fab.yaml</code>.</p>"},{"location":"vlab/running/#next-steps","title":"Next steps","text":"<ul> <li>Running Demo</li> </ul>"}]}
\ No newline at end of file