Page MenuHomeVyOS Platform

L3VPN - redistribute connected does not export prefixes into VPNv4 table (Related to T4846)
Closed, InvalidPublicBUG

Description

We are reopening this bug based on reproduction confirmed by the VyOS TAC team and multiple engineers in a lab environment running FRR 9.1.3 and 10.5.2.

The fix introduced in FRR PR#12545 (backported to FRR 8.4.1 and included in FRR 8.5) is no longer effective in FRR 9.1.3. The redistribute connected directive within a VRF BGP instance does not export connected prefixes into the VPNv4 table, even though the full VPN export policy is correctly configured.

Bug reproduction:

set vrf name CUST-DEMO1 protocols bgp address-family ipv4-unicast export vpn
set vrf name CUST-DEMO1 protocols bgp address-family ipv4-unicast import vpn
set vrf name CUST-DEMO1 protocols bgp address-family ipv4-unicast label vpn export 'auto'
set vrf name CUST-DEMO1 protocols bgp address-family ipv4-unicast rd vpn export '10.208.90.3:19'
set vrf name CUST-DEMO1 protocols bgp address-family ipv4-unicast route-target vpn both '65001:19'
set vrf name CUST-DEMO1 protocols bgp address-family ipv4-unicast redistribute connected metric '0'
set interfaces ethernet eth2 vif 999 address '169.254.1.1/24'
set interfaces ethernet eth2 vif 999 vrf 'CUST-DEMO1'
vyos@vyos:~$ show ip route vrf CUST-DEMO1
C>* 169.254.1.0/24 is directly connected, eth2.999
vyos@vyos:~$ show bgp ipv4 vpn neighbors 10.208.90.1 advertised-routes
(empty)

Workaround:
Using the network command combined with "no bgp network import-check" allows the prefix to be exported. However, this workaround introduces a secondary issue: when no bgp network import-check is disabled, FRR does not withdraw the prefix from the BGP table when the interface is removed, resulting in a stale advertisement:

Deleting the interface:

show ip route vrf CUST-DEMO1
169.254.10.0/24 #is correctly away from the RIB
show ip bgp vrf CUST-DEMO1
*> 169.254.10.0/24 0.0.0.0 0 32768 i #still advertised


Environment:

VyOS version:   1.4 and 1.5.0 H1
FRR version:    9.1.3 and 10.5.2-0
Underlay:       OSPF + MPLS + Segment Routing
Overlay:        iBGP VPNv4 (L3VPN)
Reproduced by:  VyOS TAC team + multiple engineers in lab
Reproducible:   100% of the time

References:

T4846 — L3VPN network command does not install direct connected prefix
FRR Issue #12502
FRR PR #12545
FRR fix included in FRR 8.5 — regression confirmed in FRR 9.1.3{F114101832}

Details

Version
1.5.0
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Unspecified (please specify)

Event Timeline

c.faria triaged this task as High priority.
c.faria created this object in space S1 VyOS Public.
c.faria created this object with edit policy "All Users".

To be noted that "Logical interface" (like dummy), and physical interfaces, do work. However, virtual interfaces (vif) don't.

dum0         192.168.100.1/24  c2:2b:d5:03:56:48  CUST-DEMO1   1500  u/u
eth0         -                 0c:b7:52:32:00:00  default      1500  u/D
eth1         -                 0c:b7:52:32:00:01  default      1500  u/u
eth1.504     10.208.91.11/31   0c:b7:52:32:00:01  default      1500  u/u    Peer1
eth1.999     169.254.10.1/24   0c:b7:52:32:00:01  CUST-DEMO1   1500  u/u
eth2         -                 0c:b7:52:32:00:02  default      1500  u/D
eth3         -                 0c:b7:52:32:00:03  default      1500  u/D
eth4         -                 0c:b7:52:32:00:04  default      1500  u/D
eth5         -                 0c:b7:52:32:00:05  default      1500  u/D
lo           127.0.0.1/8       00:00:00:00:00:00  default     65536  u/u
             10.208.90.5/32
             ::1/128
BGP table version is 1, local router ID is 10.208.90.5, vrf id 0
Default local pref 100, local AS 65001
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
Route Distinguisher: 10.208.90.5:19
 *>  192.168.100.0/24 0.0.0.0@9<               0         32768 ?
    UN=0.0.0.0 EC{65001:19} label=80 type=bgp, subtype=5

Displayed 1 routes and 1 total paths

According to https://github.com/FRRouting/frr/issues/12834, FRR does not support Link-Local: 169.254.0.0 – 169.254.255.255 (Automatic private IP addressing)