Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@chiragshah6
Copy link
Member

@chiragshah6 chiragshah6 commented Oct 9, 2025

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

  • IPv6 support for BGP system-IP which is used for Type-5 routes
  • Remote MAC add,delete to restore behavior for IPv4 underlay where ipv4 mapped ipv6 vtep address is preserved.
  • show commands across BGP and Zebra to support IPv4 and IPv6 VTEP
  • code consolidation and debug, tracepoints

Signed-off-by: Chirag Shah [email protected]
Signed-off-by: Manpreet Kaur [email protected]

Copy link
Contributor

@mjstapp mjstapp left a 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.

@chiragshah6
Copy link
Member Author

chiragshah6 commented Oct 10, 2025

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.
Alternative, this PR would help listed show commands and type-5 route processing functionality working which base PR would have missing. One would run into the partially broken state.

@chiragshah6 chiragshah6 force-pushed the evpnv6_1 branch 2 times, most recently from b4e45b7 to a06deb9 Compare October 10, 2025 17:58
@github-actions
Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@chiragshah6 chiragshah6 changed the title *:EVPN over IPv6 overlay fabric - single homed *:EVPN over IPv6 underlay fabric - single homed Oct 13, 2025
@chiragshah6 chiragshah6 requested a review from mjstapp October 13, 2025 17:14
Copy link
Contributor

@mjstapp mjstapp left a 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?

@chiragshah6
Copy link
Member Author

chiragshah6 commented Oct 13, 2025

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.
https://github.com/FRRouting/frr/runs/52287524083

@chiragshah6 chiragshah6 requested a review from mjstapp October 13, 2025 18:19
@riw777 riw777 self-requested a review October 14, 2025 15:13
@mjstapp
Copy link
Contributor

mjstapp commented Oct 14, 2025

that's ... not how we do it, though? we commonly don't take random whitespace changes?

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. https://github.com/FRRouting/frr/runs/52287524083

@chiragshah6
Copy link
Member Author

chiragshah6 commented Oct 15, 2025

that's ... not how we do it, though? we commonly don't take random whitespace changes?

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. https://github.com/FRRouting/frr/runs/52287524083

I don't understand. These are not random whitespace changes, these are clang format/style checker reported ones in PR-19498
These were not addressed in base PR https://github.com/FRRouting/frr/runs/52287524083 and being addressed when this PR changes worked on top of the base PR. The base PR merged couple of days back. How are these random spaces?
I don't see why they are not acceptable, they are aligning to coding style checkers accepted by FRR community.

chiragshah6 and others added 23 commits October 17, 2025 23:16
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]>
post v4/v6 vtep change, check for input vtep pointer
validitiy before accessing it.

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]>
EVPN Mcast does not support IPv6 mcast address

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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants