A study on community-triggered updates in BGP

Maria Matějka maria.matejka at nic.cz
Mon Oct 19 23:33:32 CEST 2020


Hi Thomas,

Thank you for your clarification.

There is a plausible reason why to keep the internal communities with the route. It is external debug info which you can get from BGP monitoring services. Anyway, there may be also cases of just misconfiguration. We all know, people are leaving trash everywhere and Internet is not a protected area of nature where you have to bring literally everything back when leaving. However, we can't clean up for others; the community attributes are transitive by definition. We must just pass them through. 

The trade-off in BIRD of not keeping Adj-RIB-Out, should anyway not lead to what you are proposing. When the receiving site finds exactly the same route in their tables, they should not reannounce it further so the spreading stops at the first neighbor's ingress. At least BIRD does it this way; I don't remember exactly what is in RFC about this situation. 

Maria


On October 19, 2020 11:04:41 PM GMT+02:00, Thomas Krenc <tkrenc at nps.edu> wrote:
>Hi Maria,
>
>I agree with what you are saying.
>
>One minor clarification in the definitions: we observe (i) duplicates,
>i.e., AS path and community attribute don't change, as well as (ii)
>announcement where AS path don't change, but the community attribute
>does. Interestingly, we show in the experiments that an AS-internal
>change in the community attribute **only** can lead to these
>observations.
>
>In that regard, the tradeoff you are describing is very interesting.
>Because the dicision of one AS not to filter, in paricular (ii), has an
>impact on neighboring ASes; and if they don't filter, they have an
>impact on their neighbors etc.
>
>It's relatively hard to tell how frquent that happen, since a lot of
>updates are not visible to us. But from the BGP collectors perspective,
>we observe that around 50% of all announcements fall into the category
>(i) and (ii), in March 2020.
>
>Thanks for your feedback. It's very insightful!
>
>best regards
>Thomas
>
>On 10/17/20 10:39 AM, Maria Matějka wrote:
>> Hello!
>>
>> If I read your paper correctly, I assume that this is just a feature
>> of the BGP itself. To make it clear: I read that in some cases when a
>> link inside one AS goes down, a route is reannounced with the same AS
>> path but different communities because of e.g. some internal tagging
>> which you call duplicate. Please correct me if I'm wrong.
>>
>> This is definitely something for the admin of that AS whether they
>> want to share such an information outside or not. We can't say from a
>> global perspective whether they shall or shan't reannounce that
>route.
>> They may want to, they may not want to reannounce. It depends on lots
>> of things.
>>
>> So from my perspective, as a developer of BIRD, this is a matter of
>> configuration. If some of your routers do some tagging, it's your
>> configuration as well as the configuration of the outbound router
>> where you can strip these tags if you want.
>>
>> BIRD shall be never smarter than its user.
>>
>> There is also another thing that in case of egress filtering, BIRD
>may
>> send a duplicate announcement if it is not sure about the contents of
>> the previous route. From my point of view, it is a tradeoff. We save
>> memory by not keeping the Adj-RIB-Out by default. This can be
>switched
>> on by the "export table on" setting in the appropriate bgp channel
>> with the cost of some memory overhead.
>>
>> I hope I've answered you well, feel free to discuss or correct me if
>I
>> misunderstood anything.
>>
>> Thank you for the research. BTW, do you have an estimation on how
>> frequently does it happen?
>>
>> Maria
>>
>>
>> On October 17, 2020 1:43:54 AM GMT+02:00, Thomas Krenc
>> <tkrenc at nps.edu> wrote:
>>
>>     Dear BIRD users and developers,
>>
>>     As a team of researchers from NPS and TU Berlin, we are
>investigating
>>     the impact of BGP community attributes on the update behavior
>between ASes.
>>
>>     We find that when a route is associated with multiple distinct
>community
>>     attributes it does not only lead to multiple announcement at the
>tagging
>>     AS, but also at neighboring ASes, if communities are not filtered
>>     properly. This behavior is wide-spread.
>>
>>     In order to better understand our observations, we have performed
>a
>>     series of laboratory experiments using Cisco IOS, Junos OS, as
>well as
>>     the BIRD daemon.
>>
>>     We find that - by default - all routers generate announcements
>with
>>     changing community attributes, even when other attributes do not
>change.
>>     In addition, when communities are filtered at egress, Cisco und
>BIRD
>>     send duplicate announcements (Juniper does not).
>>
>>         Is this side-effect known to the BIRD community and would you
>>     consider it a bug or a feature?
>>
>>     Since our findings are limited to observations in public data as
>well as
>>     few router implementations, we would like to share our research
>and
>>     kindly ask you to have a look at:
>>
>>         https://www.cmand.org/communityexploration/
>>
>>     There, we provide some resources documenting our research, as
>well as
>>     open questions. We greatly appreciate any feedback and insights
>you can
>>     offer. Also, please don't hesitate to contact us directly:
>>
>>         communityexploration AT cmand DOT org
>>
>>     best regards
>>
>>     Thomas Krenc
>>     Postdoctoral Researcher
>>     Naval Postgraduate School
>>
>>
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20201019/f7710e21/attachment.htm>


More information about the Bird-users mailing list