Damien/arista-evpn-vxlan-clab
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

L3 VXLAN - Cannot add default route on host2/host4 (VRF gold) #13

New Issue
Closed
opened 2025-11-30 09:52:06 +00:00 by Damien · 1 comment
Damien commented 2025-11-30 09:52:06 +00:00
Owner
Copy Link
Copy Source

Problem

L3 VXLAN hosts (host2 and host4 in VRF gold) cannot add default route via their VRF gateway during lab deployment.

Error Message

RTNETLINK answers: File exists

When executing: ip route add default via 10.34.34.1 (host2) or ip route add default via 10.78.78.1 (host4)

Current State

Host2 (VLAN 34 in VRF gold)

Working:

  • ✅ Bond0 interface up with LACP
  • ✅ VLAN 34 interface configured (10.34.34.102/24)
  • ✅ Can ping gateway 10.34.34.1

Not Working:

  • ❌ Cannot add default route via 10.34.34.1

Current routing table:

default via 172.16.0.254 dev eth0          # Management network default route
10.34.34.0/24 dev bond0.34 proto kernel scope link src 10.34.34.102
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.102

Host4 (VLAN 78 in VRF gold)

Same issue - cannot add default route via 10.78.78.1

Root Cause

ContainerLab automatically adds a default route via the management network (172.16.0.254 dev eth0). When exec commands try to add another default route, the kernel rejects it with "File exists" error.

Possible Solutions

Option 1: Delete existing default route first

exec:
    - ip route del default via 172.16.0.254 dev eth0
    - ip route add default via 10.34.34.1

Option 2: Use ip route replace

exec:
    - ip route replace default via 10.34.34.1

Option 3: Add route with higher metric

exec:
    - ip route add default via 10.34.34.1 metric 100

This keeps the mgmt route but prefers the VRF gateway.

Option 4: Don't add default route

Simply rely on connected routes - host2 and host4 can reach each other via EVPN without a default route.

Testing Required

Once route issue is resolved, verify:

  • host2 can ping host4 (10.78.78.104)
  • host4 can ping host2 (10.34.34.102)
  • L3 VXLAN routes learned via EVPN Type-5
  • VRF gold routing working end-to-end

Branch

Topology is on debug branch for troubleshooting.

## Problem L3 VXLAN hosts (host2 and host4 in VRF gold) cannot add default route via their VRF gateway during lab deployment. ## Error Message ``` RTNETLINK answers: File exists ``` When executing: `ip route add default via 10.34.34.1` (host2) or `ip route add default via 10.78.78.1` (host4) ## Current State ### Host2 (VLAN 34 in VRF gold) **Working:** - ✅ Bond0 interface up with LACP - ✅ VLAN 34 interface configured (10.34.34.102/24) - ✅ Can ping gateway 10.34.34.1 **Not Working:** - ❌ Cannot add default route via 10.34.34.1 **Current routing table:** ``` default via 172.16.0.254 dev eth0 # Management network default route 10.34.34.0/24 dev bond0.34 proto kernel scope link src 10.34.34.102 172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.102 ``` ### Host4 (VLAN 78 in VRF gold) Same issue - cannot add default route via 10.78.78.1 ## Root Cause ContainerLab automatically adds a default route via the management network (172.16.0.254 dev eth0). When exec commands try to add another default route, the kernel rejects it with "File exists" error. ## Possible Solutions ### Option 1: Delete existing default route first ```yaml exec: - ip route del default via 172.16.0.254 dev eth0 - ip route add default via 10.34.34.1 ``` ### Option 2: Use ip route replace ```yaml exec: - ip route replace default via 10.34.34.1 ``` ### Option 3: Add route with higher metric ```yaml exec: - ip route add default via 10.34.34.1 metric 100 ``` This keeps the mgmt route but prefers the VRF gateway. ### Option 4: Don't add default route Simply rely on connected routes - host2 and host4 can reach each other via EVPN without a default route. ## Testing Required Once route issue is resolved, verify: - [x] host2 can ping host4 (10.78.78.104) - [x] host4 can ping host2 (10.34.34.102) - [x] L3 VXLAN routes learned via EVPN Type-5 - [x] VRF gold routing working end-to-end ## Branch Topology is on **debug** branch for troubleshooting.
Damien commented 2025-11-30 10:02:42 +00:00
Author
Owner
Copy Link
Copy Source

