Merge branch 'master' into pr/fredi/gw_failover

Author: Fredi-raspall

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: MCLAG Peer Link, Unbundled/MCLAG server connections, Fabric connection between spine and leaf
+    * for example: Fabric connection between spine and leaf, and server connections like Unbundled, Bundled, MCLAG, or ESLAG.
 * __VLANNamespace__ -> non-overlapping VLAN ranges for attaching servers
 * __IPv4Namespace__ -> non-overlapping IPv4 ranges for VPC subnets
 

docs/install-upgrade/build-wiring.md

@@ -42,7 +42,7 @@ spec:
 
 1. See the [list](../reference/profiles.md) of profile names
 2. More information in the [User Guide](../user-guide/profiles.md#port-naming)
-3. Could be MCLAG, ESLAG or nothing, more details in [Redundancy
+3. Could be ESLAG or nothing, more details in [Redundancy
    Groups](../user-guide/devices.md#redundancy-groups)
 
 ## Design Discussion
@@ -79,12 +79,11 @@ A connection represents the physical wires in your data center. They connect swi
 
 #### Server Connections
 
-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:
+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 (Unbundled, Bundled, ESLAG, 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:
 
 - *Unbundled* - A single cable connecting switch to server.
 - *Bundled* - Two or more cables going to a single switch, a LAG or similar.
-- *MCLAG* -  Two cables going to two different switches, also called dual homing. The switches will need a fabric link between them.
-- *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.
+- *ESLAG* - Two to four cables going to different switches, also called multi-homing (EVPN-MH). If four links are used there will need to be four switches connected to a single server with four NIC ports.
 
 ``` mermaid
 graph TD
@@ -95,45 +94,33 @@ graph TD
     L3([Leaf 3])
     L4([Leaf 4])
     L5([Leaf 5])
-    L6([Leaf 6])
-    L7([Leaf 7])
 
     TS1[Server1]
     TS2[Server2]
     TS3[Server3]
-    TS4[Server4]
 
-    S1 & S2 ---- L1 & L2 & L3 & L4 & L5 & L6 & L7
+    S1 & S2 ---- L1 & L2 & L3 & L4 & L5
     L1 <-- Bundled --> TS1
     L1 <-- Bundled --> TS1
     L1 <-- Unbundled --> TS2
-    L2 <-- MCLAG --> TS3
-    L3 <-- MCLAG --> TS3
-    L4 <-- ESLAG --> TS4
-    L5 <-- ESLAG --> TS4
-    L6 <-- ESLAG --> TS4
-    L7 <-- ESLAG --> TS4
+    L2 <-- ESLAG --> TS3
+    L3 <-- ESLAG --> TS3
+    L4 <-- ESLAG --> TS3
+    L5 <-- ESLAG --> TS3
 
     subgraph VPC 1
     TS1
     TS2
     TS3
-    TS4
-    end
-    
-    subgraph MCLAG
-    L2
-    L3
     end
 
     subgraph ESLAG
+    L2
     L3
     L4
     L5
-    L6
-    L7
     end
-    
+
 ```
 #### Fabric Connections
 

docs/reference/gateway-api.md.gen

@@ -199,7 +199,6 @@ GatewaySpec defines the desired state of Gateway.
 
 _Appears in:_
 - [Gateway](#gateway)
-- [GatewayAgentSpec](#gatewayagentspec)
 
 | Field | Description | Default | Validation |
 | --- | --- | --- | --- |
@@ -346,7 +345,6 @@ PeeringSpec defines the desired state of Peering.
 
 
 _Appears in:_
-- [GatewayAgentSpec](#gatewayagentspec)
 - [Peering](#peering)
 
 | Field | Description | Default | Validation |
@@ -426,7 +424,6 @@ VPCInfoSpec defines the desired state of VPCInfo.
 
 _Appears in:_
 - [VPCInfo](#vpcinfo)
-- [VPCInfoData](#vpcinfodata)
 
 | Field | Description | Default | Validation |
 | --- | --- | --- | --- |
@@ -444,7 +441,6 @@ VPCInfoStatus defines the observed state of VPCInfo.
 
 _Appears in:_
 - [VPCInfo](#vpcinfo)
-- [VPCInfoData](#vpcinfodata)
 
 | Field | Description | Default | Validation |
 | --- | --- | --- | --- |
@@ -460,7 +456,6 @@ _Appears in:_
 
 
 _Appears in:_
-- [VPCInfoData](#vpcinfodata)
 - [VPCInfoSpec](#vpcinfospec)
 
 | Field | Description | Default | Validation |
@@ -662,48 +657,9 @@ GatewayAgent is the Schema for the gatewayagents API.
 | `apiVersion` _string_ | `gwint.githedgehog.com/v1alpha1` | | |
 | `kind` _string_ | `GatewayAgent` | | |
 | `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. |  |  |
-| `spec` _[GatewayAgentSpec](#gatewayagentspec)_ |  |  |  |
 | `status` _[GatewayAgentStatus](#gatewayagentstatus)_ |  |  |  |
 
 
-#### GatewayAgentSpec
-
-
-
-GatewayAgentSpec defines the desired state of GatewayAgent.
-
-
-
-_Appears in:_
-- [GatewayAgent](#gatewayagent)
-
-| Field | Description | Default | Validation |
-| --- | --- | --- | --- |
-| `agentVersion` _string_ | AgentVersion is the desired version of the gateway agent to trigger generation changes on controller upgrades |  |  |
-| `gateway` _[GatewaySpec](#gatewayspec)_ |  |  |  |
-| `vpcs` _object (keys:string, values:[VPCInfoData](#vpcinfodata))_ |  |  |  |
-| `peerings` _object (keys:string, values:[PeeringSpec](#peeringspec))_ |  |  |  |
-| `groups` _object (keys:string, values:[GatewayGroupInfo](#gatewaygroupinfo))_ |  |  |  |
-| `communities` _object (keys:string, values:string)_ |  |  |  |
-| `config` _[GatewayAgentSpecConfig](#gatewayagentspecconfig)_ |  |  |  |
-
-
-#### GatewayAgentSpecConfig
-
-
-
-
-
-
-
-_Appears in:_
-- [GatewayAgentSpec](#gatewayagentspec)
-
-| Field | Description | Default | Validation |
-| --- | --- | --- | --- |
-| `fabricBFD` _boolean_ | FabricBFD defines if fabric-facing links should be configured with BFD |  |  |
-
-
 #### GatewayAgentStatus
 
 
@@ -724,40 +680,6 @@ _Appears in:_
 | `state` _[GatewayState](#gatewaystate)_ | State represents collected data from the dataplane API that includes FRR as well |  |  |
 
 
-#### GatewayGroupInfo
-
-
-
-
-
-
-
-_Appears in:_
-- [GatewayAgentSpec](#gatewayagentspec)
-
-| Field | Description | Default | Validation |
-| --- | --- | --- | --- |
-| `members` _[GatewayGroupMember](#gatewaygroupmember) array_ |  |  |  |
-
-
-#### GatewayGroupMember
-
-
-
-
-
-
-
-_Appears in:_
-- [GatewayGroupInfo](#gatewaygroupinfo)
-
-| Field | Description | Default | Validation |
-| --- | --- | --- | --- |
-| `name` _string_ |  |  |  |
-| `priority` _integer_ |  |  |  |
-| `vtepIP` _string_ |  |  |  |
-
-
 #### GatewayState
 
 
@@ -799,24 +721,6 @@ _Appears in:_
 | `pps` _float_ | PktsPerSecond is the number of packets sent per second on the peering |  |  |
 
 
-#### VPCInfoData
-
-
-
-
-
-
-
-_Appears in:_
-- [GatewayAgentSpec](#gatewayagentspec)
-
-| Field | Description | Default | Validation |
-| --- | --- | --- | --- |
-| `subnets` _object (keys:string, values:[VPCInfoSubnet](#vpcinfosubnet))_ | Subnets is a map of all subnets in the VPC (incl. CIDRs, VNIs, etc) keyed by the subnet name |  |  |
-| `vni` _integer_ | VNI is the VNI for the VPC |  |  |
-| `internalID` _string_ |  |  |  |
-
-
 #### VPCStatus
 
 

docs/reference/profiles.md

@@ -28,6 +28,9 @@ features and port naming scheme.
 
 ## Switch Feature Matrix
 
+!!! warning "MCLAG Deprecation"
+    MCLAG is being deprecated in favor of ESLAG (EVPN Multi-Homing) for multi-homing. While still supported, it is recommended to use ESLAG for new deployments.
+
 The following table shows which features are supported by each switch profile:
 
 | Switch Profile | Subinterfaces | ACLs | L2VNI | L3VNI | RoCE | MCLAG | ESLAG | QPN |

docs/troubleshooting/overview.md

@@ -10,22 +10,20 @@ command:
 ```console
 core@control-1 ~ $ kubectl fabric inspect fabric
 Switches:
-NAME        PROFILE           ROLE           GROUPS     SERIAL       STATE    GEN    APPLIED          HEARTBEAT
-leaf-01     Virtual Switch    server-leaf    mclag-1    000000000    Ready    1/1    4 minutes ago    15 seconds ago
-leaf-02     Virtual Switch    server-leaf    mclag-1    000000000    Ready    1/1    3 minutes ago    19 seconds ago
-leaf-03     Virtual Switch    server-leaf    eslag-1    000000000    Ready    2/2    5 minutes ago    12 seconds ago
-leaf-04     Virtual Switch    server-leaf    eslag-1    000000000    Ready    2/2    3 minutes ago    17 seconds ago
-leaf-05     Virtual Switch    server-leaf               000000000    Ready    2/2    5 minutes ago    9 seconds ago
-spine-01    Virtual Switch    spine                     000000000    Ready    1/1    3 minutes ago    19 seconds ago
-spine-02    Virtual Switch    spine                     000000000    Ready    2/2    4 minutes ago    1 second ago
+NAME        PROFILE           ROLE           GROUPS     SERIAL                 STATE    GEN    APPLIED           HEARTBEAT
+leaf-01     Virtual Switch    server-leaf    eslag-1    0000000000000000000    Ready    1/1    10 minutes ago    22 seconds ago
+leaf-02     Virtual Switch    server-leaf    eslag-1    0000000000000000000    Ready    1/1    21 minutes ago    19 seconds ago
+leaf-03     Virtual Switch    server-leaf               0000000000000000000    Ready    1/1    38 minutes ago    10 seconds ago
+spine-01    Virtual Switch    spine                     0000000000000000000    Ready    1/1    15 minutes ago    10 seconds ago
+spine-02    Virtual Switch    spine                     0000000000000000000    Ready    1/1    45 minutes ago    24 seconds ago
 ```
 
 The output above is from the virtual testing environment. In a deployment of physical
 switches, the profile would match the profile of the switch, and the correct
 serial number would be displayed.
 
 The `GROUP` column will be populated if you have redundancy configured on the
-switches, either MCLAG, or ESLAG.
+switches, such as ESLAG (EVPN Multi-Homing).
 
 The `GEN` column shows the applied/current generation. If the numbers are equal
 then there are no pending changes for the switches.