Skip to content
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

Wrong as number when using autort #17945

Open
2 tasks done
dshleg opened this issue Jan 28, 2025 · 0 comments
Open
2 tasks done

Wrong as number when using autort #17945

dshleg opened this issue Jan 28, 2025 · 0 comments
Labels
triage Needs further investigation

Comments

@dshleg
Copy link

dshleg commented Jan 28, 2025

Description

Dear friends, i trying to integrate server with FRR to my EVPN-VXLAN network based on Juniper QFX Hardware
Server OS: Debian Bookworm with Proxmox 8.3 ( latest )
Juniper using rfc8365 for generate route target:
https://datatracker.ietf.org/doc/html/rfc8365

test vni numbers: 22022, 22025

my FRR config(version 8.5.2-pve):
autort works correctly and other hosts pings my server with FRR, but Proxmox contains other issues, after some time i want create other report.

router bgp 4200004045
 bgp router-id 10.77.8.45
 bgp log-neighbor-changes
 no bgp ebgp-requires-policy
 no bgp default ipv4-unicast
 bgp bestpath as-path multipath-relax
 no bgp network import-check
 timers bgp 30 90
 neighbor OVERLAY peer-group
 neighbor OVERLAY remote-as 64542
 neighbor OVERLAY local-as 64542
 neighbor OVERLAY ttl-security hops 3
 neighbor OVERLAY update-source dum0
 neighbor OVERLAY capability dynamic
 neighbor UNDERLAY peer-group
 neighbor UNDERLAY capability dynamic
 neighbor 10.77.5.1 peer-group OVERLAY
 neighbor 10.77.5.1 description RR-SPINE-1
 neighbor 10.77.5.2 peer-group OVERLAY
 neighbor 10.77.5.2 description RR-SPINE-2
 neighbor 10.77.9.1 remote-as external
 neighbor 10.77.9.1 peer-group UNDERLAY
 neighbor 10.77.9.6 remote-as external
 neighbor 10.77.9.6 peer-group UNDERLAY
 !
 address-family ipv4 unicast
  redistribute connected
  neighbor UNDERLAY activate
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor OVERLAY activate
  advertise-all-vni
  autort as 64542 (ONLY PVE VERSION CONTAINS THIS OPTION)
  autort rfc8365-compatible
 exit-address-family
exit

for fix FRR issue (Proxmox version) i try to upgrade to other FRR version: 8.5.7, 9.0, 9.1, 10.1
This versions generates partially correct route target, for example:
target:63949:268457478 - for VNI 22022 = 63949 WRONG AS NUMBER, 268457478 - correct target(based on rfc8365)

Result of test versions:

  1. any version from FRR repository, this fixes my issue with Proxmox version, but broke autort functionality: for each vni number i need manually set route target.
  2. any version from FRR repository not contains: autort as option
    Working config for FRR versions from original repository(EVPN family):
address-family l2vpn evpn
  neighbor OVERLAY activate
  advertise-all-vni
  autort rfc8365-compatible(THIS OPTION GENERATES CORRECT route target, but inserts WRONG as number)
   vni 22022
   route-target import 64542:268457478(manually generated)
   route-target export 64542:268457478(manually generated)
  exit-vni
    vni 22025
   route-target import 64542:268457481(manually generated)
   route-target export 64542:268457481(manually generated)
  exit-vni
 exit-address-family

My Topology:

Image

My questions:

  1. This bug or a feature? When is bug, maybe possible to fix
  2. Maybe my configurations is wrong? Misconfigured?
  3. Maybe possible to porting path for add option : autort as from FRR(Proxmox version) to new versions of FRR
    Link to patch: https://git.proxmox.com/?p=frr.git;a=commit;h=ee6c216aee076d61619d5992446d3d17d3035883

Version

Tested versions: 8.5.7, 9.0, 10.1

How to reproduce

Use example of config

Expected behavior

autort generates route target with correct as number configured for OVERLAY group

Actual behavior

as number for OVERLAY group not useed by FRR and inserts wrong BGP AS number

Additional context

No response

Checklist

  • I have searched the open issues for this bug.
  • I have not included sensitive information in this report.
@dshleg dshleg added the triage Needs further investigation label Jan 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Needs further investigation
Projects
None yet
Development

No branches or pull requests

1 participant