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
Description
Description
Details
Details
- Version
- -
- Is it a breaking change?
- Unspecified (possibly destroys the router)
Related Objects
Related Objects
Event Timeline
Comment Actions
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.
This comment was removed by MrXermon.
Comment Actions
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
Comment Actions
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 iComment Actions
@MrXermon were you able to workaround the next hop issue you describe here as I am getting the same result from my peers?
Comment Actions
Sadly not. I can reproduce the error but i am not able to fix the problem in the code.
Comment Actions
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.
Comment Actions
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.
Comment Actions
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 ;)
Comment Actions
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