- 
                Notifications
    You must be signed in to change notification settings 
- Fork 1.4k
*:EVPN over IPv6 underlay fabric - single homed #19721
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
6a041d3    to
    9552af6      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this doesn't make sense to me: our PR has been available for months, plenty of time to offer/accept meaningful review comments. it's unreasonable to ask my team to re-review all this work, to separate out the changes you want to propose.
I think you should merge the existing PR, and then submit your own PR with your own proposed changes - that would make the changes much easier to review and discuss.
| 
 @mjstapp Please revisit the title—it clearly outlines the scope of your PR and appropriately credits both the original author and yourself. The base PR commits have been retained here so this PR can be raised once the dependency is met. The original commits remain untouched from your previous submission, and this new PR introduces additional functionality on top of that. The original PR was still open, but since the author is unavailable and you've taken ownership, I’ve provided review comments on that version. Those specific parts of the code have not been modified in this PR. Feel free to proceed with merging the original PR first, once you’ve received acknowledgments from all reviewers. We can then move forward with this PR afterward. | 
b4e45b7    to
    a06deb9      
    Compare
  
    | This pull request has conflicts, please resolve those before we can evaluate the pull request. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A lot of diffs here seem just to be white-space - is there a reason for that? could you remove those - that wouldn't change any behavior, right?
| 
 Those are from clang-format/stye-check runs reported  from the original PR, I think its better to have them addressed for better code consistency. | 
| that's ... not how we do it, though? we commonly don't take random whitespace changes? 
 | 
| 
 I don't understand. These are not random whitespace changes, these are clang format/style checker reported ones in PR-19498 | 
Signed-off-by: Chirag Shah <[email protected]>
Signed-off-by: Chirag Shah <[email protected]>
CLI changes to support and display IPv6 VTEP Ticket: #4619095 ``` tor-22# show interface vxlan99 Interface vxlan99 is up, line protocol is up <snip> VTEP IP: 2006:20:20::31 VxLAN Id 104001 Access VLAN Id 4001 <snip> tor-22# show evpn mac vni all <snip> MAC Type Flags Intf/Remote ES/VTEP VLAN Seq #'s 00:02:00:00:00:20 remote 2006:20:20::30 0/0 00:02:00:00:00:24 local swp4 112 0/0 <snip> tor-22# show evpn l2-nh VTEP NH id #ES 6.0.0.16 268435468 2 tor-22# show evpn next-hops vni all <snip> IP RMAC 2006:20:20::2 00:00:10:00:02:08 tor-22# show evpn rmac vni all <snip> RMAC Remote VTEP 00:00:10:00:02:08 2006:20:20::2 tor-22# show evpn rmac vni 104001 Number of Remote RMACs known for this VNI: 1 MAC Remote VTEP 00:00:10:00:02:08 2006:20:20::2 tor-22# show evpn next-hops vni 104002 Number of NH Neighbors known for this VNI: 2 IP RMAC 2006:20:20::2 00:00:10:00:02:08 tor-22# show evpn mac vni all duplicate <snip> Flags: N=sync-neighs, I=local-inactive, P=peer-active, X=peer-proxy MAC Type Flags Intf/Remote ES/VTEP VLAN Seq #'s ``` Signed-off-by: Manpreet Kaur <[email protected]>
CLI changes to support and display IPv6 VTEP
Testing:
```
tor-22# show bgp l2vpn evpn next-hops
VRF             IP                                      RMAC              #Paths     Base Path
VRF vrf2        2006:20:20::30                          00:01:00:00:1e:07 2          60.1.1.211/32
tor-22# show bgp l2vpn evpn all tags
   Network          Next Hop      In tag/Out tag
Route Distinguisher: 6.0.0.2:4
 *>  [2]:[0]:[48]:[00:02:00:00:00:1d]
                    2006:20:20::2
 *=                   2006:20:20::2
```
Ticket: #4614829
Signed-off-by: Manpreet Kaur <[email protected]>
    Aligned "show bgp l2vpn evpn all tags" output to prevent
IPv6 vtep address to hit notag string boundary
Before fix:
```
*> [5]:[0]:[64]:[2081:1:1:3::]
                    2006:20:20::1notag/6500
```
After fix:
```
*> [5]:[0]:[64]:[2081:1:1:3::]
                    2006:20:20::1 notag/6500
```
Ticket: #4614829
Signed-off-by: Manpreet Kaur <[email protected]>
    Testing:
