Damien
370782da62
feat: Update objects list in .infrahub.yml to match infrahub/objects folder
...
- Swap order of vrfs (10) and bgp-sessions (11) to reflect renumbering
- Add new object files: 13-ipam-links.yml and 14-fabric-links.yml
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com >
2026-03-01 20:40:03 +01:00
1dfec839c7
Actualiser .infrahub.yml
2026-03-01 19:38:46 +00:00
833a460ddf
Actualiser .infrahub.yml
2026-03-01 18:27:07 +00:00
68b9e88483
docs: Add README for Infrahub transforms ( #28 )
...
Adds a concise README in `infrahub/transforms/` documenting the 6 available Jinja2 transforms, usage commands, directory structure, and how to add new transforms.
Reviewed-on: #28
2026-03-01 16:29:40 +00:00
1b918a4cbc
feat: Add Infrahub Jinja2 transform for BGP configuration ( #23 ) ( #27 )
...
## Summary
Closes #23 . Implements a single unified `bgp_yang_transform` covering the complete BGP router stanza for all 10 fabric devices.
**Design decision:** One transform (one query + one template) rather than 4 separate transforms, because all BGP components (process config, peer groups, neighbors, AFs) live under a single `router bgp <ASN>` stanza and must be consistent. This avoids multiple API calls per device and keeps the data model coherent.
| File | Description |
|------|-------------|
| `infrahub/transforms/queries/bgp_intent.gql` | Unified GraphQL query — `InfraBGPRouterConfig` (with peer_groups, sessions) + `InfraBGPAddressFamily` (with active_peer_groups, active_sessions, networks, optional vrf) |
| `infrahub/transforms/templates/bgp_yang.j2` | Jinja2 template — renders `bgp.global`, `bgp.peer_groups`, `bgp.neighbors`, `bgp.address_families`, `bgp.vrf_neighbors`, `bgp.vrf_address_families`; returns `[]` for devices with no BGP config |
| `infrahub/transforms/tests/bgp_yang/test.yml` | Smoke check + unit render tests for leaf1, spine1, leaf7 |
| `infrahub/transforms/tests/bgp_yang/leaf1/` | 3 peer-groups, 5 global neighbors, 2 global AFs |
| `infrahub/transforms/tests/bgp_yang/spine1/` | 1 peer-group (evpn/next-hop-unchanged), 16 neighbors (8 direct underlay + 8 EVPN), IPv4 AF activates individual sessions |
| `infrahub/transforms/tests/bgp_yang/leaf7/` | leaf1 pattern + VRF gold border session (AS 64999) + VRF-scoped IPv4 unicast AF |
| `.infrahub.yml` | Registers `bgp_intent` query and `bgp_yang_transform` |
## Validation
| Device | Expected output |
|--------|----------------|
| `leaf1` | 3 peer-groups, 5 global neighbors (underlay×2, iBGP×1, EVPN×2), 2 AFs, empty VRF sections |
| `spine1` | 1 peer-group (evpn, next-hop-unchanged), 16 neighbors (8 direct with `remote_asn`, 8 EVPN via peer-group), IPv4 AF activates individual sessions |
| `leaf7` | Same as leaf1 (AS 65004) + `vrf_neighbors: [{10.90.90.1, AS 64999, VRF gold}]` + `vrf_address_families: [{ipv4, VRF gold, active_sessions: [10.90.90.1]}]` |
```bash
infrahubctl render bgp_yang_transform device_name=leaf1
infrahubctl render bgp_yang_transform device_name=spine1
infrahubctl render bgp_yang_transform device_name=leaf7
```
## Design notes
- Follows identical conventions to existing transforms (#20–#22)
- All optional relationships (`remote_asn`, `peer_group`, `vrf`, `peer_device`, `update_source`, etc.) wrapped in `is defined and is not none` guards
- `send_community` value `"none"` (schema default) is normalised to `null` in the output — keeps the rendered JSON clean for downstream consumers
- VRF-scoped sessions and AFs are separated into `vrf_neighbors` / `vrf_address_families` arrays, each entry carrying a `"vrf"` key, so the template consumer can trivially iterate per-VRF without filtering
2026-03-01 13:22:51 +00:00
cf7da535ed
feat: Add Infrahub Jinja2 transforms for MLAG configuration ( #22 ) ( #26 )
...
## Summary
Closes #22 . Implements Infrahub Jinja2 transforms for MLAG configuration, generating Arista-native YANG-compatible JSON payloads from Infrahub intent data.
| File | Description |
|------|-------------|
| `infrahub/transforms/queries/mlag_intent.gql` | GraphQL query — fetches `InfraMlagPeerConfig` by `$device_name`, including MLAG domain attributes, peer/iBGP VLANs, local interface SVI, and peer-link LAG |
| `infrahub/transforms/templates/mlag_yang.j2` | Jinja2 template — renders a JSON object targeting `/arista-mlag-augments:mlag/config`; returns `[]` for devices with no MLAG (spines) |
| `infrahub/transforms/tests/mlag_yang/test.yml` | Test spec: smoke check + unit render tests for `leaf1` and `spine1` |
| `infrahub/transforms/tests/mlag_yang/leaf1/` | Mock input + expected output for leaf1 (full MLAG config, domain `leafs-1-2`) |
| `infrahub/transforms/tests/mlag_yang/spine1/` | Mock input (empty edges) + expected output `[]` for spine1 |
| `.infrahub.yml` | Registers `mlag_intent` query and `mlag_yang_transform` jinja2 transform |
## Output shape (leaf1)
```json
{
"mlag": {
"config": {
"domain-id": "leafs-1-2",
"peer-link": "Port-Channel999",
"local-interface": "Vlan4090",
"peer-address": "10.0.199.255",
"shutdown": false
},
"dual_primary_detection": {
"enabled": true,
"delay": 10,
"action": "errdisable",
"heartbeat_peer_ip": "172.16.0.50",
"heartbeat_vrf": "mgmt"
},
"virtual_mac": "c001.cafe.babe",
"peer_vlan_id": 4090,
"ibgp_vlan_id": 4091,
"local_interface_ip": "10.0.199.254/31"
}
}
```
## Validation
```bash
infrahubctl render mlag_yang_transform device_name=leaf1 # → MLAG config JSON
infrahubctl render mlag_yang_transform device_name=spine1 # → []
```
## Design notes
- Follows identical conventions to existing transforms (#20 VLAN/interface/VXLAN, #21 VRF/L3VNI)
- All optional relationship accesses wrapped in `is defined and is not none` guards
- Spine/non-MLAG devices return `[]` (empty array) — consistent with the "no data → empty collection" pattern used in vxlan_yang for devices without VTEP
2026-03-01 11:06:55 +00:00
a105e44bbd
feat: Add Infrahub Jinja2 transform for VRF/L3VNI configuration ( #21 ) ( #25 )
...
## Summary
Implements Infrahub Jinja2 Transform for VRF/L3VNI configuration, generating structured JSON payloads from Infrahub intent data. Closes #21 .
## What's included
- **GraphQL query** (`transforms/queries/vrf_intent.gql`): Queries `InfraVRFDeviceAssignment` by device name, fetching VRF details, L3VNI, route targets, and device-specific route distinguisher
- **Jinja2 transform** (`transforms/templates/vrf_yang.j2`): Renders VRF config payloads with defensive null handling (lessons learned from #20 )
- **`.infrahub.yml`** updated with the new query and transform definitions
- **Tests** (`transforms/tests/vrf_yang/`) using correct Infrahub pytest format (`jinja2-transform-smoke` + `jinja2-transform-unit-render`)
## Validation
All transforms render correctly:
| Device | Expected | Result |
|--------|----------|--------|
| `leaf3` | VRF gold, RD `10.0.250.13:1`, L3VNI 100001 | ✅ |
| `leaf7` | VRF gold, RD `10.0.250.17:1`, L3VNI 100001 | ✅ |
| `leaf1` | Empty array (no VRF assignment) | ✅ |
| `spine1` | Empty array (no VRF assignment) | ✅ |
## Usage
```bash
# Local debugging
infrahubctl render vrf_yang_transform device_name=leaf3
# API endpoint
GET /api/transform/jinja2/vrf_yang_transform?device_name=leaf3
```
## Related
- Depends on: #20 (base transforms infrastructure, already merged)
- Reference: Arista EVPN Type-5 / L3VXLAN configuration from lab topology
2026-03-01 10:45:01 +00:00
668e9cbada
feat: Add Infrahub Jinja2 transforms for VLANs, interfaces, and VXLAN ( #20 ) ( #24 )
...
## Summary
Closes #20
Adds Infrahub Jinja2 transforms that query device intent from Infrahub via GraphQL and produce structured JSON payloads (YANG-style) suitable for gNMI Set operations on Arista EOS devices.
- **3 GraphQL queries** — `vlan_intent`, `interface_intent`, `vxlan_intent` — each parameterized by `$device_name`
- **3 Jinja2 templates** — `vlan_yang.j2`, `interface_yang.j2`, `vxlan_yang.j2` — producing JSON arrays/objects from the GraphQL response
- **Integration test fixtures** — one directory per transform with `input.json`, `output.json`, and `test.yml`, using leaf1 from the lab topology as sample device
- **`.infrahub.yml` updated** with `queries` and `jinja2_transforms` sections
## Files added
```
transforms/
├── queries/
│ ├── vlan_intent.gql # VLANs via VTEP mappings + SVI interfaces
│ ├── interface_intent.gql # All interface types with IPs
│ └── vxlan_intent.gql # VTEP config + VLAN/VNI/VRF mappings
├── templates/
│ ├── vlan_yang.j2 # JSON array of VLANs (merged, deduplicated, sorted)
│ ├── interface_yang.j2 # JSON array of interfaces with type discriminator
│ └── vxlan_yang.j2 # JSON object: vtep + vlan_vni + vrf_vni mappings
└── tests/
├── vlan_yang/{input,output,test}.{json,yml}
├── interface_yang/{input,output,test}.{json,yml}
└── vxlan_yang/{input,output,test}.{json,yml}
```
## Transform usage
```bash
# Render locally
infrahubctl render vlan_yang_transform device_name=leaf1
infrahubctl render interface_yang_transform device_name=leaf1
infrahubctl render vxlan_yang_transform device_name=leaf1
# Via API
GET /api/transform/jinja2/vlan_yang_transform?device_name=leaf1
GET /api/transform/jinja2/interface_yang_transform?device_name=leaf1
GET /api/transform/jinja2/vxlan_yang_transform?device_name=leaf1
```
## Test plan
- [x] Load branch into Infrahub (`infrahubctl schema load` + `infrahubctl object load`)
- [x] Run `infrahubctl render vlan_yang_transform device_name=leaf1` and verify JSON output matches expected VLANs (40, 4090, 4091)
- [x] Run `infrahubctl render interface_yang_transform device_name=leaf1` and verify all interface types are present with correct attributes
- [x] Run `infrahubctl render vxlan_yang_transform device_name=leaf1` and verify VTEP source address, UDP port, and VLAN-VNI mapping for VLAN 40 / VNI 110040
- [x] Run `infrahubctl render vxlan_yang_transform device_name=leaf3` and verify VRF gold / L3VNI 100001 appears in `vrf_vni_mappings`
- ~~[ ] Verify `infrahubctl test` passes for all three test fixtures~~
Reviewed-on: #24
2026-02-28 17:42:08 +00:00
e00cf517e3
Merge pull request 'Add bidirectional navigation relationships' ( #18 ) from feat/update-identifiers into main
...
Reviewed-on: #18
2026-02-22 09:27:20 +00:00
Damien
ac1634b561
Add device roles to fabric links
2026-02-22 10:07:27 +01:00
Damien
9a0b6dd1e6
feat(schema): add bidirectional relationship identifiers and fabric-device links
...
- LocationSite: add devices (device__site) and fabrics (fabric__sites) reverse relationships
- InfraDevice.site: add identifier device__site
- InfraDevice: add fabric relationship (fabric__devices)
- InfraFabric.sites: add identifier fabric__sites; add devices reverse relationship (fabric__devices)
- InfraInterfaceVlan.vlan: add identifier vlan__svi
- InfraVLAN: add svi_interfaces reverse relationship (vlan__svi)
- Add 14-fabric-links.yml to assign all 10 devices to the evpn-lab fabric
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com >
2026-02-21 20:59:10 +01:00
Damien
2c1fccee5b
Remove IP addresses from interfaces and add new IPAM links file
2026-02-21 18:08:53 +01:00
Damien
e778fedf71
Add IP addresses to loopback and VLAN interfaces
2026-02-21 18:03:19 +01:00
Damien
4aecc544da
Refactor interface references to use structured format
...
Refactored all interface references in IPAM configuration to use the
structured format with kind and data fields instead of simple lists.
This improves consistency and makes the configuration more maintainable.
2026-02-21 17:41:11 +01:00
Damien
807f3ce8a1
refactor(ipam): simplify interface references to compact array format
...
Replace verbose interface definitions using node/kind objects with
concise [device, interface] array notation across all IPAM address
entries. This reduces verbosity and improves readability of the
IP address assignments for loopbacks and P2P underlay links.
2026-02-21 16:13:31 +01:00
Damien
e9dad132ea
feat(ipam): add interface associations to IP addresses
...
Add interface node and kind to all IP address entries in the IPAM configuration file. This change enhances the IPAM configuration by explicitly associating each IP address with its corresponding interface, improving clarity and maintainability of the network configuration.
The changes include:
- Adding interface node and kind for all Router-ID Loopback0 addresses
- Adding interface node and kind for all VTEP Loopback1 addresses
- Adding interface node and kind for all spine and leaf P2P underlay addresses
- Maintaining consistent format across all IP address entries
2026-02-21 16:02:54 +01:00
9c8bc40046
chore: remove visual annotations from topology file
...
The `evpn-lab.clab.yml.annotations.json` file was updated to remove all existing `freeTextAnnotations` (AS numbers) and `freeShapeAnnotations` (grouping rectangles). This effectively cleans up the visual overlay for the topology.
2026-02-21 14:48:02 +00:00
Damien
e353ef0a90
Update MLAG schema to use IPHost instead of IPNetwork for local
...
interface IP
2026-02-21 11:48:13 +01:00
Damien
6dd4cc96ef
fix(InfraBGPSessionUpsert): changeing load order of objects
2026-02-21 10:02:17 +01:00
Damien
7cd0103d39
Update .gitignore
2026-02-20 18:42:27 +01:00
Damien
1b25c92965
build(infrahub): update file paths to match new directory structure
...
Refactor the .infrahub.yml configuration file to prefix all schema, menu, and object paths with the 'infrahub/' directory. This change aligns the configuration with the reorganized project structure where Infrahub resources have been moved into a dedicated subfolder.
2026-02-20 18:33:37 +01:00
Damien
b042e13b38
fea(infrahub): Add infrahub configuration
2026-02-20 16:12:07 +01:00
f0e7bd7135
chore(annotation): update AS comments position
2026-01-25 10:19:36 +00:00
3a9c7cd790
feat(configs): add static route for 100.64.0.0/10 subnet for Tailnet Access
...
Update configuration files for all leaf and spine switches to include a
new static route for the 100.64.0.0/10 prefix.
The route points to the next-hop gateway 172.16.0.254, ensuring proper
reachability for the Tailnet range across the network fabric.
2025-12-22 18:06:08 +00:00
913135d966
refactor(configs): migrate management interface to Management0
...
This commit updates the management interface configuration across all leaf and spine switches to align with the target environment requirements.
Changes include:
- Changing the primary management interface from `Management1` to `Management0`.
- Removing the `vrf mgmt` assignment, moving the interface to the default global routing table.
- Explicitly configuring `lldp management-address Management0` to ensure the correct management IP is advertised to neighbors.
2025-12-17 20:10:12 +00:00
c152e04473
chore(annotations): update line width
2025-12-16 21:17:26 +00:00
d9327ed95f
feat(configs): enable gNMI API on all network devices
...
Enables the gNMI (gRPC Network Management Interface) API across all leaf
and spine switches to allow for telemetry streaming and programmatic
device management.
Configuration details:
- Transport: grpc default
- Provider: eos-native
2025-12-16 12:00:20 +00:00
481f3d996d
Chore(annotations): Update AS information
2025-12-16 10:35:34 +00:00
bbcf2c9cb9
chore(configs): update admin password for spine switches
2025-12-14 19:26:39 +00:00
5c55732941
clab annotation
2025-12-14 19:04:37 +00:00
8ea0fdcf64
adapt line width
2025-12-14 19:02:33 +00:00
308781e6eb
Update readme
2025-12-04 10:12:06 +00:00
51f21f16c9
Add topology visualization and annotations
...
Add SVG topology diagram and containerlab annotations file with AS number labels and node positioning for the EVPN VXLAN lab environment.
🤖 Generated with [Claude Code](https://claude.com/claude-code )
Co-Authored-By: Claude <noreply@anthropic.com >
2025-12-04 10:11:03 +00:00
1a084d0c3f
Add detailed information to README
...
Expanded the README to provide more details about the configuration,
including:
- AS Numbers
- IP Addressing (Management, Loopback, Underlay P2P, Host)
- VXLAN Network Identifiers (VNI)
- Features Implemented
- Test Connectivity
2025-11-30 19:16:56 +00:00
db54e56b41
chore: Repository cleanup - Remove unnecessary files ( #16 )
...
## Summary
Repository cleanup to remove unnecessary files and streamline documentation after the successful EVPN-VXLAN lab implementation.
Closes #15
---
## Changes
### Files Removed (13 files total)
**Scripts folder:**
- `scripts/deploy.sh`
- `scripts/test-connectivity.sh`
- `scripts/cleanup.sh`
**Root-level markdown files:**
- `BRANCH_SUMMARY.md`
- `BUGFIX_EVPN_ACTIVATION.md`
- `DEPLOYMENT_GUIDE.md`
- `FIXES_APPLIED.md`
- `TESTING_CHECKLIST.md`
- `VLAN_TAGGING_FIX_EXPLANATION.md`
**docs/ folder (entire folder removed):**
- `docs/HOST_INTERFACE_CONFIGURATION.md`
- `docs/configuration-guide.md`
- `docs/quick-reference.md`
- `docs/validation-commands.md`
### Files Updated
- `hosts/README.md` - Fixed broken links
- `README.md` - Updated repository structure section
---
## Final Repository Structure
```
├── .gitignore
├── README.md # Main documentation
├── TROUBLESHOOTING.md # Troubleshooting guide
├── END_TO_END_TESTING.md # Testing procedures
├── evpn-lab.clab.yml # ContainerLab topology
├── configs/ # Switch configurations (10 files)
└── hosts/ # Host interface configs (5 files)
```
---
## Testing
- [x] Lab redeployed successfully with `containerlab deploy -t evpn-lab.clab.yml`
- [x] L2 VXLAN connectivity verified (host1 ↔ host3)
- [x] L3 VXLAN connectivity verified (host2 ↔ host4)
- [x] All BGP EVPN sessions established
- [x] MLAG pairs operational
Reviewed-on: #16
2025-11-30 19:07:22 +00:00
1080bf07bb
Complete Lab Fixes - L2 and L3 VXLAN Fully Operational ( #14 )
...
## Summary
This PR merges all fixes and improvements from the troubleshooting journey to make the Arista EVPN-VXLAN lab fully operational with both L2 and L3 VXLAN connectivity.
## What's Changed
### 🎯 Major Achievements
- ✅ **L2 VXLAN fully operational** - host1 ↔ host3 connectivity verified
- ✅ **L3 VXLAN fully operational** - host2 ↔ host4 connectivity verified (VRF gold)
- ✅ **LACP bonding working** - dual-homed hosts with proper Port-Channel negotiation
- ✅ **All BGP/EVPN sessions established** - complete underlay and overlay working
### 🔧 Infrastructure Fixes
#### BGP & Routing
- Added `ip routing` command to all spine and leaf switches
- Fixed duplicate BGP network statements on leaf3, leaf4, leaf7, leaf8
- Activated EVPN neighbors on spine switches
- Added loopback network advertisements to BGP
#### MLAG Configuration
- Configured MLAG peer-link in trunk mode (not access) for VLAN 4090/4091
- Added dual-active detection via management interface
- Configured virtual router MAC for MLAG pairs
#### Switch Port Configuration
- Port-Channel1 configured in **trunk mode** on all leaf switches
- Added `switchport trunk allowed vlan` for host VLANs (34, 40, 78)
- Removed `no shutdown` from Port-Channel interfaces
### 🖥️ Host Networking - Complete Redesign
#### Image Change
- **Old:** `alpine:latest` (had bonding syntax issues)
- **New:** `ghcr.io/hellt/network-multitool` (networking tools pre-installed)
#### LACP Bonding Configuration
Proper LACP setup following network-multitool best practices:
```yaml
- ip link add bond0 type bond mode 802.3ad
- ip link set dev bond0 type bond xmit_hash_policy layer3+4
- ip link set dev eth1 down
- ip link set dev eth2 down
- ip link set eth1 master bond0
- ip link set eth2 master bond0
- ip link set dev eth1 up
- ip link set dev eth2 up
- ip link set dev bond0 type bond lacp_rate fast
- ip link set dev bond0 up
```
#### VLAN Configuration
- **L2 VXLAN hosts (host1, host3):** VLAN 40 tagged on bond0
- **L3 VXLAN hosts (host2, host4):** VLANs 34 and 78 tagged on bond0
#### Routing Strategy
- Kept management default route (172.16.0.254 via eth0)
- Added **specific routes** for L3 VXLAN networks instead of default routes:
- host2: `ip route add 10.78.78.0/24 via 10.34.34.1`
- host4: `ip route add 10.34.34.0/24 via 10.78.78.1`
### 📁 Files Changed
#### Switch Configurations (Updated)
- `configs/spine1.cfg` - Added ip routing, EVPN activation
- `configs/spine2.cfg` - Added ip routing, EVPN activation
- `configs/leaf1.cfg` - Port-Channel trunk mode, VLAN config
- `configs/leaf2.cfg` - Port-Channel trunk mode, VLAN config
- `configs/leaf3.cfg` - Added ip routing, loopback ads, Port-Channel config
- `configs/leaf4.cfg` - Added ip routing, loopback ads, Port-Channel config
- `configs/leaf5.cfg` - Port-Channel trunk mode, VLAN config
- `configs/leaf6.cfg` - Port-Channel trunk mode, VLAN config
- `configs/leaf7.cfg` - Added ip routing, loopback ads, Port-Channel config
- `configs/leaf8.cfg` - Added ip routing, loopback ads, Port-Channel config
#### Topology (Updated)
- `evpn-lab.clab.yml` - Updated all host configurations with network-multitool image and proper LACP/VLAN setup
#### Documentation (New)
- `hosts/README.md` - Host interface configuration guide
- `hosts/host1_interfaces` - Interface file for host1 (not currently used, kept for reference)
- `hosts/host2_interfaces` - Interface file for host2 (not currently used, kept for reference)
- `hosts/host3_interfaces` - Interface file for host3 (not currently used, kept for reference)
- `hosts/host4_interfaces` - Interface file for host4 (not currently used, kept for reference)
## Testing & Verification
### ✅ L2 VXLAN (VLAN 40)
```
host1 (10.40.40.101) → host3 (10.40.40.103)
- Connectivity: VERIFIED ✓
- VXLAN tunnel: VTEP1 ↔ VTEP3
- MAC learning: Working via EVPN Type-2
```
### ✅ L3 VXLAN (VRF gold)
```
host2 (10.34.34.102) → host4 (10.78.78.104)
- Connectivity: VERIFIED ✓
- Ping results: 0% packet loss, TTL=62
- Routing: Via EVPN Type-5 through fabric
```
### ✅ Infrastructure Status
- BGP Underlay: All sessions ESTAB
- EVPN Overlay: All neighbors ESTAB
- MLAG: All 4 pairs operational
- Port-Channels: LACP negotiated on all hosts
## Related Issues
Fixes #1 - Lab deployment and configuration fixes
Fixes #2 - BGP EVPN neighbors stuck in Connect state
Fixes #3 - Ready for deployment with EVPN activation
Fixes #4 - Lab convergence in progress
Fixes #5 - BGP EVPN neighbors stuck in Active state
Fixes #11 - Host LACP bonding configuration
Fixes #13 - L3 VXLAN default route issue
## Key Technical Learnings
1. **Arista EOS requires explicit `ip routing`** before BGP can function
2. **MLAG peer-link must be trunk mode** to allow VLAN 4090/4091 traversal
3. **VLAN tagging location matters** - hosts tag, switches use trunk mode
4. **network-multitool image** superior to Alpine for LACP bonding
5. **Specific routes better than default routes** when management network present
6. **LACP rate fast** ensures quick negotiation with Arista switches
## Deployment
After merging, deploy with:
```bash
cd ~/arista-evpn-vxlan-clab
sudo containerlab destroy -t evpn-lab.clab.yml --cleanup
sudo containerlab deploy -t evpn-lab.clab.yml
```
No manual post-deployment configuration needed - everything works from initial deployment!
## Breaking Changes
⚠️ **Host image changed** from `alpine:latest` to `ghcr.io/hellt/network-multitool`
⚠️ **Host configuration completely redesigned** - old exec commands replaced
## Reviewers
@Damien - Please review and merge when ready
---
**This PR represents the complete troubleshooting journey and brings the lab to production-ready status with full L2 and L3 VXLAN functionality.** 🚀
Reviewed-on: #14
Co-authored-by: Damien <damien@arnodo.fr >
Co-committed-by: Damien <damien@arnodo.fr >
2025-11-30 10:24:29 +00:00
9502302b76
Revert topology to original version before accidental commits
2025-11-30 08:55:08 +00:00
d6acdfbe75
Revert accidental commit to main - remove HOST_CONFIGURATION.md
2025-11-30 08:53:58 +00:00
e6210267a6
Revert accidental commit to main - remove host4-interfaces
2025-11-30 08:53:44 +00:00
67816b84a1
Revert accidental commit to main - remove host3-interfaces
2025-11-30 08:53:32 +00:00
aef0890f34
Revert accidental commit to main - remove host2-interfaces
2025-11-30 08:53:21 +00:00
0baec91037
Revert accidental commit to main - remove host interface files
2025-11-30 08:53:11 +00:00
7c08125826
Add comprehensive host interface configuration documentation
2025-11-30 08:21:24 +00:00
e04a531a86
Update topology to use persistent interface files via binds instead of exec commands
2025-11-30 08:20:58 +00:00
926ab47337
Add host4 interface configuration for LACP bonding with VLAN 78
2025-11-30 08:20:31 +00:00
ce76b0c342
Add host3 interface configuration for LACP bonding with VLAN 40
2025-11-30 08:20:26 +00:00
31e1e345cd
Add host2 interface configuration for LACP bonding with VLAN 34
2025-11-30 08:20:21 +00:00
050a529c68
Add host1 interface configuration for LACP bonding with VLAN 40
2025-11-30 08:20:16 +00:00
4fc902ee13
Add DEPLOYMENT_GUIDE.md with step-by-step instructions
...
Provide clear deployment instructions, verification checklist, and
troubleshooting guidance for the EVPN-VXLAN lab with applied fixes.
2025-11-28 09:28:13 +00:00
783e12cea6
Add FIXES_APPLIED.md to main branch
...
Document all critical fixes discovered during lab testing:
- Spine routing: ip routing command added
- MLAG: static LAG mode enabled
- Pending: port-channel access mode, host networking
Track status of each fix for deployment readiness.
2025-11-28 09:27:56 +00:00
