Page MenuHomeVyOS Platform

BGP neighbours with IPv6 link-local addresses
Needs testing, NormalPublicFEATURE REQUEST

Description

It would be great if BGP neighbours with IPv6 link-local addresses and interface alias were possible.

admin@rt-1# set protocols bgp ASN neighbor fe80::42%eth1

  "fe80::42%eth1" is not a valid value
  Value validation failed
  Set failed

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)

Event Timeline

syncer triaged this task as Low priority.
syncer removed a project: VyOS 1.2 Crux.

It is not possible to use this exact syntax in FRR, and it's not possible to fake it in the current BGP script either. It is possible to add a new "interface" option to match the FRR CLI though.

In my experimental change it seems to work:

vyos@vyos-test-1# set protocols bgp 64444 neighbor fe80::46 interface eth1
[edit]
vyos@vyos-test-1# commit
[edit]
vyos@vyos-test-1# vtysh -c 'sh run' | grep fe80::46
 neighbor fe80::46 remote-as 63334
 neighbor fe80::46 interface eth1

Of course it needs real life testing.

dmbaturin changed the task status from Open to In progress.Nov 18 2018, 2:47 PM
This comment was removed by MrXermon.

The BGP seems to be working but the summary is not quite correct (State/PfxRcd is wrong).

admin@rt-1:~$ show ipv6 bgp summary

IPv6 Unicast Summary:
BGP router identifier 172.20.178.96, local AS number 4242423506 vrf-id 0
BGP table version 861
RIB entries 454, using 67 KiB of memory
Peers 8, using 164 KiB of memory

Neighbor           V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
fdb4:4911:ccf8::97 4 4242423506     955     581        0    0    0 00:17:52          233
fe80::42:194       4 4242423934     331     247        0    0    0 00:12:18            0
fe80::465:1337:1   4 4242420131     205     194        0    0    0 00:03:14            0

Total number of neighbors 3

Found another bug. Routes are shown via received-routes but with a wrong next-hop address (:: instead of fe80::465:1337:1 in my case) and they are not installed in the FIB.

admin@rt-1:~$ show ipv6 bgp neighbors fe80::465:1337:1 routes

admin@rt-1:~$ show ipv6 bgp neighbors fe80::465:1337:1 received-routes
BGP table version is 0, local router ID is 172.20.178.96, vrf id 0
Status codes:  s suppressed, d damped, h history, * 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

   Network          Next Hop            Metric LocPrf Weight Path
*> fd00:4242:3348::/48
                    ::                                     0 4242420131 4242422601 4242422950 4242423348 i
*> fd00:65a8:93a4::/48
                    ::                                     0 4242420131 4242421191 65026 4242421271 4242422800 65142 i
*> fd00:aaaa:251::/48
                    ::                                     0 4242420131 4242423934 4242420144 i
*> fd00:aaaa:255::/48
                    ::                                     0 4242420131 4242423934 4242420144 i
*> fd00:aaaa:256::/48
                    ::                                     0 4242420131 4242423905 4242420022 4242422777 4242420117 i
*> fd01:67c:2ed8::/48
                    ::                                     0 4242420131 4242423905 65043 65038 i
*> fd04:52c0:4000::/48
                    ::                                     0 4242420131 4242423905 4242423585 i
*> fd0a:3599:3930::/48
                    ::                                     0 4242420131 4242423905 64737 4242421233 i
*> fd0b:21e1:fd0b::/64
                    ::                                     0 4242420131 4242420789 76190 76175 4242420002 i
*> fd10:1074:41f6::/48
                    ::                                     0 4242420131 4242423934 4242420138 64752 i
*> fd12:ee00:9898::/48
                    ::                                     0 4242420131 4242423640 i

@MrXermon were you able to workaround the next hop issue you describe here as I am getting the same result from my peers?

Sadly not. I can reproduce the error but i am not able to fix the problem in the code.

syncer added a subscriber: c-po.
syncer changed the task status from In progress to Needs testing.Feb 8 2019, 12:15 AM
syncer reassigned this task from dmbaturin to zsdc.
syncer raised the priority of this task from Low to Normal.
zsdc added a subscriber: zsdc.

Is there any way I can help test this? I was trying to setup the same, but lack of link-local support prevents me from adding a v6 BGP peer without allocating IP addresses to the link.

I would like to test as well. I have successfully setup link local peering with 2 vyos routers using the new "interface v6only" option. However, I am unable to establish a link local session when peering with a different vendor.

Unknown Object (User) added a subscriber: Unknown Object (User).Aug 20 2020, 6:05 PM

Hi, any updates on this?

I'm really having a hard time peering using link-local addresses...

If I can help in some way.... i'm here ;)

dmbaturin set Is it a breaking change? to Unspecified (possibly destroys the router).

this is very similar to https://phabricator.vyos.net/T3657 , so it seems that this is going to be fixed in 1.4 ( proof https://forum.vyos.io/t/bgp-peering-with-ipv6-link-local-addresses/7309/14 ). Is this going to be backported to 1.3 ? Anyone is able to find the commit that introduced the feature on 1.4? Maybe it is something easy to patch