Extreme IX BGP Communities and Configuration Guide

Extreme IX Route Servers remove the need for individual bilateral BGP sessions between members. Use BGP communities to control how the Route Servers propagate your routes to other peers.

Route Server behavior: AS-path hiding

Extreme IX Route Servers (RS) do not prepend or include their own Autonomous System Number (ASN) in the AS_PATH attribute. This removes the RS AS from the path, so participating members appear directly connected without requiring individual bilateral BGP sessions between each member network.

Disable the first-AS check

Because the Route Server hides its ASN, some BGP router implementations discard incoming updates from eBGP peers by default if the peer’s ASN does not appear first in the AS_PATH. Disable this check on your router when you peer with Extreme IX Route Servers:

Cisco — no bgp enforce-first-as or bgp enforce-first-as disable
Huawei — undo check-first-as under the BGP context
Fortinet — set enforce-first-as disable

BGP community controls

All members peering with Extreme IX Route Servers can use communities to control incoming and outgoing route propagation.

Incoming traffic control — Managed on the member side. You control which prefixes received from the Route Server are accepted into your routing table.
Outgoing traffic control — Use BGP communities to control which peers receive your announced prefixes through the Route Server.

Do not mix standard communities with large communities in the same policy. Choose one format for your configuration.

Standard BGP communities

Communities originated from the Extreme IX RS:

0:peer AS — The prefix is announced from peer AS.

Standard communities accepted by the Extreme IX RS:

49378:0 — Block your prefix to all peers.
49378:0 49378:ASPEER — Block your prefix to all peers except ASPEER.
49378:ASPEER — Block your prefix to ASPEER.

Large BGP communities

Announcement control:

49378:0:0 — Block your prefix to all peers.
49378:1:ASPEER — Announce a route to a specific ASPEER.
49378:0:ASPEER — Prevent announcement of a prefix to an ASPEER.

For the full list of AS mappings and technical requirements, see the Extreme IX Technical Requirements page. Large BGP communities also let you prepend your prefixes to a specific Route Server member while advertising to the rest of the peers without prepends:

49378:101:ASPEER — Prepend to ASPEER once.
49378:102:ASPEER — Prepend to ASPEER twice.
49378:103:ASPEER — Prepend to ASPEER three times.

For example, attaching 49378:103:ASN1 prepends your prefixes to ASN1 three times, while advertising to the rest of the members without prepends.

Operational notices

IPv6 Router Advertisements (RA) are ICMPv6 NDP messages required for LAN/SLAAC environments. They have no use case for point-to-point (PtP) links, inter-AS links, IP transit, PNI, and IXP LAN connectivity. Confirm that these default behaviors are disabled on your network devices. For information about how to disable IPv6 RA per vendor, and why this matters, see this article.

Vendor configuration examples

The following examples show how to manage route propagation to and from specific BGP peers through the Route Server (RS) using BGP communities (ASN 49378).

Scenario 1: block specific BGP peers through the Route Server

Use these configurations to block receiving prefixes from specific target Autonomous Systems (AS: xxx, AS: yyy) and prevent sending your routes to them.

Deny received routes matching the targeted AS in the inbound filter, then accept the remaining routes. Attach the control community to every prefix pool you advertise toward the Route Server.

# BGP Peer Configuration
peer <RS-IP> as-number <RS-ASN>
#
ipv4-family unicast
 peer <RS-IP> enable
 peer <RS-IP> route-policy MyPool-IN import
 peer <RS-IP> route-policy MyPool-OUT export
 peer <RS-IP> advertise-community
#
# Define Local Prefixes
ip ip-prefix MyPool index 10 permit x.x.x.x 24
ip ip-prefix MyPool index 15 permit x.x.x.x 24
#
# Outbound Route Policy (Do not advertise to AS xxx, yyy)
route-policy MyPool-OUT permit node 10
 if-match ip-prefix MyPool
 apply community 49378:xxx 49378:yyy additive
#
# Inbound Route Policy (Block routes from AS xxx, yyy)
route-policy MyPool-IN deny node 10
 if-match community-filter 11 12
route-policy MyPool-IN permit node 20
#
# Community Filters
ip community-filter 11 permit 0:xxx
ip community-filter 12 permit 0:yyy

! BGP Peer Configuration
neighbor <RS-IP> remote-as <RS-ASN>
neighbor <RS-IP> route-map MyPool-IN in
neighbor <RS-IP> route-map MyPool-OUT out
neighbor <RS-IP> send-community
!
! Define Local Prefixes
ip prefix-list MyPool seq 10 permit x.x.x.x/22 le 24
!
! Outbound Route Map
route-map MyPool-OUT permit 10
 match ip address prefix-list MyPool
 set community 49378:xxx 49378:yyy additive
!
! Inbound Route Map
route-map MyPool-IN deny 10
 match community filter
!
route-map MyPool-IN permit 20
!
! Community List Definition
ip community-list standard filter permit 0:xxx
ip community-list standard filter permit 0:yyy

# BGP Protocol Setup
set protocols bgp group to_EIX type external
set protocols bgp group to_EIX import inbound-routes-EIX
set protocols bgp group to_EIX export outbound-routes-EIX
set protocols bgp group to_EIX neighbor 103.77.108.200 peer-as 49378

# Prefix List Definition
set policy-options prefix-list EIX-Download-PREFIX x.x.x.x/24

# Outbound Policy Statement
set policy-options policy-statement outbound-routes-EIX term OUT from prefix-list EIX-Download-PREFIX
set policy-options policy-statement outbound-routes-EIX term OUT then community add COMMUNITY_out
set policy-options policy-statement outbound-routes-EIX term OUT then accept
set policy-options policy-statement outbound-routes-EIX term LAST then reject