✅ RESOLVED - L3 VXLAN Working with Specific Routes

Solution

Instead of adding a default route (which conflicts with ContainerLab management), added specific routes to remote L3 VXLAN networks.

Configuration Applied

Host2 exec commands:

- ip route add 10.78.78.0/24 via 10.34.34.1

Host4 exec commands:

- ip route add 10.34.34.0/24 via 10.78.78.1

Verification - host2 Routing Table

Destination     Gateway         Genmask         Flags   Iface
default         172.16.0.254    0.0.0.0         UG      eth0        # Management
10.34.34.0      0.0.0.0         255.255.255.0   U       bond0.34    # Local
10.78.78.0      10.34.34.1      255.255.255.0   UG      bond0.34    # Remote via VRF gateway
172.16.0.0      0.0.0.0         255.255.255.0   U       eth0        # Management

✅ Connectivity Test Results

host2 → host4 (10.78.78.104):
- 2 packets transmitted, 2 received
- 0% packet loss
- RTT min/avg/max: 4.083/7.247/10.411 ms
- TTL=62 (indicates routing through fabric)

Why This Works

  1. Management network preserved: Default route via eth0 for ContainerLab
  2. Local connectivity: Direct connection to local subnet via bond0.XX
  3. Remote L3 VXLAN: Specific route points to VRF gateway
  4. EVPN handles the rest: Fabric routes between VRF gold networks

Benefits

  • ✅ No route conflicts
  • ✅ Management access maintained
  • ✅ L3 VXLAN routing working
  • ✅ Clean separation of concerns

Issue resolved - L3 VXLAN fully operational!

## ✅ RESOLVED - L3 VXLAN Working with Specific Routes ### Solution Instead of adding a default route (which conflicts with ContainerLab management), added **specific routes** to remote L3 VXLAN networks. ### Configuration Applied **Host2 exec commands:** ```yaml - ip route add 10.78.78.0/24 via 10.34.34.1 ``` **Host4 exec commands:** ```yaml - ip route add 10.34.34.0/24 via 10.78.78.1 ``` ### Verification - host2 Routing Table ``` Destination Gateway Genmask Flags Iface default 172.16.0.254 0.0.0.0 UG eth0 # Management 10.34.34.0 0.0.0.0 255.255.255.0 U bond0.34 # Local 10.78.78.0 10.34.34.1 255.255.255.0 UG bond0.34 # Remote via VRF gateway 172.16.0.0 0.0.0.0 255.255.255.0 U eth0 # Management ``` ### ✅ Connectivity Test Results ``` host2 → host4 (10.78.78.104): - 2 packets transmitted, 2 received - 0% packet loss - RTT min/avg/max: 4.083/7.247/10.411 ms - TTL=62 (indicates routing through fabric) ``` ### Why This Works 1. **Management network preserved**: Default route via eth0 for ContainerLab 2. **Local connectivity**: Direct connection to local subnet via bond0.XX 3. **Remote L3 VXLAN**: Specific route points to VRF gateway 4. **EVPN handles the rest**: Fabric routes between VRF gold networks ### Benefits - ✅ No route conflicts - ✅ Management access maintained - ✅ L3 VXLAN routing working - ✅ Clean separation of concerns **Issue resolved - L3 VXLAN fully operational!**
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
containerlab
Containerlab topology et configs
 epic
Epic / Phase de projet
 generator
Infrahub Generator Python code
 resource-manager
Resource Manager / IPAM pools
 schema
Modifications de schéma Infrahub
 telemetry
monitoring configuration with prometheus and grafana
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
Damien (Damien Arnodo)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Damien/arista-evpn-vxlan-clab#13