diff --git a/docs/architecture/fabric.md b/docs/architecture/fabric.md
index 113d6b8b4..5d11ff32b 100644
--- a/docs/architecture/fabric.md
+++ b/docs/architecture/fabric.md
@@ -67,23 +67,7 @@ describe how VPCs are actually implemented in the network to ensure a private vi
## VPC Peering
-To enable communication between 2 different VPCs, one needs to configure a VPC peering policy. The Hedgehog Fabric
-supports two different peering modes:
-
-* 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. Traffic between the peered VPCs will not leave the switch that connects
- them.
-* Remote Peering:
-
- !!! warning "Deprecated"
- Remote peering is being deprecated. Using local peering is encouraged.
-
- 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. This peering mode was introduced as a workaround to previous limitations of the fabric; users are recommended
- to use local peering instead.
+To enable communication between 2 different VPCs, one needs to configure a VPC peering policy.
+This directly imports routes from another VPC using route leaking.
+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.
diff --git a/docs/concepts/overview.md b/docs/concepts/overview.md
index 44e432096..a4ff293df 100644
--- a/docs/concepts/overview.md
+++ b/docs/concepts/overview.md
@@ -33,7 +33,7 @@ Wiring Diagram consists of the following resources:
* __Server__: *any* physical server attached to the Fabric including Control Nodes
* __Connection__: *any* logical connection for devices
* usually it's a connection between two or more ports on two different devices
- * for example: Fabric connection between spine and leaf, and server connections like Unbundled, Bundled, MCLAG, or ESLAG.
+ * for example: Fabric connection between spine and leaf, and server connections like Unbundled, Bundled, or ESLAG.
* __VLANNamespace__ -> non-overlapping VLAN ranges for attaching servers
* __IPv4Namespace__ -> non-overlapping IPv4 ranges for VPC subnets
diff --git a/docs/install-upgrade/build-wiring.md b/docs/install-upgrade/build-wiring.md
index 16b7af968..a3bb6bb7b 100644
--- a/docs/install-upgrade/build-wiring.md
+++ b/docs/install-upgrade/build-wiring.md
@@ -133,7 +133,7 @@ topologies without spines.
### VPC Peering
-VPCs need VPC Peerings to talk to each other. VPC Peerings come in two varieties: local and remote.
+VPCs need VPC Peerings to talk to each other.
``` mermaid
graph TD
@@ -162,9 +162,7 @@ graph TD
end
```
-#### Local VPC Peering
-
-When there is no dedicated border/peering switch available in the fabric we can use local VPC peering. This kind of peering tries to send traffic between the two VPCs on the switch where either of the VPCs has workloads attached.
+A VPC peering sends traffic between the two VPCs on the switch where either of the VPCs has workloads attached.
``` mermaid
graph TD
@@ -189,51 +187,7 @@ graph TD
S4
end
```
-The dotted line in the diagram shows the traffic flow for local peering. The traffic originates in VPC 2, travels to the switch, and finally out the port destined for VPC 1.
-
-
-#### Remote VPC Peering
-
-!!! warning "Deprecated"
- Remote peering is being deprecated. Using local peering is encouraged.
-
-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 VPCs 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.
-
-``` mermaid
-graph TD
- S1([Spine 1])
- S2([Spine 2])
- L1([Leaf 1])
- L2([Leaf 2])
- L3([Leaf 3])
- TS1[Server1]
- TS2[Server2]
- TS3[Server3]
- TS4[Server4]
-
- S1 <-.5.-> L1;
- S1 <-.2.-> L2;
- S1 <-.3,4.-> L3;
- S2 <--> L1;
- S2 <--> L2;
- S2 <--> L3;
- L1 <-.6.-> TS1;
- L1 <--> TS2;
- L2 <--> TS3;
- L2 <-.1.-> TS4;
-
-
- subgraph VPC 1
- TS1
- TS2
- end
-
- subgraph VPC 2
- TS3
- TS4
- end
-```
-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.
+The dotted line in the diagram shows the traffic flow for VPC peering. The traffic originates in VPC 2, travels to the switch, and finally out the port destined for VPC 1.
## Sample Wiring Diagram
diff --git a/docs/known-limitations/known-limitations.md b/docs/known-limitations/known-limitations.md
index eb2ecdafa..bdcaf8289 100644
--- a/docs/known-limitations/known-limitations.md
+++ b/docs/known-limitations/known-limitations.md
@@ -5,7 +5,6 @@ working hard to address:
* [Deleting a VPC and creating a new one right away can cause the agent to fail](#deleting-a-vpc-and-creating-a-new-one-right-away-can-cause-the-agent-to-fail)
* [Configuration not allowed when port is member of PortChannel](#configuration-not-allowed-when-port-is-member-of-portchannel)
-* [External peering over a connection originating from an MCLAG switch can fail](#external-peering-over-a-connection-originating-from-an-mclag-switch-can-fail)
* [Breakout and CMIS transceiver initialization issues on DS5000](#breakout-and-cmis-transceiver-initialization-issues-on-ds5000)
### Deleting a VPC and creating a new one right away can cause the agent to fail
@@ -55,22 +54,6 @@ s5248-01(config)# interface Ethernet 1
s5248-01(config-if-Ethernet1)# no shutdown
```
-### External peering over a connection originating from an MCLAG switch can fail
-
-When importing routes via [External Peering](../user-guide/external.md) over a connection
-originating from an MCLAG leaf switch, traffic from the peered VPC towards that
-prefix can be blackholed. This is due to a routing mismatch between the two MCLAG leaves,
-where only one switch learns the imported route. Packets hitting the "wrong" leaf will
-be dropped with a Destination Unreachable error.
-
-#### Diagnosing this issue
-
-No connectivity from the workload server(s) in the VPC towards the prefix routed via the external.
-
-#### Known workarounds
-
-Connect your externals to non-MCLAG switches instead.
-
### Breakout and CMIS transceiver initialization issues on DS5000
On Celestica DS5000 devices, certain transceivers using the Common Management Interface Specification (CMIS) fail to initialize properly under specific conditions.
diff --git a/docs/reference/cli.md b/docs/reference/cli.md
index bd02e69e6..1badf9f7e 100644
--- a/docs/reference/cli.md
+++ b/docs/reference/cli.md
@@ -46,10 +46,10 @@ core@control-1 ~ $ kubectl fabric vpc create --name vpc-1 --subnet 10.0.1.0/24 -
```
Attach previously created VPC to the server `server-01` (which is connected to the Fabric using the
-`server-01--mclag--leaf-01--leaf-02` Connection):
+`server-01--eslag--leaf-01--leaf-02` Connection):
```bash
-core@control-1 ~ $ kubectl fabric vpc attach --vpc-subnet vpc-1/default --connection server-01--mclag--leaf-01--leaf-02
+core@control-1 ~ $ kubectl fabric vpc attach --vpc-subnet vpc-1/default --connection server-01--eslag--leaf-01--leaf-02
```
To peer VPC with another VPC (e.g. `vpc-2`) use the following command:
diff --git a/docs/release-notes/index.md b/docs/release-notes/index.md
index 575154dba..7a894bb34 100644
--- a/docs/release-notes/index.md
+++ b/docs/release-notes/index.md
@@ -23,7 +23,7 @@ Date: May 8, 2026
### Notes
- Upgrade is supported only from 26.01.x
-- Remote VPC peering (`spec.remote`) has been deprecated since 26.01 and will be removed in 26.03; use local `VPCPeering` or `GatewayPeering` instead
+- Remote VPC peering (`spec.remote`) has been deprecated since 26.01 and will be removed in 26.03; use regular `VPCPeering` or `GatewayPeering` instead
- `MCLAG` has been deprecated since 26.01 and will be removed in 26.03; use `ESLAG` (EVPN MH) instead
### Software versions
@@ -208,7 +208,7 @@ Date: May 15, 2025
### Highlights
- Celestica DS5000 support as a spine and limited leaf
- - Limited leaf means that [local peering](../install-upgrade/build-wiring.md#local-vpc-peering) is not supported and
+ - Limited leaf means that local peering is not supported and
externals could only be attached without VLANs due to the lack of subinterfaces support
- MCLAG link state tracking is now enabled (shutdown server-facing MCLAG port channels if no spine uplinks are up)
diff --git a/docs/user-guide/connections.md b/docs/user-guide/connections.md
index 1008d99b4..dbfd61fad 100644
--- a/docs/user-guide/connections.md
+++ b/docs/user-guide/connections.md
@@ -234,71 +234,3 @@ spec:
ip: 172.30.128.8/31
port: spine-01/E1/5
```
-
-## Deprecated Connections
-
-### MCLAG
-
-!!! warning "Deprecated"
- MCLAG is being deprecated. Use [ESLAG](#eslag) for multi-homing instead.
-
-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 `mclag`
-and a Connection with type `mclag-domain` between them. MCLAG switches should also have the same `spec.ASN` and
-`spec.VTEPIP`. The server interfaces should be configured for 802.3ad LACP.
-
-```yaml
-apiVersion: wiring.githedgehog.com/v1beta1
-kind: Connection
-metadata:
- name: server-1--mclag--s5248-01--s5248-02
- namespace: default
-spec:
- mclag:
- links: # Defines multiple links between a single server and a pair of switches
- - server:
- port: server-1/enp2s1
- switch:
- port: s5248-01/E1/1
- - server:
- port: server-1/enp2s2
- switch:
- port: s5248-02/E1/1
-```
-
-### MCLAG-Domain
-
-!!! warning "Deprecated"
- MCLAG is being deprecated. Use [ESLAG](#eslag) for multi-homing instead.
-
-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 `mclag` and Connection with
-type `mclag-domain` between them. MCLAG switches should also have the same `spec.ASN` and `spec.VTEPIP`.
-
-```yaml
-apiVersion: wiring.githedgehog.com/v1beta1
-kind: Connection
-metadata:
- name: s5248-01--mclag-domain--s5248-02
- namespace: default
-spec:
- mclagDomain:
- peerLinks: # Defines multiple links between a pair of MCLAG switches for Peer link
- - switch1:
- port: s5248-01/E1/12
- switch2:
- port: s5248-02/E1/12
- - switch1:
- port: s5248-01/E1/13
- switch2:
- port: s5248-02/E1/13
- sessionLinks: # Defines multiple links between a pair of MCLAG switches for Session link
- - switch1:
- port: s5248-01/E1/14
- switch2:
- port: s5248-02/E1/14
- - switch1:
- port: s5248-01/E1/15
- switch2:
- port: s5248-02/E1/15
-```
diff --git a/docs/user-guide/devices.md b/docs/user-guide/devices.md
index 662dcda71..2be42e51b 100644
--- a/docs/user-guide/devices.md
+++ b/docs/user-guide/devices.md
@@ -171,9 +171,6 @@ spec:
...
```
-!!! warning "MCLAG Deprecated"
- MCLAG is being deprecated. Use ESLAG for multi-homing instead.
-
## Servers
Regular workload server:
diff --git a/docs/user-guide/dhcp.md b/docs/user-guide/dhcp.md
index 000e740d7..29f39ee0a 100644
--- a/docs/user-guide/dhcp.md
+++ b/docs/user-guide/dhcp.md
@@ -72,7 +72,7 @@ After creating the VPC, attach it to servers using their connection names:
kubectl fabric vpc attach \
--vpc vpc-1 \
--subnet default \
- --connection server-01--mclag--leaf-01--leaf-02
+ --connection server-01--eslag--leaf-01--leaf-02
```
## CLI helpers for leases
diff --git a/docs/user-guide/shrink-expand.md b/docs/user-guide/shrink-expand.md
index 546832f6f..35a8fc9f2 100644
--- a/docs/user-guide/shrink-expand.md
+++ b/docs/user-guide/shrink-expand.md
@@ -18,7 +18,7 @@ a spine is being added, it shares the same ASN as the existing spines. For an
IPv4 address increment the largest IP by one, keep the same netmask.
!!! note
- If the`Switch` will be used in `ESLAG` or `MCLAG` (deprecated) groups, appropriate groups should exist. Redundancy groups should
+ If the `Switch` will be used in `ESLAG` groups, those groups should exist. Redundancy groups should
be specified in the `Switch` object before creation.
#### Expanding Example
diff --git a/docs/user-guide/vpcs.md b/docs/user-guide/vpcs.md
index 8949390d7..ad6decd64 100644
--- a/docs/user-guide/vpcs.md
+++ b/docs/user-guide/vpcs.md
@@ -198,8 +198,8 @@ DHCPACK on 10.0.1.2 to 0c:20:12:fe:03:01 (server-01) via 10.0.1.1
### HostBGP subnets
At times, it is useful to have BGP running directly on the host and peering with the Fabric: one such case is
-to support active-active multi-homed servers, or simply to have redundancy when other techniques such
-as MCLAG or ESLAG are not available, for example because of hardware limitations.
+to support active-active multi-homed servers, or simply to have redundancy when ESLAG is not available,
+for example because of hardware limitations.
Consider this scenario: `server-1` is connected to two different Fabric switches `sw-1` and `sw-2`, and attached to
`vpc-1/subnet-1` on both of them. This subnet is configured as `hostBGP`; the switches will be configured to peer with
@@ -225,27 +225,21 @@ VPC could be attached to a switch that is part of the VLAN namespace used by the
apiVersion: vpc.githedgehog.com/v1beta1
kind: VPCAttachment
metadata:
- name: vpc-1-server-1--mclag--s5248-01--s5248-02
+ name: vpc-1-server-1--eslag--s5248-01--s5248-02
namespace: default
spec:
- connection: server-1--mclag--s5248-01--s5248-02 # Connection name representing the server port(s)
+ connection: server-1--eslag--s5248-01--s5248-02 # Connection name representing the server port(s)
subnet: vpc-1/default # VPC subnet name
nativeVLAN: true # (Optional) if true, the port will be configured as a native VLAN port (untagged)
```
## VPCPeering
-A VPCPeering enables VPC-to-VPC connectivity. There are two types of VPC peering:
-
-* Local: peering is implemented on the same switches where VPCs are attached
-* Remote: peering is implemented on the border/mixed leaves defined by the `SwitchGroup` object
-
+A VPCPeering enables VPC-to-VPC connectivity.
VPC peering is only possible between VPCs attached to the same IPv4 namespace (see [IPv4Namespace](#ipv4namespace)).
Note that static routes defined within a VPC will not be exported to other VPC peers.
-### Local VPC peering
-
```yaml
apiVersion: vpc.githedgehog.com/v1beta1
kind: VPCPeering
@@ -258,24 +252,6 @@ spec:
vpc-2: {} # See "Subnet filtering" for more advanced configuration
```
-### Remote VPC peering
-
-!!! warning "Deprecated"
- Remote peering is being deprecated. Using local peering is encouraged.
-
-```yaml
-apiVersion: vpc.githedgehog.com/v1beta1
-kind: VPCPeering
-metadata:
- name: vpc-1--vpc-2
- namespace: default
-spec:
- permit:
- - vpc-1: {}
- vpc-2: {}
- remote: border # Indicates a switch group to implement the peering on
-```
-
### Subnet filtering
It's possible to specify which specific subnets of the peering VPCs could communicate to each other using the `permit`
diff --git a/docs/vlab/demo.md b/docs/vlab/demo.md
index 753b622fc..efc941c7e 100644
--- a/docs/vlab/demo.md
+++ b/docs/vlab/demo.md
@@ -19,7 +19,6 @@ classDef gateway fill:#FFF2CC,stroke:#999,stroke-width:1px,color:#000
classDef spine fill:#F8CECC,stroke:#B85450,stroke-width:1px,color:#000
classDef leaf fill:#DAE8FC,stroke:#6C8EBF,stroke-width:1px,color:#000
classDef server fill:#D5E8D4,stroke:#82B366,stroke-width:1px,color:#000
-classDef mclag fill:#F0F8FF,stroke:#6C8EBF,stroke-width:1px,color:#000
classDef eslag fill:#FFF8E8,stroke:#CC9900,stroke-width:1px,color:#000
classDef external fill:#FFCC99,stroke:#D79B00,stroke-width:1px,color:#000
classDef hidden fill:none,stroke:none
@@ -184,11 +183,11 @@ USAGE:
Example command:
- $ 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
+ $ hhfab vlab setup-peerings 1+2 2+4 1~as5835 2~as5835:subnets=sub1,sub2:prefixes=0.0.0.0/0,22.22.22.0/24
Which will produce:
1. VPC peering between vpc-01 and vpc-02
- 2. Remote VPC peering between vpc-02 and vpc-04 on switch group named border
+ 2. VPC peering between vpc-02 and vpc-04
3. External peering for vpc-01 with External as5835 with default vpc subnet and any routes from external permitted
4. External peering for vpc-02 with External as5835 with subnets sub1 and sub2 exposed from vpc-02 and default route
from external permitted as well any route that belongs to 22.22.22.0/24
@@ -196,20 +195,37 @@ USAGE:
VPC Peerings:
1+2 -- VPC peering between vpc-01 and vpc-02
+ 1+2:gw -- same as above but using gateway peering, only valid if gateway is present
demo-1+demo-2 -- VPC peering between vpc-demo-1 and vpc-demo-2
- 1+2:r -- remote VPC peering between vpc-01 and vpc-02 on switch group if only one switch group is present
- 1+2:r=border -- remote VPC peering between vpc-01 and vpc-02 on switch group named border
- 1+2:remote=border -- same as above
External Peerings:
1~as5835 -- external peering for vpc-01 with External as5835
- 1~ -- external peering for vpc-1 with external if only one external is present for ipv4 namespace of vpc-01, allowing
+ 1~as5835:gw -- same as above but using gateway peering, only valid if gateway is present
+ 1~ -- external peering for vpc-01 with external if only one external is present for ipv4 namespace of vpc-01, allowing
default subnet and any route from external
- 1~:subnets=default@prefixes=0.0.0.0/0 -- external peering for vpc-1 with auth external with default vpc subnet and
+ 1~:subnets=default@prefixes=0.0.0.0/0 -- external peering for vpc-01 with auth external with default vpc subnet and
default route from external permitted
- 1~as5835:subnets=default,other:prefixes=0.0.0.0/0_le32_ge32,22.22.22.0/24 -- same but with more details
- 1~as5835:s=default,other:p=0.0.0.0/0_le32_ge32,22.22.22.0/24 -- same as above
+ 1~as5835:s=default:p=default:gw -- same as above but via the gateway
+ 1~as5835:s=default,other:p=1.0.0.1/32_le32_ge32,22.22.22.0/24 -- two explicit prefixes allowed from the external,
+ provided the external it is advertising them they will be imported and exposed to the VPC
+
+ Gateway NAT options:
+
+ These are available only when :gw is used. Options are per side of the peering; the examples below are for the
+ first VPC in a VPC peering. For the second VPC, replace '1' with '2'; for external peerings, use 'ext' and 'vpc'
+ instead to target respectively the external or the VPC in the peering (e.g. 'vpc-as' or 'ext-as').
+ - vpc1-as / as1: expose NAT "as" prefixes (one or more CIDRs, comma-separated; use !CIDR for Not)
+ - vpc1-nat / nat1: static|masquerade|port-forward (if *-as is set and *-nat omitted => static)
+ - vpc1-pf / pf1: port-forward rules (required when *-nat=port-forward), comma-separated:
+ tcp/80=8080,udp/10000-10010=20000-20010,443=8443
+
+ Example of VPC↔VPC with NAT via gateway:
+ 1+2:gw:vpc1-as=10.10.0.0/24:vpc1-nat=masquerade:vpc2-as=172.16.0.0/16:vpc2-nat=static
+ 1+2:gw:as1=10.10.0.0/24:nat1=port-forward:pf1=tcp/80=8080:as2=172.16.0.0/16
+
+ Example of VPC↔External with NAT via gateway:
+ 1~as5835:gw:vpc-as=10.10.0.1/32:vpc-nat=masquerade:ext-as=192.0.2.0/24:ext-nat=port-forward:ext-pf=udp/53=5353:p=1.0.0.0/8
OPTIONS:
--help, -h show help
@@ -219,7 +235,7 @@ OPTIONS:
Global options:
--brief, -b brief output (only warn and error) (default: false) [$HHFAB_BRIEF]
- --cache-dir DIR use cache dir DIR for caching downloaded files (default: "/home/ubuntu/.hhfab-cache") [$HHFAB_CACHE_DIR]
+ --cache-dir DIR use cache dir DIR for caching downloaded files (default: "home/ubuntu/.hhfab-cache") [$HHFAB_CACHE_DIR]
--verbose, -v verbose output (includes debug) (default: false) [$HHFAB_VERBOSE]
--workdir PATH run as if hhfab was started in PATH instead of the current working directory (default: "/home/ubuntu/hhfab") [$HHFAB_WORK_DIR]
```
diff --git a/docs/vlab/overview.md b/docs/vlab/overview.md
index ac849922e..3531a536c 100644
--- a/docs/vlab/overview.md
+++ b/docs/vlab/overview.md
@@ -25,10 +25,9 @@ and fairly up-to-date packages.
The following packages needs to be installed: `qemu-kvm socat`. Docker is also required, to login
into the OCI registry.
-By default, the VLAB topology is Spine-Leaf with 2 spines, 2 MCLAG leaves, 2 ESLAG leaves, and 1 "orphan" leaf, i.e. with
-no redundancy scheme. For ESLAG-only topologies (recommended), use `--mclag-leafs-count=0`. Alternatively, users can
-run the mesh topology, which directly connects as few as 2 leaves to each other, without the need for a spine switch
-in between.
+By default, the VLAB topology is Spine-Leaf with 2 spines, 2 ESLAG leaves, and 1 "orphan" leaf, i.e. with
+no redundancy scheme. Alternatively, users can run the mesh topology, which directly connects as few as 2
+leaves to each other, without the need for a spine switch in between.
You can calculate the system requirements based on the allocated resources to the VMs using the following table:
@@ -41,7 +40,7 @@ You can calculate the system requirements based on the allocated resources to th
These numbers give approximately the following requirements for the default topologies:
-* Spine-Leaf: 54 vCPUs, 49664 MB, 550 GB disk
+* Spine-Leaf: 46 vCPUs, 39424 MB, 450 GB disk
* Mesh (2 leaves): 22 vCPUs, 19456 MB, 240 GB disk
* If gateway is enabled it adds 8 vCPUs, 6GB RAM, and 50GB disk
diff --git a/docs/vlab/running.md b/docs/vlab/running.md
index 68120c00f..25dbde9e7 100644
--- a/docs/vlab/running.md
+++ b/docs/vlab/running.md
@@ -5,11 +5,11 @@ before running VLAB.
## Initialize VLAB
-First, initialize Fabricator by running `hhfab init --dev --gw`. This command creates the `fab.yaml` file, which is the main configuration file for the fabric. The `--gw` flag enables the gateway. This command supports several customization options that are listed in the output of `hhfab init --help`.
+First, initialize Fabricator by running `hhfab init --dev --gws=2`. This command creates the `fab.yaml` file, which is the main configuration file for the fabric. The `--gws=2` flag enables the gateway and adds two of them. This command supports several customization options that are listed in the output of `hhfab init --help`.
```console
-ubuntu@docs:~$ hhfab init --dev --gw
-10:26:45 INF Hedgehog Fabricator version=v0.43.1
+ubuntu@docs:~$ hhfab init --dev --gws=2
+10:26:45 INF Hedgehog Fabricator version=v0.47.4
10:26:45 INF Generated initial config
10:26:45 INF Adjust configs (incl. credentials, modes, subnets, etc.) file=fab.yaml
10:26:45 INF Include wiring (fabric/gateway) files (.yaml) or adjust imported ones dir=include
@@ -18,25 +18,26 @@ ubuntu@docs:~$ hhfab init --dev --gw
### Spine-Leaf
-To generate a spine-leaf topology, use `hhfab vlab gen`. The following generates an ESLAG (EVPN Multi-Homing) topology:
+To generate a spine-leaf topology, use `hhfab vlab gen`:
```console
-ubuntu@docs:~$ hhfab vlab gen --mclag-leafs-count 0 --eslag-leaf-groups 2
-10:26:46 INF Hedgehog Fabricator version=v0.43.1
-10:26:46 INF Building VLAB wiring diagram fabricMode=spine-leaf
-10:26:46 INF >>> spinesCount=2 fabricLinksCount=2 meshLinksCount=0
-10:26:46 INF >>> eslagLeafGroups=2
-10:26:46 INF >>> gatewayUplinks=2 gatewayDriver=kernel
-10:26:46 INF >>> mclagLeafsCount=0 mclagSessionLinks=0 mclagPeerLinks=0
-10:26:46 INF >>> orphanLeafsCount=1
-10:26:46 INF >>> mclagServers=0 eslagServers=2 unbundledServers=1 bundledServers=1
-10:26:46 INF >>> externalCount=0 externalMclagConnCount=0 externalEslagConnCount=0 externalOrphanConnCount=0
-10:26:46 INF Generated wiring file name=vlab.generated.yaml
+ubuntu@docs:~$ hhfab vlab gen
+17:33:13 INF Hedgehog Fabricator version=v0.47.4
+17:33:13 INF Building VLAB wiring diagram fabricMode=spine-leaf
+17:33:13 INF >>> profile=vs
+17:33:13 INF >>> spinesCount=2 fabricLinksCount=2 meshLinksCount=0
+17:33:13 INF >>> eslagLeafGroups=2
+17:33:13 INF >>> gateways=2 gatewayUplinks=2 gatewayDriver=kernel
+17:33:13 INF >>> orphanLeafsCount=1
+17:33:13 INF >>> eslagServers=2 unbundledServers=1 bundledServers=1 multihomedServers=0
+17:33:13 INF >>> externalBGPCount=0 externalStaticCount=0 externalStaticProxyCount=0
+17:33:13 INF >>> externalEslagConnCount=0 externalOrphanConnCount=0
+17:33:13 INF Generated wiring file name=vlab.generated.yaml
```
-You can customize the topology with flags like `--spines-count` and `--eslag-leaf-groups`. For complete options, run `hhfab vlab gen -h`.
+You can customize the topology with flags like `--spines-count` and `--eslag-leaf-groups`. For a complete list of options, run `hhfab vlab gen -h`.
-The topology with 2 spines, 2 ESLAG leaves, 1 orphan leaf, and a gateway is shown below:
+The resulting topology with 2 spines, 2 ESLAG leaves, 1 orphan leaf, and two gateways is shown below:
```mermaid
graph TD
@@ -54,67 +55,70 @@ classDef legendBox fill:white,stroke:#999,stroke-width:1px,color:#000
%% Network diagram
subgraph Gateways[" "]
- direction LR
- Gateway_1["gateway-1"]
+ direction LR
+ Gateway_1["gateway-1"]
+ Gateway_2["gateway-2"]
end
subgraph Spines[" "]
- direction LR
- subgraph Spine_01_Group [" "]
- direction TB
- Spine_01["spine-01
spine"]
- end
- subgraph Spine_02_Group [" "]
- direction TB
- Spine_02["spine-02
spine"]
- end
+ direction LR
+ subgraph Spine_01_Group [" "]
+ direction TB
+ Spine_01["spine-01
spine"]
+ end
+ subgraph Spine_02_Group [" "]
+ direction TB
+ Spine_02["spine-02
spine"]
+ end
end
subgraph Leaves[" "]
- direction LR
- subgraph Eslag_1 ["eslag-1"]
- direction LR
- Leaf_01["leaf-01
server-leaf"]
- Leaf_02["leaf-02
server-leaf"]
- end
-
- Leaf_03["leaf-03
server-leaf"]
+ direction LR
+ subgraph Eslag_1 ["eslag-1"]
+ direction LR
+ Leaf_01["leaf-01
server-leaf"]
+ Leaf_02["leaf-02
server-leaf"]
+ end
+
+ Leaf_03["leaf-03
server-leaf"]
end
subgraph Servers[" "]
- direction TB
- Server_03["server-03"]
- Server_01["server-01"]
- Server_02["server-02"]
- Server_04["server-04"]
- Server_05["server-05"]
- Server_06["server-06"]
+ direction TB
+ Server_03["server-03"]
+ Server_01["server-01"]
+ Server_02["server-02"]
+ Server_04["server-04"]
+ Server_05["server-05"]
+ Server_06["server-06"]
end
%% Connections
%% Gateway connections
-Gateway_1 ---|"enp2s2↔E1/7"| Spine_02
Gateway_1 ---|"enp2s1↔E1/7"| Spine_01
+Gateway_1 ---|"enp2s2↔E1/7"| Spine_02
+Gateway_2 ---|"enp2s1↔E1/8"| Spine_01
+Gateway_2 ---|"enp2s2↔E1/8"| Spine_02
%% Spine_01 -> Leaves
-Spine_01 ---|"E1/4↔E1/1
E1/5↔E1/2"| Leaf_01
-Spine_01 ---|"E1/6↔E1/4
E1/5↔E1/3"| Leaf_02
Spine_01 ---|"E1/4↔E1/5
E1/5↔E1/6"| Leaf_03
+Spine_01 ---|"E1/4↔E1/1
E1/5↔E1/2"| Leaf_01
+Spine_01 ---|"E1/5↔E1/3
E1/6↔E1/4"| Leaf_02
%% Spine_02 -> Leaves
-Spine_02 ---|"E1/7↔E1/3
E1/8↔E1/4"| Leaf_02
Spine_02 ---|"E1/6↔E1/1
E1/7↔E1/2"| Leaf_01
Spine_02 ---|"E1/6↔E1/5
E1/7↔E1/6"| Leaf_03
+Spine_02 ---|"E1/7↔E1/3
E1/8↔E1/4"| Leaf_02
%% Leaves -> Servers
-Leaf_01 ---|"enp2s1↔E1/2"| Server_02
Leaf_01 ---|"enp2s1↔E1/1"| Server_01
+Leaf_01 ---|"enp2s1↔E1/2"| Server_02
Leaf_01 ---|"enp2s1↔E1/3"| Server_03
-Leaf_02 ---|"enp2s1↔E1/3
enp2s2↔E1/4"| Server_04
-Leaf_02 ---|"enp2s2↔E1/2"| Server_02
Leaf_02 ---|"enp2s2↔E1/1"| Server_01
+Leaf_02 ---|"enp2s2↔E1/2"| Server_02
+Leaf_02 ---|"enp2s1↔E1/3
enp2s2↔E1/4"| Server_04
Leaf_03 ---|"enp2s1↔E1/2
enp2s2↔E1/3"| Server_06
Leaf_03 ---|"enp2s1↔E1/1"| Server_05
@@ -124,17 +128,17 @@ Leaf_03 ---|"enp2s1↔E1/1"| Server_05
%% External connections
subgraph Legend["Network Connection Types"]
- direction LR
- %% Create invisible nodes for the start and end of each line
- L1(( )) --- |"Fabric Links"| L2(( ))
- L5(( )) --- |"Bundled Server Links (x2)"| L6(( ))
- L7(( )) --- |"Unbundled Server Links"| L8(( ))
- L9(( )) --- |"ESLAG Server Links"| L10(( ))
- L11(( )) --- |"Gateway Links"| L12(( ))
- P1(( )) --- |"Label Notation: Downstream ↔ Upstream"| P2(( ))
+ direction LR
+ %% Create invisible nodes for the start and end of each line
+ L1(( )) --- |"Fabric Links"| L2(( ))
+ L5(( )) --- |"Bundled Server Links (x2)"| L6(( ))
+ L7(( )) --- |"Unbundled Server Links"| L8(( ))
+ L9(( )) --- |"ESLAG Server Links"| L10(( ))
+ L11(( )) --- |"Gateway Links"| L12(( ))
+ P1(( )) --- |"Label Notation: Downstream ↔ Upstream"| P2(( ))
end
-class Gateway_1 gateway
+class Gateway_1,Gateway_2 gateway
class Spine_01,Spine_02 spine
class Leaf_01,Leaf_02,Leaf_03 leaf
class Server_03,Server_01,Server_02,Server_04,Server_05,Server_06 server
@@ -142,17 +146,17 @@ class Eslag_1 eslag
class L1,L2,L3,L4,L5,L6,L7,L8,L9,L10,L11,L12,P1,P2 hidden
class Legend legendBox
linkStyle default stroke:#666,stroke-width:2px
-linkStyle 0,1 stroke:#CC9900,stroke-width:2px
-linkStyle 2,3,4,5,6,7 stroke:#CC3333,stroke-width:4px
-linkStyle 11,14 stroke:#66CC66,stroke-width:4px
-linkStyle 8,9,12,13 stroke:#CC9900,stroke-width:4px,stroke-dasharray:5 5
-linkStyle 10,15 stroke:#999999,stroke-width:2px
-linkStyle 16 stroke:#B85450,stroke-width:2px
-linkStyle 17 stroke:#82B366,stroke-width:2px
-linkStyle 18 stroke:#000000,stroke-width:2px
-linkStyle 19 stroke:#CC9900,stroke-width:2px,stroke-dasharray:5 5
-linkStyle 20 stroke:#CC9900,stroke-width:2px
-linkStyle 21 stroke:#FFFFFF
+linkStyle 0,1,2,3 stroke:#CC9900,stroke-width:2px
+linkStyle 4,5,6,7,8,9 stroke:#CC3333,stroke-width:4px
+linkStyle 15,16 stroke:#66CC66,stroke-width:4px
+linkStyle 10,11,13,14 stroke:#CC9900,stroke-width:4px,stroke-dasharray:5 5
+linkStyle 12,17 stroke:#999999,stroke-width:2px
+linkStyle 18 stroke:#B85450,stroke-width:2px
+linkStyle 19 stroke:#82B366,stroke-width:2px
+linkStyle 20 stroke:#000000,stroke-width:2px
+linkStyle 21 stroke:#CC9900,stroke-width:2px,stroke-dasharray:5 5
+linkStyle 22 stroke:#CC9900,stroke-width:2px
+linkStyle 23 stroke:#FFFFFF
%% Make subgraph containers invisible
style Gateways fill:none,stroke:none
@@ -174,14 +178,17 @@ For example, to create a mesh topology with 2 links between each pair of leaves,
```console
ubuntu@docs:~$ hhfab vlab gen --mesh-links-count 2
-13:24:58 INF Hedgehog Fabricator version=v0.41.3
-13:24:58 INF Building VLAB wiring diagram fabricMode=spine-leaf
-13:24:58 INF >>> spinesCount=0 fabricLinksCount=0 meshLinksCount=2
-13:24:58 INF >>> eslagLeafGroups=2
-13:24:58 INF >>> mclagLeafsCount=0 mclagSessionLinks=0 mclagPeerLinks=0
-13:24:58 INF >>> orphanLeafsCount=1
-13:24:58 INF >>> mclagServers=2 eslagServers=2 unbundledServers=1 bundledServers=1
-13:24:58 INF Generated wiring file name=vlab.generated.yaml
+18:14:56 INF Hedgehog Fabricator version=v0.47.4
+18:14:56 INF Building VLAB wiring diagram fabricMode=spine-leaf
+18:14:56 INF >>> profile=vs
+18:14:56 INF >>> spinesCount=0 fabricLinksCount=0 meshLinksCount=2
+18:14:56 INF >>> eslagLeafGroups=2
+18:14:56 INF >>> gateways=2 gatewayUplinks=2 gatewayDriver=kernel
+18:14:56 INF >>> orphanLeafsCount=1
+18:14:56 INF >>> eslagServers=2 unbundledServers=1 bundledServers=1 multihomedServers=0
+18:14:56 INF >>> externalBGPCount=0 externalStaticCount=0 externalStaticProxyCount=0
+18:14:56 INF >>> externalEslagConnCount=0 externalOrphanConnCount=0
+18:14:56 INF Generated wiring file name=vlab.generated.yaml
```
The default topology generated in this case will have 2 ESLAG leaves and 1 orphan leaf. Below is the corresponding diagram:
@@ -201,12 +208,18 @@ classDef hidden fill:none,stroke:none
classDef legendBox fill:white,stroke:#999,stroke-width:1px,color:#000
%% Network diagram
+subgraph Gateways[" "]
+ direction LR
+ Gateway_1["gateway-1"]
+ Gateway_2["gateway-2"]
+end
+
subgraph Leaves[" "]
direction LR
- subgraph ESLAG [ESLAG]
+ subgraph Eslag_1 ["eslag-1"]
direction LR
- Leaf_01["leaf-01
server-leaf"]
Leaf_02["leaf-02
server-leaf"]
+ Leaf_01["leaf-01
server-leaf"]
end
Leaf_03["leaf-03
server-leaf"]
@@ -214,32 +227,38 @@ end
subgraph Servers[" "]
direction TB
- Server_03["server-03"]
+ Server_04["server-04"]
Server_01["server-01"]
Server_02["server-02"]
- Server_04["server-04"]
+ Server_03["server-03"]
Server_05["server-05"]
Server_06["server-06"]
end
%% Connections
+%% Gateway connections
+Gateway_2 ---|"enp2s2↔E1/10"| Leaf_02
+Gateway_2 ---|"enp2s1↔E1/9"| Leaf_01
+Gateway_1 ---|"enp2s1↔E1/8"| Leaf_01
+Gateway_1 ---|"enp2s2↔E1/9"| Leaf_02
+
%% Leaves -> Servers
+Leaf_01 ---|"enp2s1↔E1/2"| Server_02
Leaf_01 ---|"enp2s1↔E1/3"| Server_03
Leaf_01 ---|"enp2s1↔E1/1"| Server_01
-Leaf_01 ---|"enp2s1↔E1/2"| Server_02
-Leaf_02 ---|"enp2s2↔E1/1"| Server_01
Leaf_02 ---|"enp2s2↔E1/2"| Server_02
Leaf_02 ---|"enp2s1↔E1/3
enp2s2↔E1/4"| Server_04
+Leaf_02 ---|"enp2s2↔E1/1"| Server_01
-Leaf_03 ---|"enp2s1↔E1/1"| Server_05
Leaf_03 ---|"enp2s1↔E1/2
enp2s2↔E1/3"| Server_06
+Leaf_03 ---|"enp2s1↔E1/1"| Server_05
%% Mesh connections
-Leaf_01 ---|"E1/6↔E1/5
E1/5↔E1/4"| Leaf_02
+Leaf_01 ---|"E1/5↔E1/4
E1/6↔E1/5"| Leaf_02
Leaf_02 ---|"E1/6↔E1/7
E1/7↔E1/8"| Leaf_03
-Leaf_01 ---|"E1/4↔E1/6
E1/5↔E1/7"| Leaf_03
+Leaf_01 ---|"E1/5↔E1/7
E1/4↔E1/6"| Leaf_03
%% External connections
@@ -247,29 +266,34 @@ subgraph Legend["Network Connection Types"]
direction LR
%% Create invisible nodes for the start and end of each line
L15(( )) --- |"Mesh Links"| L16(( ))
- L5(( )) --- |"Bundled Server Links"| L6(( ))
+ L5(( )) --- |"Bundled Server Links (x2)"| L6(( ))
L7(( )) --- |"Unbundled Server Links"| L8(( ))
L9(( )) --- |"ESLAG Server Links"| L10(( ))
+ L11(( )) --- |"Gateway Links"| L12(( ))
P1(( )) --- |"Label Notation: Downstream ↔ Upstream"| P2(( ))
end
-class Leaf_01,Leaf_02,Leaf_03 leaf
-class Server_03,Server_01,Server_02,Server_04,Server_05,Server_06 server
-class ESLAG eslag
+class Gateway_1,Gateway_2 gateway
+class Leaf_02,Leaf_01,Leaf_03 leaf
+class Server_04,Server_01,Server_02,Server_03,Server_05,Server_06 server
+class Eslag_1 eslag
class L1,L2,L3,L4,L5,L6,L7,L8,L9,L10,L11,L12,P1,P2,L15,L16 hidden
class Legend legendBox
linkStyle default stroke:#666,stroke-width:2px
-linkStyle 8,9,10 stroke:#0078D4,stroke-width:4px
-linkStyle 5,7 stroke:#66CC66,stroke-width:4px
-linkStyle 1,2,3,4 stroke:#CC9900,stroke-width:4px,stroke-dasharray:5 5
-linkStyle 0,6 stroke:#999999,stroke-width:2px
-linkStyle 11 stroke:#0078D4,stroke-width:2px
-linkStyle 12 stroke:#82B366,stroke-width:2px
-linkStyle 13 stroke:#000000,stroke-width:2px
-linkStyle 14 stroke:#CC9900,stroke-width:2px,stroke-dasharray:5 5
-linkStyle 15 stroke:#FFFFFF
+linkStyle 0,1,2,3 stroke:#CC9900,stroke-width:2px
+linkStyle 12,13,14 stroke:#0078D4,stroke-width:4px
+linkStyle 8,10 stroke:#66CC66,stroke-width:4px
+linkStyle 4,6,7,9 stroke:#CC9900,stroke-width:4px,stroke-dasharray:5 5
+linkStyle 5,11 stroke:#999999,stroke-width:2px
+linkStyle 15 stroke:#0078D4,stroke-width:2px
+linkStyle 16 stroke:#82B366,stroke-width:2px
+linkStyle 17 stroke:#000000,stroke-width:2px
+linkStyle 18 stroke:#CC9900,stroke-width:2px,stroke-dasharray:5 5
+linkStyle 19 stroke:#CC9900,stroke-width:2px
+linkStyle 20 stroke:#FFFFFF
%% Make subgraph containers invisible
+style Gateways fill:none,stroke:none
style Leaves fill:none,stroke:none
style Servers fill:none,stroke:none
```
@@ -277,7 +301,8 @@ style Servers fill:none,stroke:none
### Gateway
The gateway is enabled by adding the `--gw` flag to `hhfab init`. It connects to two spines in spine-leaf topology
-or two leaves in mesh topology. The number of uplinks can be controlled using flags on `hhfab vlab gen`.
+or two leaves in mesh topology. Multiple gateways can be used e.g. by using the `--gws=2` flag.
+The number of uplinks can be controlled using flags on `hhfab vlab gen`.
### Lightweight Spine-Leaf
A default spine-leaf topology in VLAB requests more CPU and RAM than is commonly available. The lightweight
@@ -287,14 +312,17 @@ Host, and 1 normal host. To launch the lightweight spine-leaf topology use the f
```console
ubuntu@docs:~$ hhfab vlab gen --eslag-leaf-groups=2 --spines-count=1 --bundled-servers=0 --eslag-servers=1 --unbundled-servers=1
-20:10:16 INF Hedgehog Fabricator version=v0.42.0
-20:10:16 INF Building VLAB wiring diagram fabricMode=spine-leaf
-20:10:16 INF >>> spinesCount=1 fabricLinksCount=2 meshLinksCount=0
-20:10:16 INF >>> eslagLeafGroups=2
-20:10:16 INF >>> mclagLeafsCount=0 mclagSessionLinks=0 mclagPeerLinks=0
-20:10:16 INF >>> orphanLeafsCount=0
-20:10:16 INF >>> mclagServers=2 eslagServers=1 unbundledServers=1 bundledServers=0
-20:10:16 INF Generated wiring file name=vlab.generated.yaml
+18:27:19 INF Hedgehog Fabricator version=v0.47.4
+18:27:19 INF Building VLAB wiring diagram fabricMode=spine-leaf
+18:27:19 INF >>> profile=vs
+18:27:19 INF >>> spinesCount=1 fabricLinksCount=2 meshLinksCount=0
+18:27:19 INF >>> eslagLeafGroups=2
+18:27:19 INF >>> gateways=1 gatewayUplinks=1 gatewayDriver=kernel
+18:27:19 INF >>> orphanLeafsCount=0
+18:27:19 INF >>> eslagServers=1 unbundledServers=1 bundledServers=0 multihomedServers=0
+18:27:19 INF >>> externalBGPCount=0 externalStaticCount=0 externalStaticProxyCount=0
+18:27:19 INF >>> externalEslagConnCount=0 externalOrphanConnCount=0
+18:27:19 INF Generated wiring file name=vlab.generated.yaml
```
The lightweight spine-leaf topology looks like this:
@@ -303,72 +331,95 @@ The lightweight spine-leaf topology looks like this:
graph TD
%% Style definitions
+classDef gateway fill:#FFF2CC,stroke:#999,stroke-width:1px,color:#000
classDef spine fill:#F8CECC,stroke:#B85450,stroke-width:1px,color:#000
classDef leaf fill:#DAE8FC,stroke:#6C8EBF,stroke-width:1px,color:#000
classDef server fill:#D5E8D4,stroke:#82B366,stroke-width:1px,color:#000
+classDef mclag fill:#F0F8FF,stroke:#6C8EBF,stroke-width:1px,color:#000
classDef eslag fill:#FFF8E8,stroke:#CC9900,stroke-width:1px,color:#000
+classDef external fill:#FFCC99,stroke:#D79B00,stroke-width:1px,color:#000
classDef hidden fill:none,stroke:none
classDef legendBox fill:white,stroke:#999,stroke-width:1px,color:#000
%% Network diagram
+subgraph Gateways[" "]
+ direction LR
+ Gateway_1["gateway-1"]
+end
+
subgraph Spines[" "]
- direction LR
- subgraph Spine_01_Group [" "]
- direction TB
- Spine_01["spine-01
spine"]
- end
+ direction LR
+ subgraph Spine_01_Group [" "]
+ direction TB
+ Spine_01["spine-01
spine"]
+ end
end
subgraph Leaves[" "]
- direction LR
- subgraph Eslag_1 ["eslag-1"]
- direction LR
- Leaf_01["leaf-01
server-leaf"]
- Leaf_02["leaf-02
server-leaf"]
- end
+ direction LR
+ subgraph Eslag_1 ["eslag-1"]
+ direction LR
+ Leaf_01["leaf-01
server-leaf"]
+ Leaf_02["leaf-02
server-leaf"]
+ end
end
subgraph Servers[" "]
- direction TB
- Server_02["server-02"]
- Server_01["server-01"]
+ direction TB
+ Server_02["server-02"]
+ Server_01["server-01"]
end
%% Connections
+%% Gateway connections
+Gateway_1 ---|"enp2s1↔E1/5"| Spine_01
+
%% Spine_01 -> Leaves
-Spine_01 --- Leaf_01
-Spine_01 --- Leaf_02
+Spine_01 ---|"E1/4↔E1/2
E1/3↔E1/1"| Leaf_01
+Spine_01 ---|"E1/2↔E1/3
E1/3↔E1/4"| Leaf_02
%% Leaves -> Servers
-Leaf_01 --- Server_01
-Leaf_01 --- Server_02
-Leaf_02 --- Server_01
+Leaf_01 ---|"enp2s1↔E1/1"| Server_01
+Leaf_01 ---|"enp2s1↔E1/2"| Server_02
+
+Leaf_02 ---|"enp2s2↔E1/1"| Server_01
+
+%% Mesh connections
+
+%% External connections
subgraph Legend["Network Connection Types"]
- direction LR
- %% Create invisible nodes for the start and end of each line
- L1(( )) --- |"Fabric Links"| L2(( ))
- L7(( )) --- |"Unbundled Server Links"| L8(( ))
- L9(( )) --- |"ESLAG Server Links"| L10(( ))
+ direction LR
+ %% Create invisible nodes for the start and end of each line
+ L1(( )) --- |"Fabric Links"| L2(( ))
+ L7(( )) --- |"Unbundled Server Links"| L8(( ))
+ L9(( )) --- |"ESLAG Server Links"| L10(( ))
+ L11(( )) --- |"Gateway Links"| L12(( ))
+ P1(( )) --- |"Label Notation: Downstream ↔ Upstream"| P2(( ))
end
+class Gateway_1 gateway
class Spine_01 spine
class Leaf_01,Leaf_02 leaf
class Server_02,Server_01 server
class Eslag_1 eslag
-class L1,L2,L7,L8,L9,L10 hidden
+class L1,L2,L3,L4,L5,L6,L7,L8,L9,L10,L11,L12,P1,P2 hidden
class Legend legendBox
linkStyle default stroke:#666,stroke-width:2px
-linkStyle 0,1 stroke:#CC3333,stroke-width:4px
-linkStyle 2,4 stroke:#CC9900,stroke-width:4px,stroke-dasharray:5 5
-linkStyle 3 stroke:#999999,stroke-width:2px
-linkStyle 5 stroke:#B85450,stroke-width:2px
-linkStyle 6 stroke:#000000,stroke-width:2px
-linkStyle 7 stroke:#CC9900,stroke-width:2px,stroke-dasharray:5 5
+linkStyle 0 stroke:#CC9900,stroke-width:2px
+linkStyle 1,2 stroke:#CC3333,stroke-width:4px
+linkStyle 3,5 stroke:#CC9900,stroke-width:4px,stroke-dasharray:5 5
+linkStyle 4 stroke:#999999,stroke-width:2px
+linkStyle 6 stroke:#B85450,stroke-width:2px
+linkStyle 7 stroke:#000000,stroke-width:2px
+linkStyle 8 stroke:#CC9900,stroke-width:2px,stroke-dasharray:5 5
+linkStyle 9 stroke:#CC9900,stroke-width:2px
+linkStyle 10 stroke:#FFFFFF
%% Make subgraph containers invisible
+style Gateways fill:none,stroke:none
style Spines fill:none,stroke:none
style Leaves fill:none,stroke:none
style Servers fill:none,stroke:none
diff --git a/docs/vlab/virt-externals.md b/docs/vlab/virt-externals.md
index c7428b3cc..d26b0df71 100644
--- a/docs/vlab/virt-externals.md
+++ b/docs/vlab/virt-externals.md
@@ -13,14 +13,10 @@ using either Fabric or Gateway external peerings.
## Creating the topology
-Externals can be connected to any non-MCLAG leaf, whether in a spine-leaf topology or
-a mesh one.
+Externals can be connected to any leaf, whether in a spine-leaf topology or a mesh one.
!!! warning
- Due to a [known limitation](../known-limitations/known-limitations.md#external-peering-over-a-connection-originating-from-an-mclag-switch-can-fail)
- with MCLAG and external peerings, connecting externals to MCLAG leaves is not recommended.
-
- Additionally, due to a limitation of the SONiC virtual switch implementation, having more than one
+ Due to a limitation of the SONiC virtual switch implementation, having more than one
external connection between virtual switches and an external will cause issues.
This limitation does not apply to physical switches.
@@ -34,17 +30,16 @@ ubuntu@docs:~/hhfab$ ./hhfab init -f --dev --gw
09:27:35 INF Generated initial config
09:27:35 INF Adjust configs (incl. credentials, modes, subnets, etc.) file=fab.yaml
09:27:35 INF Include wiring (fabric/gateway) files (.yaml) or adjust imported ones dir=include
-ubuntu@docs:~/hhfab$ ./hhfab vlab gen --mclag-leafs-count=0 --eslag-leaf-groups=2 --orphan-leafs-count=1 --externals-bgp=1 --external-orphan-connections=1
+ubuntu@docs:~/hhfab$ ./hhfab vlab gen --eslag-leaf-groups=2 --orphan-leafs-count=1 --externals-bgp=1 --external-orphan-connections=1
09:28:36 INF Hedgehog Fabricator version=v0.43.1
09:28:36 INF Building VLAB wiring diagram fabricMode=spine-leaf
09:28:36 INF >>> spinesCount=2 fabricLinksCount=2 meshLinksCount=0
09:28:36 INF >>> eslagLeafGroups=2
09:28:36 INF >>> gatewayUplinks=2 gatewayDriver=kernel
-09:28:36 INF >>> mclagLeafsCount=0 mclagSessionLinks=0 mclagPeerLinks=0
09:28:36 INF >>> orphanLeafsCount=1
-09:28:36 INF >>> mclagServers=0 eslagServers=2 unbundledServers=1 bundledServers=1
+09:28:36 INF >>> eslagServers=2 unbundledServers=1 bundledServers=1
09:28:36 INF >>> externalBGPCount=1 externalStaticCount=0 externalStaticProxyCount=0
-09:28:36 INF >>> externalMclagConnCount=0 externalEslagConnCount=0 externalOrphanConnCount=1
+09:28:36 INF >>> externalEslagConnCount=0 externalOrphanConnCount=1
09:28:36 INF Generated wiring file name=vlab.generated.yaml
ubuntu@docs:~/hhfab$ ./hhfab vlab up -f -m=manual -r=wait
09:31:53 INF Hedgehog Fabricator version=v0.43.1
@@ -62,7 +57,6 @@ classDef gateway fill:#FFF2CC,stroke:#999,stroke-width:1px,color:#000
classDef spine fill:#F8CECC,stroke:#B85450,stroke-width:1px,color:#000
classDef leaf fill:#DAE8FC,stroke:#6C8EBF,stroke-width:1px,color:#000
classDef server fill:#D5E8D4,stroke:#82B366,stroke-width:1px,color:#000
-classDef mclag fill:#F0F8FF,stroke:#6C8EBF,stroke-width:1px,color:#000
classDef eslag fill:#FFF8E8,stroke:#CC9900,stroke-width:1px,color:#000
classDef external fill:#FFCC99,stroke:#D79B00,stroke-width:1px,color:#000
classDef hidden fill:none,stroke:none