Page MenuHomeVyOS Platform

Add support for Large BGP Community
Closed, ResolvedPublic


Dear VyOS community,

Is there any plan to add support for Large BGP communities (1)? ExaBGP and Cisco (IOS XR) already implemented it (2), other vendors are moving too.

Since almost one in four ASNs in the DFZ are 4-byte ASNs, 4-byte ASNs cannot properly use RFC1997 communities - the internet has a problem, especially newcomers. RIPE and ARIN are scraping the bottom of the barrel for 2-byte ASNs (they both only have tens left).

The Large BGP Community is specifically designed with simplicity in mind. Will VyOS add support for it?



Difficulty level
Normal (likely a few hours)

Event Timeline

job updated the task description. (Show Details)
syncer raised the priority of this task from Normal to High.

@dmbaturin what do you think?

Let me know if you require any additional information. I'm happy to help you with interop testing

and if vyos does have an implementation i'd like to include it in my rfc7942 reports!

Interested in this too. We will be multi-homing soon and requesting an AS number from ARIN. I doubt we will be getting a 2-byte ASN.

Keep in mind that the specification has not yet been standardised. If you commit to implementing, make sure you only release it as a 'beta' or 'test release'.

Through an early allocation, IANA assigned 30 as the path attribute value for Large BGP Communities.

Why aren't you all discussing this on the Quagga mailing list? More generally, what is the VyOS project policy about work that belongs in upstream?

In fact, I think I read someone's post about working on this on the Quagga dev list not that long ago, but even if I'm wrong, isn't that where this sort of work belongs? Excepting only minor details of the CLI, there should be no difference in the code base, and you're much more likely to get good code review (or someone else's code, already written) there simply because the project has more participants.

Of course, as VyOS and Quagga get more out of sync, this will get harder, but I just posted about that separately...

The Quagga has been provided with a patch to support Large BGP Communities. This patch is for Quagga 1.1.0 but should be easy to backport if needed.

Reviewed the discussion there - I think we have to wait at least couple of weeks until it will be at least a little bit tested there...

Yes, waiting a bit does not hurt. We are working on version 3 of the patch to accomodate the missing features

The specification has been published as IETF standard:

Both Quagga and FreeRangeRouting have implemented support for BGP Large Communities and put it in releases.

Can this move forward?

I am very interested in this, has any work been done?

syncer set Version to -.
syncer removed a subscriber: VyOS 2.0.x.
syncer lowered the priority of this task from High to Normal.Jun 10 2018, 3:03 AM
syncer changed the task status from Open to In progress.Aug 13 2018, 9:22 PM

This will be added with FRR integration

FRR is now included in 1.2.0rc but no large communities. It would be very nice to have support for it cause people like me got only 32bit ASN.....

<dmbaturin> Hi! If you are ready to help with testing it, I'll be happy to make a CLI.
<dmbaturin> I think it should be orthogonal with all other features indeed, so a perfec candidate for RC3.

FRR example for large bgp communities:

Large Community Lists

Two types of large community lists are supported, namely standard and expanded.

ip large-community-list standard NAME permit|deny LARGE-COMMUNITY

    This command defines a new standard large-community-list. large-community is the Large Community value. We can add multiple large communities under same name. In that case the match will happen in the user defined order. Once the large-community-list matches the Large Communities attribute in BGP updates it will return permit or deny based upon the large-community-list definition. When there is no matched entry, a deny will be returned. When large-community is empty it matches any routes.

ip large-community-list expanded NAME permit|deny LINE

    This command defines a new expanded large-community-list. Where line is a string matching expression, it will be compared to the entire Large Communities attribute as a string, with each large-community in order from lowest to highest. line can also be a regular expression which matches this Large Community attribute.

no ip large-community-list NAME

no ip large-community-list standard NAME

no ip large-community-list expanded NAME

    These commands delete Large Community lists specified by name. All Large Community lists share a single namespace. This means Large Community lists can be removed by simply specifying the name.

show ip large-community-list

show ip large-community-list NAME

    This command display current large-community-list information. When name is specified the community list information is shown.

show ip bgp large-community-info

    This command displays the current large communities in use.

Large Communities in Route Map

match large-community LINE

    Where line can be a simple string to match, or a regular expression. It is very important to note that this match occurs on the entire large-community string as a whole, where each large-community is ordered from lowest to highest.

set large-community LARGE-COMMUNITY


set large-community LARGE-COMMUNITY additive

    These commands are used for setting large-community values. The first command will overwrite any large-communities currently present. The second specifies two large-communities, which overwrites the current large-community list. The third will add a large-community value without overwriting other values. Multiple large-community values can be specified.
syncer added a project: VyOS-1.2.0-GA.