bgpd: Fix BGP to update correct v6 next-hop globally #15919
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Issue: In a dual-stack IPv4/IPv6 BGP session, after the interface is deactivated (ifdown) and then reloaded (ifreload), the global next-hop within BGP is incorrectly updated. Currently, only unnumbered neighbors are handled. We also need to handle an IPv4 neighbor when IPv6 AFI-SAFI is enabled. Fix: When the primary global v6 unicast address is received from Zebra, BGP updates the peer's global next-hop with the correct address and send update to its negibors. Testing: UT, and TestEbgpMultihop tests UT logs: with fix: root@cumulus:mgmt:/tmp# ifdown swp1s0; ifreload -a root@:mgmt:/tmp# vtysh -c "show ip bgp vrf all neighbors" | grep Nexthop Nexthop: 20.1.2.101 Nexthop global: 2001:10:1:2::101 Nexthop local: fe80::7efe:90ff:fefa:e158 without fix after ifreload: Nexthop: 20.1.2.101 Nexthop global: :: Nexthop local: fe80::7efe:90ff:fefa:e158 Ticket: #3870831 Signed-off-by: Rajesh Varatharaj <[email protected]> and Pooja Doijode [email protected]
ton31337
requested changes
May 4, 2024
| link_if = NULL; | ||
| char ip_buf[ETHER_ADDR_STRLEN]; |
There was a problem hiding this comment.
Please move this above link_if and a newline after variables (same is suggested by frrbot/verify check).
| if (IS_ZEBRA_DEBUG_KERNEL) | ||
| zlog_debug( | ||
| " Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring"); | ||
| " Neighbor Entry IF %s(%u) and IP %s is not on a VLAN or BRIDGE, ignoring", |
There was a problem hiding this comment.
nit: and IP can it be one whitespace?
|
@Mergifyio backport stable/10.0 |
🟠 Waiting for conditions to match
|
|
@routingrocks could you rebase? |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
Normally, the issue is fixed by #15614, which is now merged |
|
@frrbot autoclose in 1 month |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue:
In a dual-stack IPv4/IPv6 BGP session, after the interface is deactivated (ifdown) and then reloaded (ifreload), the global next-hop within BGP is incorrectly updated. Currently, only unnumbered neighbors are handled.
We also need to handle an IPv4 neighbor when IPv6 AFI-SAFI is enabled.
Fix:
When the primary global v6 unicast address is received from Zebra, BGP updates the peer's global next-hop with the correct address and send update to its negibors.
Testing: UT, and TestEbgpMultihop tests
UT logs:
with fix:
root@:mgmt:/tmp# ifdown swp1s0; ifreload -a root@:mgmt:/tmp# vtysh -c "show ip bgp vrf all neighbors" | grep Nexthop Nexthop: 20.1.2.101
Nexthop global: 2001:10:1:2::101
Nexthop local: fe80::7efe:90ff:fefa:e158
without fix after ifreload:
Nexthop: 20.1.2.101
Nexthop global: ::
Nexthop local: fe80::7efe:90ff:fefa:e158
Ticket: #
Signed-off-by: Rajesh Varatharaj [email protected] and Pooja Doijode [email protected]