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

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: - [ ] 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.
Damien commented 2025-11-30 10:02:42 +00:00
Author
Owner
Copy Link

✅ 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
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Damien
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Damien/arista-evpn-vxlan-clab#13
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?