```
2025-09-18T11:09:40.964 frr_bgp:evpn_local_vni_add_zrecv {'vni': 104001, 'vtep': '2006:20:20::2', 'mc_grp': '0.0.}
2025-09-18T11:09:40.965 frr_bgp:evpn_local_l3vni_add_zrecv {'vni': 104001, 'vrf': 12, 'svi_rmac': '00:01:00:00:00,
    'vrr_rmac': '00:01:00:00:02:08', 'vtep': '2006:20:20::2', 'filter': 0, 'svi_ifindex': 21, 'anycast_mac': 'no'}
```
Signed-off-by: Manpreet Kaur <[email protected]>
    EVPN route type5 uses system IP and system MAC as nexthop and RMAC. Ensure advdertise pip system IP is IPv6 VTEP address aware. In case of IPv6 underlay fabric fetch loopback's primary GUA IPv6 address as advertise PIP IP. EVPN route type-5 advertisement uses pip IP as nexthop, use default instance's loopback GUA IPv6 address as VTEP address. Signed-off-by: Chirag Shah <[email protected]>
Before: tor-21# show bgp l2vpn evpn route rd 144.1.1.2:6 EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id] EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] BGP routing table entry for 144.1.1.2:6:[5]:[0]:[24]:[50.1.110.0] Paths: (2 available, best FRRouting#1) Advertised to peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[24]:[50.1.110.0] VNI 104001 651004 652000 651001 660000 0.0.0.0(leaf-21) from leaf-21(swp1) (6.0.0.26) Origin incomplete, valid, external, multipath, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104001 ET:8 Rmac:00:00:10:00:01:08 Last update: Mon Sep 29 04:06:01 2025 Route [5]:[0]:[24]:[50.1.110.0] VNI 104001 651004 652000 651001 660000 0.0.0.0(leaf-22) from leaf-22(swp2) (6.0.0.27) Origin incomplete, valid, external, multipath Extended Community: RT:4640:104001 ET:8 Rmac:00:00:10:00:01:08 Last update: Mon Sep 29 04:06:01 2025 After: tor-21# show bgp l2vpn evpn route rd 144.1.1.2:6 EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id] EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] BGP routing table entry for 144.1.1.2:6:[5]:[0]:[24]:[50.1.110.0] Paths: (2 available, best FRRouting#1) Advertised to peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[24]:[50.1.110.0] VNI 104001 651004 652000 651001 660000 2006:27:27::1(leaf-21) from leaf-21(swp1) (6.0.0.26) Origin incomplete, valid, external, multipath, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104001 ET:8 Rmac:00:00:10:00:01:08 Last update: Mon Sep 29 00:36:28 2025 Route [5]:[0]:[24]:[50.1.110.0] VNI 104001 651004 652000 651001 660000 2006:27:27::1(leaf-22) from leaf-22(swp2) (6.0.0.27) Origin incomplete, valid, external, multipath Extended Community: RT:4640:104001 ET:8 Rmac:00:00:10:00:01:08 Last update: Mon Sep 29 00:36:28 2025 Signed-off-by: Chirag Shah <[email protected]>
with recent change to unification v4/v6 vtep_ip
The commands like  show bgp vni 1000111 vtep
leads to crash as vtep ip null needs to be handled.
(gdb) bt
    at ../lib/sigevent.c:268
    type=type@entry=0, mac_table=mac_table@entry=false, _vtep_ip=_vtep_ip@entry=0x0, json=<optimized out>)
    at ../bgpd/bgp_evpn_vty.c:2767
    vni_str=<optimized out>, addr_str=<optimized out>, uj=0x0, addr=0x0, vni=1000111, vty=0x55e631b5a500)
    at ../bgpd/bgp_evpn_vty.c:5779
    at ./bgpd/bgp_evpn_vty_clippy.c:1379
    cmd=cmd@entry=0x0, up_level=up_level@entry=0) at ../lib/command.c:1011
    cmd=cmd@entry=0x0, vtysh=vtysh@entry=0) at ../lib/command.c:1069
    cmd=cmd@entry=0x55e631b64d70 "show bgp vni 1000111 ", matched=matched@entry=0x0, vtysh=vtysh@entry=0)
    at ../lib/command.c:1236
    at ../lib/vty.c:617
(gdb) frame 4
    type=type@entry=0, mac_table=mac_table@entry=false, _vtep_ip=_vtep_ip@entry=0x0, json=<optimized out>)
    at ../bgpd/bgp_evpn_vty.c:2767
2767    in ../bgpd/bgp_evpn_vty.c
(gdb) p _vtep_ip
$3 = (const union sockunion *) 0x0
Signed-off-by: Chirag Shah <[email protected]>
    Modifying frr_babeltrace.py for bgp l2vpn and l3vni trace parses to parse v4/v6 vtep Ticket: #4619093 Signed-off-by: Manpreet Kaur <[email protected]>
