githedgehog · edipascale · Jun 18, 2026
@@ -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.
@@ -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
 

@@ -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
 

@@ -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.

@@ -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:

@@ -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)
 

@@ -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
-```
@@ -171,9 +171,6 @@ spec:
   ...
 ```
 
-!!! warning "MCLAG Deprecated"
-    MCLAG is being deprecated. Use ESLAG for multi-homing instead.
-
 ## Servers
 
 Regular workload server:

@@ -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

@@ -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

@@ -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`