BGP Communities

This document is an informative description of the BGP communities supported by Inter.link AS5405. The applicable service order, Service Level Agreement (SLA), and Master Services Agreement (MSA) prevail in the event of any conflict.

Scope and applicability

This document defines the origin communities, traffic-engineering communities, standard communities, remote-triggered blackholing (RTBH), and DDoS redirect community for BGP sessions with Inter.link AS5405. It applies to IP Transit and FlexTunnel wherever those services refer to the Inter.link BGP communities. Route validation, route acceptance, and attribute handling are defined in the separate Routing Policies document. A route must be accepted under that policy before its communities are acted on.

Inter.link publishes informational origin communities and customer signalling communities for traffic engineering. The community facility is provided on a best-effort basis, is not subject to a product-specific SLA, and may change. The current catalogue is documented in the sections below, with the full identifier list in the Community identifier appendix.

Community handling

Only the communities documented in this specification are part of the supported customer-facing policy. Other communities are not interpreted by Inter.link, and their continued presence is not guaranteed.

Customer-supplied standard communities in the 5405:* namespace are processed where applicable but are not propagated as received. Inter.link applies the applicable origin communities. Inter.link signalling Large Communities in the 5405:*:* namespace are non-transitive and are removed before advertisement to other external BGP neighbours.

Origin communities

Inter.link tags every accepted route at ingress with standard BGP communities that identify where and from which type of network relationship the route was learned.

Community pattern	Meaning
5405:P	Peer type from which the route was learned
5405:1R	Continent where the route was learned
5405:2CC	Country where the route was learned
5405:3ZZZ	City where the route was learned
5405:4SSS	Inter.link PoP where the route was learned

The scope digit and identifier are concatenated in the second component of the standard community. Country, city, and PoP identifiers are zero-padded to two, three, and three digits respectively. The peer ASN is not set as an origin community because it is already present in the route’s AS path. For example, the following set describes a route learned through IXP peering at BER1-DE in Berlin, Germany:

Community	Meaning
5405:3	IXP peering
5405:15	Europe
5405:208	Germany
5405:3003	Berlin
5405:4004	BER1-DE

Signalling-community format

Traffic-engineering instructions use BGP Large Communities. Unlike many networks, Inter.link accepts these signalling communities, as well as the selective RTBH communities, from peers as well as from customers. Multiple signalling communities may be attached to one route. Inter.link removes these signalling communities before announcing the route to other external BGP neighbours.

A signalling community has the form 5405:<scope><location><P><action>:<AAA>.

Symbol	Meaning	Wildcard
scope	1 for continent, 2 for country, 3 for city	None
R	One-digit continent identifier	0 for all continents
CC	Two-digit country identifier	00 for all countries
ZZZ	Three-digit city identifier	000 for all cities
P	Peer-type identifier	0 for all peer types
action	0 announce, 1–3 prepend AS5405 that many times, 9 do not announce	None
AAA	Target 32-bit ASN	0 for all ASNs

Each community selects one location (or all locations at that scope), one peer type (or all peer types), and one ASN (or all ASNs). To select several cities, peer types, or ASNs, attach one community for each.

The wildcard identifiers may be used for announcing, AS-path prepending, and propagation restriction. They do not apply to selective RTBH communities.

Announce, prepend, and do-not-announce actions

Large-community pattern	Effect
5405:1RP0:AAA	Announce unmodified toward the selected ASN and peer type within the selected continent
5405:1RP1:AAA	Prepend AS5405 once toward the selected ASN and peer type within the selected continent
5405:1RP2:AAA	Prepend AS5405 twice toward the selected ASN and peer type within the selected continent
5405:1RP3:AAA	Prepend AS5405 three times toward the selected ASN and peer type within the selected continent
5405:1RP9:AAA	Do not advertise toward the selected ASN and peer type within the selected continent
5405:2CCP0:AAA	Announce unmodified toward the selected ASN and peer type within the selected country
5405:2CCP1:AAA	Prepend AS5405 once toward the selected ASN and peer type within the selected country
5405:2CCP2:AAA	Prepend AS5405 twice toward the selected ASN and peer type within the selected country
5405:2CCP3:AAA	Prepend AS5405 three times toward the selected ASN and peer type within the selected country
5405:2CCP9:AAA	Do not advertise toward the selected ASN and peer type within the selected country
5405:3ZZZP0:AAA	Announce unmodified toward the selected ASN and peer type within the selected city
5405:3ZZZP1:AAA	Prepend AS5405 once toward the selected ASN and peer type within the selected city
5405:3ZZZP2:AAA	Prepend AS5405 twice toward the selected ASN and peer type within the selected city
5405:3ZZZP3:AAA	Prepend AS5405 three times toward the selected ASN and peer type within the selected city
5405:3ZZZP9:AAA	Do not advertise toward the selected ASN and peer type within the selected city

