Operational BGP Communities

Operational BGP Communities can be used to control various functions of the route server. With this communities, you can:

  • control the redistribution of advertised prefixes
  • prepend your own AS up to three times
  • trigger the calculation of a new alternate path (if available) for your advertised prefixes before you start commencing a maintenance

Please note that if the $PEERAS is a four byte AS number you have to use the BGP Extended or Large Communities.

All BGP community examples on this page are based on DE-CIX Frankfurt (AS6695).
If you want to use BGP Communities at one of the other exchanges, please replace all occurrences of "6695" with the AS of the exchange:

IX AS
Frankfurt 6695
Hamburg 43252
Munich 47228
Dusseldorf 56890
New York 63034
Dallas 62499
Marseille 20717
Palermo 25083
Madrid 48793
Istanbul 20715

Control of prefix redistribution

You can control which BGP announcements you send to the route servers are redistributed to other peers. In fact, you can also control which peer / AS receives which BGP announcements you send to the route servers. For this, BGP Communities, BGP Extended Communities and BGP Large Communities can be used.

The following BGP Communities are supported:

ActionBGP Standard Community (RFC 1997)   BGP Extended Community (RFC 4360)  BGP Large Community (RFC 8092) 
Do not redistribute0:6695  rt:0:6695  6695:0:0 
Do not Redistribute to $PEERAS0:$PEER-AS  rt:0:$PEER-AS  6695:0:PEERAS 
Redistribute to $PEERAS
(in combination with 0:6695)
6695:$PEER-AS   rt:6695:$PEER-AS  6695:1:$PEERAS 
Redistribute to all (default)6695:6695  rt:6695:6695  6695:1:0 


The same is true for every occurrence of "6695" on this page: Insert the AS of the IX where you want to use the communities. The examples and descriptions are based on Frankfurt.

The route servers remove the aforementioned BGP Communities and BGP Extended Communities from a BGP announcement before re-distributing it.

The well-known BGP Communities NO-EXPORT (65535:65281) and NO-ADVERTISE (65535:65282) are also honored meaning that a BGP announcement marked by one of these communities is not re-distributed to any peer. If you want the route server system to add a NO-EXPORT or NO-ADVERTISE community for a given BGP announcement before re-distributing, you have to add the community (6695:65281) or (6695:65282) respectively. This is also possible on a per-peer basis using BGP Large Communities: (6695:901:$PEERAS) for selective NO-EXPORT and (6695:902:$PEERAS) for selective NO-ADVERTISE. 

More than one of the aforementioned BGP Communities and BGP Extended Communities can be added to a single BGP announcement. DE-CIX recommends not to add more than 50 of these communities as it makes handling complex and error-prone. If you need to do this, please contact Customer Service. The following table lists the evaluation order of the different BGP Communities and BGP Extended Communities which helps to build complex filter rules. In case two or more BGP (extended) Communities are contradicting the community with the lowest evaluation order wins.

Evaluation orderCommunity
1.NO-EXPORT (65535:65281)

NO-ADVERTISE (65535:65282)
2.0:$PEER-AS

rt:0:$PEER-AS

6695:0:$PEERAS
3.6695:$PEER-AS

rt:6695:$PEER-AS

6695:1:$PEERAS
4.0:6695
5.6695:6695


All BGP Communities and BGP Extended Communities that are not listed above are not touched by the route servers and transparently re-distributed. For backwards compatibility, routes with no community at all are distributed to all peers as well.

You can obtain a list of BGP announcements received from a peer by entering the peer's IP address in the "neighbor info" tab of the DE-CIX looking glass.

How the different communities can be used

Examples for Frankfurt

BGP announcements marked with the following communities are only re-distributed to AS64501 and AS64502 (both 2 Byte ASNs):

  • (0:6695)
  • (6695:64501)
  • (6695:64502)

BGP announcements marked with the following communities are re-distributed to all peers/ ASNs except AS64501 and AS64502:

  • (0:64501)
  • (0:64502)
  • (6695:6695)

BGP announcements tagged with the following communities are only re-distributed to AS65550 (4 Byte ASN) and AS64501 (2 Byte ASN):

  • (0:6695)
  • (rt:6695:65550)
  • (6695:64501)

AS Path Prepending

You can use BGP communities to prepend your own ASN up to three times. This can be done to all other peers or selective to only certain peers.

BGP Standard Communities:
Prepend your ASN to all peers once: 65001:0
Prepend your ASN to all peers twice: 65002:0
Prepend your ASN to all peers three times: 65003:0

Prepend your ASN to $PEERAS once: 65001:$PEERAS
Prepend your ASN to $PEERAS twice: 65002:$PEERAS
Prepend your ASN to $PEERAS three times: 65003:$PEERAS

BGP Extended Communities:
Prepend your ASN to $PEERAS once: rt:65001:$PEERAS
Prepend your ASN to $PEERAS twice: rt:65002:$PEERAS
Prepend your ASN to $PEERAS three times: rt:65003:$PEERAS

BGP Large Communities:
Prepend your ASN to all peers once: 6695:101:0
Prepend your ASN to all peers twice: 6695:102:0
Prepend your ASN to all peers three times: 6695:103:0

Prepend your ASN to $PEERAS once: 6695:101:$PEERAS
Prepend your ASN to $PEERAS twice: 6695:102:$PEERAS
Prepend your ASN to $PEERAS three times: 6695:103:$PEERAS

Graceful BGP Session Shutdown

The DE-CIX route servers support RFC 8326 (Graceful BGP Session Shutdown). With this well-known BGP Community, you can instruct the route servers to calculate and redistribute an alternate path (if available) for your advertised prefixes before you start commencing your maintenance. This makes sure that routers of other customers have fully converged before you interrupt L2 connectivity and thereby so called micro blackholing is prevented.

Details:

  • Setting BGP Community GRACEFUL_SHUTDOWN (65535:0) on all you advertised prefixes. The route server will set BGP local preference to 0 for these prefixes.
  • The route server will calculate alternative paths for your advertised prefixes (if available) and redistribute these to other peers. Prefixes with no alternative path will get redistributed with BGP Community GRACEFUL_SHUTDOWN
  • You should also apply GRACEFUL_SHUTDOWN on the inbound policy of you eBGP session
  • After convergence has completed, you can safely shut down the BGP session. At this point, routers of other customers have learned alternative paths for your prefixes (if available) from the route server and forward traffic on the new path

  Graceful BGP Session Shutdown