BGP peering with BFD is established twice #17337
Assignees
Labels
Comments
|
This is because most likely BFD was not established and BGP sent a notification: |
|
Hi thank you for the reply. I have been observing the pcap, and I can see that the BFD was up before the OPEN messages.
Do you see a way to configure the FRRs to avoid that session reset? Or is that expected? |
|
According to this:
This is expected. |
|
So, should I conclude that there is no configuration that will set up BGP with BFD peering and will avoid this behavior? Is that accurate? (Context: I am trying graceful restart, and that behavior at the end removes the routes that GR stales) |
|
Either way, the BFD notification event triggers a notification (With GR notification support which is disabled in your case too), where the behavior is the same (the RFC (https://datatracker.ietf.org/doc/html/rfc9384) defines it as a HARD RESET). |
|
Can you elaborate? I am no sure I understand what you suggest. BFD notification triggers BGP Cease notification is ok. I try to understand why there is a BFD down event happens in the first place and how to avoid it. In other words, now what is happening : (I think)
Is there a way to delay bfd (after BGP) or configure it in way that no update is needed? Thanks |
|
Can you try with delay OPEN? E.g. |
|
I have alreay tried that option, I see not difference. I can re-try to be sure. Why do you suggest that? I mean delayopen delays the OPEN message so when you have both active BGP peers will avoid trying open at the same time the peering or is it related to bfd? |
|
I meant that with delay OPEN we give some time for BFD to be UP before establishing the BGP session. |
|
I will re-try ok and I will come back. But given those logs I think the problem is that bfd is up with not the right local-address/interface and BGP is correcting it (source) |
|
thanks I have to check how to pack a commit into an image first so I can try it. Until then here are the logs with delayopen to 240 seconds What is unclear |
|
You can take .rpm/.deb from here by the OS: https://ci1.netdef.org/browse/FRR-PULLREQ3-5951/artifact. |
|
Hi, I tried and once I have both ends updated to that commit and I do not see any drop anymore. Need to run some more tests but it looks ok. Thanks |
karampok
added a commit
to karampok/frr-k8s
that referenced
this issue
Nov 7, 2024
- check the bgp peering is in place at all times - use custom image with fix [0] on top of stable 9.1 [0] FRRouting/frr#17344 [1] FRRouting/frr#17337 Signed-off-by: karampok <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
When doing a BGP Peering with BFD between two FRR peers (peer A and peer B), the BGP is established but the peering takes place twice. This can be observed by the
Version
in both peers
How to reproduce
Peer A, the frr config was added using the reloader script
and the frrconfig
Peer B (config on the disk, ready before peer A starts)
Expected behavior
I would expect a peering happening once, no dropped connection
Actual behavior
Additional context
The logs indicate that once first BGP peering takes place, the bfd_session must be updated which result into terminating peering and re-establishe.
Checklist
Do you see any wrong-doing when comes to configuration? Is there a way to configure it differently to avoid that from happening? Thank you
The text was updated successfully, but these errors were encountered: