the bgpd: fix 6vpe nexthop commit has broken the v4 neighbor's global nexthop and the bfd_topo3 test case

[donaldsharp]

Description

Under bgp when you configure a v4 peer and activate it under v6, prior to this commit the nexthops available to the peering was this:

Nexthop: 192.168.1.1
Nexthop global: 2001:db8:1::1
Nexthop local: fe80::8c97:fdff:fe9e:ec61

With this change it has become:

Nexthop: 192.168.1.1
Nexthop global: ::ffff:c0a8:101
Nexthop local: fe80::8466:65ff:fe8b:be6c

This causes the v6 route to be installed with a v4 translated address

B>  2001:db8:3::/64 [20/0] via ::ffff:c0a8:201 (recursive), weight 1, 00:04:32
  *                          via 192.168.1.2, r1-eth0, weight 1, 00:04:32

Which of course does not forward anything in linux at all. As a result the bfd_topo3 test case is failing sometimes because the bfd peering does not come up for the 2001:db8:3::1 peer

Version

Anything after commit 

0325116a27258e1df773a046e8668a029bead60c is the first bad commit
commit 0325116a27258e1df773a046e8668a029bead60c
Author: Louis Scalbert <louis.scalbert@6wind.com>
Date:   Thu Feb 15 13:28:02 2024 +0100

    bgpd: fix 6vpe nexthop

shows this problem

How to reproduce

run the bfd_topo3 topotest and pause and look at the output of show bgp ipv6 uni and show bgp neighbor 192.168.2.1 and ensure that the global nexhtop is correct

Expected behavior

described above

Actual behavior

described above

Additional context

No response

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[ton31337]

Related #15614, we reverted this for 10.0 already, but #15614 might fix the issue?

[ton31337]

@louis-6wind could you take a look again at #15614?

[louis-6wind]

#15614 is merged