Announcing is the default behaviour. The announce action (0) is used to override a broader prepend or do-not-announce instruction, so that the route is advertised unmodified in a specific location, toward a specific peer type, or toward a specific ASN.

No PoP-scoped announce, prepend, or propagation-restriction community is published.

Processing order and precedence

Signalling communities are processed from the least to the most specific. This allows a general rule to be combined with more specific overrides for a location, peer type, or ASN.

• A more specific instruction overrides a less specific one, for example a city instruction overrides a continent instruction that covers the same city.
• Where two instructions have the same reach, the more specific match type takes precedence. A country-scope instruction for all countries takes precedence over a continent-scope instruction for all continents.
• An instruction that selects a specific ASN takes precedence over one that selects only a peer type.
• Where instructions still overlap, announce (0) takes precedence over prepend (1–3), which takes precedence over do not announce (9).

Standard communities honoured by Inter.link

Community	Name	Effect	Reference
65535:0	GRACEFUL_SHUTDOWN	Set local preference to 1	RFC 8326
65535:666	BLACKHOLE	Activate global RTBH	RFC 7999
65535:65281	NO_EXPORT	Do not advertise the route to another ASN	RFC 1997
65535:65282	NO_ADVERTISE	Do not advertise the route beyond the receiving Inter.link PE router	RFC 1997
5405:30	Local-preference reduction	Decrease local preference by 30
5405:50	Local-preference reduction	Decrease local preference by 50

The two local-preference reductions are cumulative. If both communities are attached, local preference is decreased by a total of 80.

The current published catalogue contains no community for increasing local preference.

Remote-triggered blackholing

RTBH may be activated globally or within a published geographic scope. The selective RTBH communities drop traffic only within the selected continent, country, or city; the global community drops traffic everywhere. An announcement is treated as an RTBH route when it carries either the well-known global BLACKHOLE community or one of the selective RTBH communities listed below. The global community should not be combined with a selective RTBH community on the same route.

Community	Effect	Propagated to other networks
65535:666	Global RTBH	Yes, to selected peers and upstreams that support RTBH
5405:666:1R	RTBH within the selected continent	No, except to upstreams supporting an equivalent feature
5405:666:2CC	RTBH within the selected country	No, except to upstreams supporting an equivalent feature
5405:666:3ZZZ	RTBH within the selected city	No, except to upstreams supporting an equivalent feature

An RTBH announcement must pass the applicable AS-path and prefix-length policy. The route must be authorized either by an RPKI Valid state or by coverage under the customer prefix filter. Permitted RTBH prefix lengths are /24 through /32 for IPv4 and /48 through /128 for IPv6.

When a route carrying 65535:666 is re-announced to an upstream, Inter.link may add that upstream’s own RTBH community where the upstream supports one. A host route (IPv4 /32 or IPv6 /128) is generally accepted by networks supporting the well-known BLACKHOLE community. Acceptance of less-specific RTBH routes by another network depends on that network’s routing policy.

If a selective RTBH scope contains the route’s point of ingress, the practical result is a global blackhole. No PoP-scoped selective RTBH community is published.

DDoS redirect community

Community	Effect	Propagated to other networks
65535:700	Divert traffic for the route through Inter.link DDoS scrubbing	No

The DDoS redirect community is available only to customers for whom BGP-community diversion has been enabled as part of the DDoS Protection service. When it is not enabled for the customer BGP session, the community is removed at ingress and has no effect. The DDoS Protection Technical Service Specification describes diversion behaviour.

Unlike 65535:666, this community is not covered by a well-known convention and other networks may use the same value for other purposes, so it is not propagated.

Published examples

