Page MenuHomeVyOS Platform

Ability to have right address-family for BGP peers.
Open, HighPublicFEATURE REQUEST

Description

The VyOS syntax doesn't allow removal ipv6 neighbors from address-family ipv4-unicast.
We need to rethink this logic.

VyOS

set protocols bgp 65001 address-family ipv4-unicast
set protocols bgp 65001 address-family ipv6-unicast
set protocols bgp 65001 neighbor 10.0.0.2 address-family ipv4-unicast
set protocols bgp 65001 neighbor 10.0.0.2 remote-as '65002'
set protocols bgp 65001 neighbor 1111:2222:33::1111:2222:1 address-family ipv6-unicast
set protocols bgp 65001 neighbor 1111:2222:33::1111:2222:1 remote-as '65002'

Vtysh show run:

!
router bgp 65001
 neighbor 10.0.0.2 remote-as 65002
 neighbor 1111:2222:33::1111:2222:1 remote-as 65002
 !
 address-family ipv6 unicast
  neighbor 1111:2222:33::1111:2222:1 activate
 exit-address-family
!
line vty
!

After commit, add command

set protocols bgp 65001 parameters default no-ipv4-unicast

vtysh

!
router bgp 65001
 no bgp default ipv4-unicast
 neighbor 10.0.0.2 remote-as 65002
 neighbor 1111:2222:33::1111:2222:1 remote-as 65002
 !
 address-family ipv4 unicast
  neighbor 10.0.0.2 activate
  neighbor 1111:2222:33::1111:2222:1 activate
 exit-address-family
 !
 address-family ipv6 unicast
  neighbor 1111:2222:33::1111:2222:1 activate
 exit-address-family
!

We see ipv6 peer in address-family ipv4-unicast.

If we delete all BGP and build one commit with all commands, include "parameters default no-ipv4-unicast", all address-families in their places.

!
router bgp 65001
 no bgp default ipv4-unicast
 neighbor 10.0.0.2 remote-as 65002
 neighbor 1111:2222:33::1111:2222:1 remote-as 65002
 !
 address-family ipv4 unicast
  neighbor 10.0.0.2 activate
 exit-address-family
 !
 address-family ipv6 unicast
  neighbor 1111:2222:33::1111:2222:1 activate
 exit-address-family
!

Details

Difficulty level
Normal (likely a few hours)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Behavior change
Issue type
Feature (new functionality)

Event Timeline

I would very much like you reconsider classifying this as a bug if not security issue.

Having address-family IPv4 unicast per default a v6 sessions means that if you only configure v6 import/export filters on a v6 session you will also accept and announce anything IPv4 unicast on such a session.

c-po triaged this task as High priority.Jul 8 2020, 6:01 PM
c-po changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).
c-po changed Is it a breaking change? from Unspecified (possibly destroys the router) to Behavior change.
c-po added a subscriber: c-po.

My guess is this will be resolved by the full BGP rewrite - I also do not like the current behavior.

This actually feels like an FRR bug as this still occurs with the new XML/Python rewrite

In the new xml/py rewrite, do they disapear if you rerun the bgp configurator script? Eg. Can we execute frr-reload twice as a workaround?

just wanting to chime in here, I think I've been bitten by what appears to be a similar cause.

When configuring a BGP peer to only have address-family ipv6-unicast configured, it appears to put 'no neighbour x:x:x::x activate' under the address-family ipv4 stanza. However: at boot, it appears that whatever logic is sending the configuration to FRR doesn't realise and doesn't disable the address family. This unfortunately causes my IPv6 peers to refuse to come up at boot-- adding and removing the ipv4-unicast address family from the peer appears to fix the issue.

erkin set Issue type to Feature (new functionality).Mon, Aug 30, 6:50 AM
erkin removed a subscriber: Active contributors.