EVPN path can have IPv6 nexthop, check the path attr nexthop len is ipv6 then copy ipv6 nexhtop address synced to zebra. Signed-off-by: Chirag Shah <[email protected]>
Based on L3VNI's local VTEP_IP as IPv6 or IPv4 address, store remote VTEP IP as IPv6 or IPv4 (or IPv4 mapped IPv6). For IPv6 routes over IPv4 underlay fabric, continue to maintain IPv4 mapped IPv6 nexthop address (commit f883c71) Signed-off-by: Chirag Shah <[email protected]>
Testing: 2025/09/29 00:12:11.076910 ZEBRA: [S5EGC-5PPV9] zl3vni_remote_rmac_add RMAC 00:00:10:00:01:08 L3VNI 104001 Remote VTEP 2006:20:20::1 add Signed-off-by: Chirag Shah <[email protected]>
2025/10/01 21:50:09.365379 BGP: [Z67YA-MZTRR] VRF vrf1 vni 104001 pip enable IP 2006:20:20::1 RMAC 00:00:10:00:01:08 sys RMAC 00:00:10:00:01:08 static RMAC 00:00:00:00:00:00 is_anycast_mac Disable Signed-off-by: Chirag Shah <[email protected]>
Signed-off-by: Chirag Shah <[email protected]>
post v4/v6 vtep change, check for input vtep pointer validitiy before accessing it. Signed-off-by: Chirag Shah <[email protected]>
Signed-off-by: Chirag Shah <[email protected]>
GUA IPv6 address max length can be 40 characters, hence defining new for #define to use where possible as column width etc. Signed-off-by: Chirag Shah <[email protected]>
Signed-off-by: Chirag Shah <[email protected]>
EVPN Mcast does not support IPv6 mcast address Signed-off-by: Chirag Shah <[email protected]>
Signed-off-by: Chirag Shah <[email protected]>
Signed-off-by: Chirag Shah <[email protected]>
field_val = [32, 1, 13, 184, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] ipv6_bytes = bytes(field_val) # b' \x01\r\xb8\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01' addr = ipaddress.IPv6Address(ipv6_bytes) print(str(addr)) # Output: "2001:db8::1" Cursor Signed-off-by: Chirag Shah <[email protected]>
memset prior to copyig data to dst Cursor Signed-off-by: Chirag Shah <[email protected]>
vni creation (evpn_create_update_vni) has local variable orignator_ip without initialisation. It only calls macro to set ipa_type SET_IPADDR_V4(&orignator_ip); When bgp->router_id is assigned to originator_ip only 4 bytes are used, 12 bytes unintialised vpn->originator_ip = *originator_ip; ← Copies uninitialized padding build_evpn_type3_prefix(&p, &vpn->originator_ip); uses this value update_evpn_route -> bgp_evpn_vni_ip_node_get -> route_node_get ==123062== Use of uninitialised value of size 8 ==123062== at 0x49B1A72: rn_hash_node_add (table.c:28) ==123062== by 0x49B1E94: route_node_set (table.c:66) ==123062== by 0x49B25A2: route_node_get (table.c:279) ==123062== by 0x216113: bgp_node_get (bgp_table.h:246) ==123062== by 0x2189D0: bgp_evpn_vni_ip_node_get (bgp_evpn.c:822) ==123062== by 0x218C1E: bgp_evpn_vni_node_get (bgp_evpn.c:925) ==123062== by 0x21C07F: update_evpn_route (bgp_evpn.c:2371) ==123062== by 0x226A2E: bgp_evpn_local_vni_add (bgp_evpn.c:7478) ==123062== by 0x345037: bgp_zebra_process_local_vni (bgp_zebra.c:3351) ==123062== by 0x49E296A: zclient_read (zclient.c:4868) ==123062== by 0x49BBAC2: event_call (event.c:2009) ==123062== by 0x4933973: frr_run (libfrr.c:1252) ==123062== by 0x1F1493: main (bgp_main.c:548) ==123062== Uninitialised value was created by a stack allocation ==123062== at 0x23C735: evpn_create_update_vni (bgp_evpn_vty.c:2374) Cursor Signed-off-by: Chirag Shah <[email protected]>
The PR-19498 covered to run EVPN over IPv6 underlay fabric, this PR enhances the functionality and covers missing functionality like EVPN type-5 route processing with PIP address, in IPv4 underlay fabric (without PR-19498 the ipv6 underlay fabric) restore back the way rmac add delete processing was present, some more existing evpn operational commands to have evpn v6 nexthop support.
This PR covers
Signed-off-by: Chirag Shah [email protected]
Signed-off-by: Manpreet Kaur [email protected]