Community or combination	Effect
5405:1002:65550	Across all continents and peer types, prepend AS5405 twice toward AS65550
5405:1539:0	In Europe, do not advertise to any IXP peer
5405:21749:0	In Spain, do not advertise to any PNI peer
5405:1039:0	Do not advertise to any IXP peer in any continent
5405:1049:0	Do not advertise to any PNI peer in any continent
5405:1039:0 and 5405:1049:0	Suppress IXP and PNI propagation, producing behaviour equivalent to NOPEER
5405:1009:0 and 5405:1300:0	Advertise only in Asia
5405:20009:0 and 5405:20100:0	Advertise only in Australia
5405:1009:0 and 5405:300300:123	Advertise only in Berlin, and only toward AS123
5405:1502:0 and 5405:301230:0	Prepend AS5405 twice toward all peers in Europe, except IXP peers in London, which receive the route unmodified
5405:666:3003	Apply selective RTBH within Berlin

Community identifier appendix

Peer types

ID (P)	Peer type
0	All peer types (signalling communities only)
1	Customers
2	Transit
3	IXP peering and IXP route servers
4	PNI peering

Continents

ID (R)	Continent
0	All continents (signalling communities only)
1	Africa
2	Antarctica
3	Asia
4	Australia
5	Europe
6	North America
7	Central America
8	South America

Countries

ID (CC)	Country	ID (CC)	Country
00	All countries (signalling communities only)
01	Australia	15	Portugal
02	Austria	16	Singapore
03	China	17	Spain
04	Czechia	18	Sweden
05	Denmark	19	Switzerland
06	Finland	20	United Arab Emirates
07	France	21	United Kingdom of Great Britain and Northern Ireland
08	Germany	22	United States of America
09	Hong Kong	23	Hungary
10	Ireland	24	Slovenia
11	Italy	25	Romania
12	Japan	26	Bulgaria
13	Netherlands	27	Greece
14	Norway

Cities

ID (ZZZ)	City	ID (ZZZ)	City
000	All cities (signalling communities only)
001	Amsterdam	022	Prague
002	Ashburn	023	Seattle
003	Berlin	024	Silicon Valley
004	Copenhagen	025	Singapore
005	Dubai	026	Stockholm
006	Dublin	027	Stuttgart
007	Dusseldorf	028	Sydney
008	Frankfurt	029	Tokyo
009	Helsinki	030	Vienna
010	Hongkong	031	Zurich
011	Lisbon	032	Marseille
012	London	033	Budapest
013	Los Angeles	034	Ahrensburg
014	Madrid	035	Hamburg
015	Miami	036	Reston
016	Milan	037	Ljubljana
017	Munich	038	Bucharest
018	New York	039	Aarhus
019	Nuremberg	040	Skanderborg
020	Oslo	041	Sofia
021	Paris	042	Thessaloniki

Points of presence

ID (SSS)	PoP	ID (SSS)	PoP
001	AMS1-NL	033	PAR1-FR
002	AMS2-NL	034	PRG1-CZ
003	ASH1-US	035	SEA1-US
004	BER1-DE	038	STO1-SE
006	BER2-DE	039	STO2-SE
007	BER3-DE	040	STR1-DE
008	BER4-DE	043	VIE1-AT
014	CPH1-DK	044	VIE2-AT
015	DUB1-IE	045	ZRH1-CH
016	DUS1-DE	047	MRS1-FR
018	FRA1-DE	048	BUD1-HU
019	FRA2-DE	049	AHR1-DE
020	FRA3-DE	050	HAM1-DE
024	LON1-GB	051	RTV1-US
026	MAD1-ES	052	LJU1-SI
028	MIL1-IT	053	BUH1-RO
029	MUC1-DE	054	AAR1-DK
030	NUE1-DE	055	AAR2-DK
031	NYC1-US	056	CPH2-DK
057	CPH3-DK	061	SOF1-BG
058	SKG1-DK	062	SKG1-GR
059	SKG2-DK	069	QAS1-US
060	MUC2-DE

The published numbering is non-contiguous; only the identifiers listed above are defined.

Responsibilities

Activity	Inter.link	Customer
Community handling	Applies origin communities and acts on the documented signalling communities	Sets the communities required for the customer’s intended traffic engineering
RTBH	Applies accepted global or selective blackhole announcements	Announces only authorized RTBH prefixes and selects the intended scope
Verification	Operates the published community facility	Verifies the intended traffic engineering and reports discrepancies through the customer portal

Service levels and support

Availability and performance commitments, incident priorities, response and restoration targets, maintenance rules, exclusions, remedies, and service credits are defined exclusively in the applicable SLA. Nothing in this informative specification changes those terms.