iBGP Sessions Flapping due to AIGP attribute after Upgrading 9.0.1/9.0.2 from 8.5.1 #15884
Replies: 8 comments 9 replies
-
Quick question: what are the versions between FRR nodes? Is it like peering between 9.0.1 <--> 9.0.1, 9.0.1 <--> 9.0.2, or what actually? |
Beta Was this translation helpful? Give feedback.
-
Also, as a side note, 8.5.1 is broken in terms of AIGP, you shouldn't use it at all, please upgrade to 8.5.2 at least. |
Beta Was this translation helpful? Give feedback.
-
Actually, our FRR daemon runs on bare metal, while the peer is Cisco equipment. The change that occurred is in the version on the server side. It is like peering between 8.5.1 (server) <-> cisco (leaf), 9.0.1 (server) <-> cisco (leaf), 9.0.2 (server) <-> cisco (leaf) |
Beta Was this translation helpful? Give feedback.
-
We're currently puzzled as the article suggests upgrading to 8.5.2, but when we upgraded to 9.0.1/9.0.2, we encountered iBGP flapping issues. We're uncertain how to address this. |
Beta Was this translation helpful? Give feedback.
-
Every node in the "cluster" should use a minimum of 8.5.2 (better the latest of 8.5.x). |
Beta Was this translation helpful? Give feedback.
-
Hi @ton31337 , Today, we made a new discovery from the recorded BGP packets.
We also attempted We're seeking a solution that aligns with the description in RFC 7311, Section 3.3, which states that if an AIGP attribute is received on a BGP session where AIGP_SESSION is disabled, it should be treated as if it were an unrecognized non-transitive attribute. Specifically, it "must be quietly ignored and not passed along to other BGP peers." Is there any other way to disable the AIGP attribute in iBGP? |
Beta Was this translation helpful? Give feedback.
-
Yes, that's correct. We received an Update message from Cisco containing the AIGP attribute with both the transitive and partial bits set to 1. However, we haven't succeeded in discarding the AIGP attribute using the path-attribute command, nor have we been able to directly disable AIGP in iBGP.
|
Beta Was this translation helpful? Give feedback.
-
I am guessing this is the same issue I ran into here going from 8.5.1 to 8.5.4. Is there a similar work around that could be used in 8.x ? https://lists.frrouting.org/pipermail/frog/2023-June/001278.html
|
Beta Was this translation helpful? Give feedback.
-
Description
Recently, we upgraded both the kernel and FRR, and noticed that after upgrading FRR from 8.5.1 to 9.0.2, upon reboot, the iBGP session starts flapping and fails to establish the BGP peer successfully.
Currently, we don't have any insights into the issue. However, we observed that reverting back to version 8.5.1 resolves the problem, with the same configuration resulting in normal iBGP session functionality
Version
How to reproduce
Expected behavior
The iBGP sessions can be established successfully after upgrading
frr 8.5.1:
Actual behavior
frr 9.0.2:
Additional context
frr 9.0.2
"We have observed that during the iBGP session flapping, numerous AIGP attribute logs frequently appear in the FRR log
frr config:
Checklist
Beta Was this translation helpful? Give feedback.
All reactions