# Inbound Policy Statement
set policy-options policy-statement inbound-routes-EIX term Block-COMMUNITY from community COMMUNITY_in
set policy-options policy-statement inbound-routes-EIX term Block-COMMUNITY then reject
set policy-options policy-statement inbound-routes-EIX term EIX-UPLOAD from protocol bgp
set policy-options policy-statement inbound-routes-EIX term EIX-UPLOAD then local-preference xx
set policy-options policy-statement inbound-routes-EIX term EIX-UPLOAD then accept

# Community Definitions
set policy-options community COMMUNITY_out members [ 49378:xxx 49378:yyy ]
set policy-options community COMMUNITY_in members [ 0:xxx 0:yyy ]

/routing filter
add action=discard chain=EIX-RS-IN bgp-communities=0:xxx
add action=discard chain=EIX-RS-IN bgp-communities=0:yyy
add action=accept chain=EIX-RS-IN

add action=accept chain=EIX-RS-OUT prefix=<YOUR_PREFIX> set-bgp-communities=49378:xxx,49378:yyy

/routing filter rule
add chain=Extreme-RS-in disabled=no rule="if (bgp-communities equal 0:xxx) { reject }"
add chain=Extreme-RS-in disabled=no rule="if (bgp-communities equal 0:yyy) { reject }"
add chain=Extreme-RS-in disabled=no rule="accept"

add chain=Extreme-RS-out disabled=no rule="if (dst==x.x.x.x/24) { set bgp-communities 49378:xxx,49378:yyy; accept }"
add chain=Extreme-RS-out disabled=no rule="reject"

For Route Server members using 32-bit ASNs, see the Extreme IX Technical Requirements page for the mapped short community values, so you avoid using BGP extended communities.

Scenario 2: allow selective peers only, and block all others

Use these configurations to block route exchange with all members by default, and allow route exchange only with specific target networks — for example, Google (AS15169) and Akamai (AS20940).

/routing filter
# Outbound: Block advertise to all (49378:0), permit only Akamai & Google
add action=accept chain=EIX-RS-OUT prefix=<YOUR_PREFIX_1> set-bgp-communities=49378:0,49378:20940,49378:15169
add action=accept chain=EIX-RS-OUT prefix=<YOUR_PREFIX_2> set-bgp-communities=49378:0,49378:20940,49378:15169
add action=discard chain=EIX-RS-OUT

# Inbound: Accept only Akamai & Google routes, discard all others
add action=accept chain=EIX-RS-IN bgp-communities=0:20940
add action=accept chain=EIX-RS-IN bgp-communities=0:15169
add action=discard chain=EIX-RS-IN

/routing filter rule
# Inbound Filter
add chain=Extreme-RS-in disabled=no rule="if (bgp-communities equal 0:20940) { accept }"
add chain=Extreme-RS-in disabled=no rule="if (bgp-communities equal 0:15169) { accept }"
add chain=Extreme-RS-in disabled=no rule="reject"

# Outbound Filter
add chain=Extreme-RS-out disabled=no rule="if (dst==x.x.x.x/24) { set bgp-communities 49378:0,49378:20940,49378:15169; accept }"
add chain=Extreme-RS-out disabled=no rule="reject"

The following example establishes dual Route Server sessions (primary and secondary) on Huawei, accepting prefixes exclusively from Akamai (AS20940) and blocking all others.

peer 45.120.248.200 as-number 49378
#
ipv4-family unicast
 peer 45.120.248.200 enable
 peer 45.120.248.200 route-policy MyPool-IN import
 peer 45.120.248.200 route-policy MyPool-OUT export
 peer 45.120.248.200 advertise-community
#
ip ip-prefix MyPool index 10 permit x.x.x.x 24
ip ip-prefix MyPool index 15 permit x.x.x.x 24
#
# Outbound: Block all peers (49378:0), permit Akamai (49378:20940)
route-policy MyPool-OUT permit node 10
 if-match ip-prefix MyPool
 apply community 49378:0 49378:20940 additive
#
# Inbound: Accept Akamai (0:20940), deny all others
route-policy MyPool-IN permit node 10
 if-match community-filter 11
route-policy MyPool-IN deny node 20
#
ip community-filter 11 permit 0:20940

peer 45.120.248.240 as-number 49378
#
ipv4-family unicast
 peer 45.120.248.240 enable
 peer 45.120.248.240 route-policy MyPool-IN import
 peer 45.120.248.240 route-policy MyPool-OUT export
 peer 45.120.248.240 advertise-community
#
ip ip-prefix MyPool index 10 permit x.x.x.x 24
ip ip-prefix MyPool index 15 permit x.x.x.x 24
#
route-policy MyPool-OUT permit node 10
 if-match ip-prefix MyPool
 apply community 49378:0 49378:20940 additive
#
route-policy MyPool-IN permit node 10
 if-match community-filter 11
route-policy MyPool-IN deny node 20
#
ip community-filter 11 permit 0:20940

​Route Server behavior: AS-path hiding

​Disable the first-AS check

​BGP community controls

​Standard BGP communities

​Large BGP communities

​Operational notices

​Vendor configuration examples

​Scenario 1: block specific BGP peers through the Route Server

​Scenario 2: allow selective peers only, and block all others

Route Server behavior: AS-path hiding

Disable the first-AS check

BGP community controls

Standard BGP communities

Large BGP communities

Operational notices

Vendor configuration examples

Scenario 1: block specific BGP peers through the Route Server

Scenario 2: allow selective peers only, and block all others