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

Connected routes are invalid when using BGP VPN import with network statement #17610

Open
2 tasks done
packet-time opened this issue Dec 9, 2024 · 2 comments
Open
2 tasks done
Labels
triage Needs further investigation

Comments

@packet-time
Copy link

Description

When importing/exporting routes from one VRF to another, if the route is directly connected, advertising it into BGP with a network statement causes the route to be installed to the VPN table as invalid. If redistribute connected is used instead, then the route is valid.

Version

FRRouting 10.2_git (pe) on Linux(6.1.0-28-arm64).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' '--sbindir=/usr/lib/frr' '--libdir=/usr/lib' '--enable-rpki' '--enable-vtysh' '--enable-multipath=64' '--enable-vty-group=frrvty' '--enable-user=frr' '--enable-group=frr' '--enable-pcre2posix' '--enable-scripting' 'CC=gcc' 'CXX=g++'

How to reproduce

See below config:

frr version 10.2_git
frr defaults datacenter
hostname pe
no ipv6 forwarding
!
vrf blue
exit-vrf
!
interface lo
 ip address 10.0.0.1/32
exit
!
interface dummy0
 ip address 10.0.0.2/32
exit
!
router bgp 64512
 bgp router-id 10.0.0.1
 !
 address-family ipv4 unicast
  network 10.0.0.1/32
  rd vpn export 64512:1
  rt vpn export 64512:1
  rt vpn import 64512:2
  import vpn
  export vpn
 exit-address-family
exit
!
router bgp 64512 vrf blue
 bgp router-id 10.0.0.1
 !
 address-family ipv4 unicast
  network 10.0.0.2/32
  rd vpn export 64512:2
  rt vpn import 64512:1
  rt vpn export 64512:2
  import vpn
  export vpn
 exit-address-family
exit
!
  1. Configure two interfaces, one in default VRF and one in VRF blue.
  2. Assign addresses to both interfaces.
  3. Distribute both /32 prefixes into respective VRFs using the network syntax.
  4. Configure default VRF to export routes to VRF blue, and vice-versa.

Expected behavior

I expect that both /32 prefixes are imported and reachable from each VRF.

10.0.0.1 should be imported to and reachable from VRF blue.
10.0.0.2 should be imported to and reachable from VRF default.

Actual behavior

Both prefixes make it to the RIB, but fail to be installed to the FIB.

pe# sh ip bgp vrf all

Instance default:
BGP table version is 1, local router ID is 10.0.0.1, vrf id 0
Default local pref 100, local AS 64512
Status codes:  s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.0.0.1/32      0.0.0.0(pe)              0         32768 i
     10.0.0.2/32      0.0.0.0(pe)@2<           0         32768 i

Displayed 2 routes and 2 total paths

Instance blue:
BGP table version is 2, local router ID is 10.0.0.1, vrf id 2
Default local pref 100, local AS 64512
Status codes:  s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.0.0.1/32      0.0.0.0(pe)@0<           0         32768 i
 *>  10.0.0.2/32      0.0.0.0(pe)              0         32768 i

Displayed 2 routes and 2 total paths
pe#

Routes are not installed:

pe# sh ip route vrf all
Codes: K - kernel route, C - connected, L - local, S - static,
       R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
       f - OpenFabric, t - Table-Direct,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

VRF blue:
B   10.0.0.1/32 [20/0] is directly connected, unknown (vrf default) inactive, weight 1, 00:14:44
L * 10.0.0.2/32 is directly connected, dummy0, weight 1, 00:14:45
C>* 10.0.0.2/32 is directly connected, dummy0, weight 1, 00:14:45

VRF default:
K>* 0.0.0.0/0 [0/0] via 172.20.20.1, eth0, weight 1, 00:14:45
L * 10.0.0.1/32 is directly connected, lo, weight 1, 00:14:45
C>* 10.0.0.1/32 is directly connected, lo, weight 1, 00:14:45
C>* 172.20.20.0/24 is directly connected, eth0, weight 1, 00:14:45
L>* 172.20.20.5/32 is directly connected, eth0, weight 1, 00:14:45

Additional context

Here is the VPN table, notice both routes are invalid.

pe# sh bgp ipv4 vpn detail
BGP table version is 0, local router ID is 10.0.0.1, vrf id 0
Default local pref 100, local AS 64512
Route Distinguisher: 64512:1
BGP routing table entry for 64512:1:10.0.0.1/32, version 0
not allocated
Paths: (1 available, no best path)
  Not advertised to any peer
  Local
    0.0.0.0(pe) from 0.0.0.0 (10.0.0.1) vrf default(0) announce-nh-self
      Origin IGP, metric 0, weight 32768, invalid, sourced, local
      Extended Community: RT:64512:1
      Originator: 10.0.0.1
      Remote label: 3
      Last update: Mon Dec  9 04:26:52 2024
Route Distinguisher: 64512:2
BGP routing table entry for 64512:2:10.0.0.2/32, version 0
not allocated
Paths: (1 available, no best path)
  Not advertised to any peer
  Local
    0.0.0.0(pe) from 0.0.0.0 (10.0.0.1) vrf blue(2) announce-nh-self
      Origin IGP, metric 0, weight 32768, invalid, sourced, local
      Extended Community: RT:64512:2
      Originator: 10.0.0.1
      Remote label: 3
      Last update: Mon Dec  9 04:26:52 2024

Displayed 2 routes and 2 total paths

If redistribute connected is used instead of the network statements, then the routes are installed just fine.

pe# sh ip route vrf all
Codes: K - kernel route, C - connected, L - local, S - static,
       R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
       f - OpenFabric, t - Table-Direct,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

VRF blue:
B>* 10.0.0.1/32 [20/0] is directly connected, lo (vrf default), weight 1, 00:03:22
L * 10.0.0.2/32 is directly connected, dummy0, weight 1, 00:03:23
C>* 10.0.0.2/32 is directly connected, dummy0, weight 1, 00:03:23
B>* 172.20.20.0/24 [20/0] is directly connected, eth0 (vrf default), weight 1, 00:03:22

VRF default:
K>* 0.0.0.0/0 [0/0] via 172.20.20.1, eth0, weight 1, 00:03:23
L * 10.0.0.1/32 is directly connected, lo, weight 1, 00:03:23
C>* 10.0.0.1/32 is directly connected, lo, weight 1, 00:03:23
B>* 10.0.0.2/32 [20/0] is directly connected, blue (vrf blue), weight 1, 00:03:22
C>* 172.20.20.0/24 is directly connected, eth0, weight 1, 00:03:23
L>* 172.20.20.5/32 is directly connected, eth0, weight 1, 00:03:23

Checklist

  • I have searched the open issues for this bug.
  • I have not included sensitive information in this report.
@packet-time packet-time added the triage Needs further investigation label Dec 9, 2024
@varuntumbe
Copy link

I will try to repro using topotest and let you know if I have any questions !

@packet-time
Copy link
Author

Any luck reproducing this?

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

2 participants