| 0 comments ]

1. SAVVIS Received BGP Community Attribute Values (BGP community String)

SAVVIS Prepend/Suppression BGP Community Attribute Values (3561:30PPN)

SAVVIS allows customers to control certain traffic flows off-net with the implementation of BGP community attribute values that prepend route/prefix paths with additional AS hops. These BGP community attribute values, which the customer applies, affects the way SAVVIS peers choose the degree of preference of a given prefix/route, because the number of AS hops within the route-path has been lengthened.

The format for the second component of customer route BGP community number (after 3561:) is set at five digits. This fixed length allows regular expressions to be used in applying a defined number of prepends to a given route/prefix path. This format is 3561:30PPN, where the fields are coded in the following way. (Note: The first 2 digits of the second component are always "30" then followed by variables of the "PP" and "N" variables which are defined in the following tables.)The "PP" variable cross references peers of SAVVIS, defined in the following table. (Note, this will always be a two digit value.)

PP Code
Peer Name
Peer AS Number
00
All Peers
-
01
SBC
AS7132
02
Sprint
AS1239
03
Tiscali
AS3257
04
Qwest
AS209
06
Verio/NTT
AS2914
07
Level3
AS3356
08
GlobalCrossing
AS3549
09
FranceTelecom
AS5511
10
WilliamsCommunicationsGroup
AS7911
11
DeutscheTelekomAG
AS3320
12
XOCommunications
AS2828
13
AboveNet/MFN
AS6461
14
UUNet
AS701
15
AT&T
AS7018
18
Cogent
AS174
21
ATDN
AS1668
41
Colt
AS8220
43
Infonet
AS3300
44
UUNet-EU
AS702
46
Telia
AS1299

The "N" variable cross references the number of prepends, defined in the following table. Please note, the only valid "N" value for all peers (PP code 00) is 0 (Do not export).
N Values
"N" Value Meaning
0 Do not export
1 Prepend once
2 Prepend twice
3 Prepend three times
9 Announce-only

Examples:
3561:30030 Do not export this route to PSINet (AS174)
3561:30142 Prepend this route twice, to UUNet (AS701)
3561:30159 Announce this route only to AT&T (AS7018)
SAVVIS Blackhole BGP Community Attribute Values (3561:666)

For customers that have a host or block under a DDoS, the affected host/block can be advertised to AS3561 with BGP community string 3561:666. This will cause all traffic to that host to be black-holed at the core of the AS3561 network. This action will trigger emails sent to the appropriate security and operations groups for notification purposes.
After advertising the prefix with 3561:666, the customer should open a priority one incident report with Client Services:
SAVVIS Support Center (SSC)
Phone: 888-638-6771
Email: ssc@savvis.net

Once the attack has been mitigated, the customer will be responsible for removing the prefix from being advertised.
SAVVIS will not be held responsible for customers who errantly advertise prefixes with the blackhole BGP community string.

SAVVIS Received BGP Community Attribute Values

Value: 3561:70
Definition:
Sets local preference value within AS3561 to "70".
Value: 3561:80
Definition:
Sets local preference value within AS3561 to "80".
Value: 3561:90
Definition:
Sets local preference value within AS3561 to "90".
Value: 3561:no-export or 3561:no-advertise
Definition:
Will prevent the network/prefix tagged with this (either) BGP community attribute from being announced outside AS3561. Note, this will prevent the route from being propagated to SAVVIS eBGP customers receiving a routing table.

2. SAVVIS Announced BGP Community Attribute Values

Formerly, only two SAVVIS BGP community attribute values were announced to users upon request: 3561:900 (customer routes) and 3561:999 (peer routes). These have been replaced by a new BGP community string implementation.
The new implementation allows for a 5 digit string, following the "3561:" notation. Each bit/digit has a pertinent value and meaning represented in the following tables (3561:xxxxx)
This was facilitated to provide the following routing information to customers receiving a routing table from SAVVIS via eBGP routing.
Identification of route source by a. Customer or peer b. Region - Predefined by SAVVIS - Based upon physical connection point c. Country - Predefined by SAVVIS - Based upon physical connection point
The format for the second component of customer route BGP community number (after 3561:) is set at five digits. This fixed length allows regular expressions to be used in routing policy statements to select subsets of customer routes. This format is 3561:SRCCC where the fields are coded in the following way.
"S" refers to 'source' of the route: Source Codes Code Source 1 Customer 2 Peer Example: 3561:1xxxx customer route 3561:2xxxx peer route
"R" defines the region, as specified in Table 3-1. Codes 7 through 0 that are not defined yet and thus available for future region definitions. Since there are only four available region codes left, the definition of each code shall await a need for the function it would provide.
Regional Codes Code Region 1 North America (U.S.A and Canada) 2 Europe 3 Asia (including Japan) 4 Australia 5 South America 6 Middle East 7 Available for future region definitions 8 Available for future region definitions 9 Available for future region definitions 0 Available for future region definitions Example: 3561:11xxx customer, North America 3561:24xxx peer, Australia
"CCC" signifies country code defined by ISO 3166 codes for countries. Note: Peers use a country code of "000".
Blogged with the Flock Browser

| 0 comments ]

Level 3 BGP Communities 

Level 3 (AS3356) does not allow any part of 4.0.0.0/8 to be multihomed. If you are a customer who is currently using address space from 4.0.0.0/8 and if you need to multihome your network to another provider, please contact Level 3 for new address space which can be multihomed.

If you are a provider who has been asked to route a more-specific network block that is part of 4.0.0.0/8, please ask your customer to contact Level 3 to obtain a new network block. Level 3 will not accept advertisements for any networks that are part of 4.0.0.0/8 from any non-customer peer.
Note that the import/export designations above are a simplification of our actual policies which cannot be properly described given the limitations of RPSL
They would also be rather tedious to read if we denoted all of the common policy bits applied to every peer, so we have only noted the peer-specific bits.
We have also only documented our customer peers in this object at this time.


 The following import actions are common to every Level 3 customer peering session:
- RFC1918 and other reserved networks and subnets are not permitted.
- Advertisements with reserved ASes in the path (ie 64512 - 65535) are not permitted.
- Prefixes shorter than /3 or longer than /28 are not permitted.
- Advertisements containing the AS of a network with which we have a non-customer peering relationship are not permitted (ie customers are not allowed to advertise transit for UUnet, CW, etc).
- Advertisements tagged with our own "internal use only" BGP communities (ie the city/country/region/etc BGP communities outlined below) will have all of their BGP communities stripped from them at ingress, and any BGP communities meant to affect localpref, prepending, etc are thus ignored.
- Prefixes not matching the per-peer import policy as documented above are not permitted.
- Localpref will be set to 100 by default, subject to modification based on received BGP communities as outlined below.
- A hard limit is placed on the number of routes a peer is allowed to announce to us. This number is based on their registered routes plus a bit of extra overhead.

The following import actions are common to every Level 3 non-customer peering session:
- RFC1918 and other reserved networks and subnets are not permitted.
- Advertisements with reserved ASes in the path (ie 64512 - 65535) are not permitted.
- Prefixes shorter than /3 or longer than /24 are not permitted.
- Any subnet of any Level 3 CIDR block (as documented in rs-Level3) is not accepted unless routing for the subnet in question has been explicitly requested by the multihomed customer in question.
- Advertisements tagged with our own "internal use" or "customer use" BGP communities (as outlined below) will have all of their BGP communities stripped from them at ingress.
- MEDs are overwritten unless special arrangements have been made.
- Peers who register their routes with meaningful policies may have a prefix filter applied based on this policy.
- Localpref is set to 86 or lower (depending on the nature of the facility over which the peering is taking place and several other factors).
- A hard limit is placed on the number of routes a peer is allowed to announce to us. This number is based on their registered routes or on a historical view of the number of routes they have been advertising plus a bit of extra overhead.

 The following export actions are common to every Level 3 peering session:
- RFC1918 and other reserved networks and subnets are not announced.
- Advertisements with reserved ASes in the path (ie 64512 - 65535) are not announced.
- Prefixes shorter than /3 or longer than /24 are not announced.
- Any subnet of any Level 3 CIDR block (as documented in rs-Level3) is not announced unless routing for the subnet in question has been explicitly requested by the multihomed customer in question.
- Suppression and prepend actions as outlined in the BGP community list below are taken for announcements to non-customer peers.

BGP Communities applied at ingress

--------------------------------------------------------------------------------
prefix type BGP communities
--------------------------------------------------------------------------------

3356:123 - Customer route
3356:666 - Peer route
--------------------------------------------------------------------------------
error type BGP communities
--------------------------------------------------------------------------------

3356:911 - "internal use" BGP communities received from peer
--------------------------------------------------------------------------------
city BGP communities
--------------------------------------------------------------------------------

3356:2001 - CHI - Chicago
3356:2002 - SDG - San Diego
3356:2003 - LAX - Los Angeles
3356:2004 - DEN - Denver
3356:2005 - PHI - Philadelphia
3356:2006 - WDC - Washington DC
3356:2007 - DET - Detroit
3356:2008 - DAL - Dallas
3356:2009 - SFO - San Francisco
3356:2010 - NYC - New York City
3356:2011 - SJO - San Jose
3356:2012 - SEA - Seattle
3356:2013 - ATL - Atlanta
3356:2014 - HOU - Houston
3356:2015 - BOS - Boston
3356:2016 - MIN - Minneapolis
3356:2017 - HON - Honolulu
3356:2018 - WEE - Weehawken
3356:2019 - BAL - Baltimore
3356:2020 - CIN - Cincinnati
3356:2021 - STM - Stamford
3356:2022 - MIA - Miami
3356:2023 - TMP - Tampa
3356:2024 - ORL - Orlando
3356:2025 - STL - St Louis
3356:2026 - PHX - Phoenix
3356:2027 - RCH - Richmond
3356:2028 - MEM - Memphis
3356:2029 - SLC - Salt Lake City
3356:2030 - SAC - Sacramento
3356:2031 - RAL - Raleigh
3356:2032 - SAT - San Antonio
3356:2033 - LVG - Las Vegas
3356:2034 - CLT - Charlotte
3356:2035 - CLE - Cleveland
3356:2036 - OAK - Oakland
3356:2037 - NVL - Nashville
3356:2038 - TUS - Tustin
3356:2039 - NWR - Newark
3356:2064 - LON - London
3356:2065 - FRF - Frankfurt
3356:2066 - PAR - Paris
3356:2067 - AMS - Amsterdam
3356:2068 - BRU - Brussels
3356:2069 - DUS - Dusseldorf
3356:2070 - HAM - Hamburg
3356:2071 - BER - Berlin
3356:2072 - MUN - Munich
3356:2074 - MLN - Milan
3356:2075 - ZUR - Zurich
3356:2076 - STK - Stockholm
3356:2077 - MAD - Madrid
3356:2078 - GEN - Geneva
3356:2079 - MAN - Manchester
3356:2080 - DUB - Dublin
3356:2081 - COP - Copenhagen
3356:2082 - VIE - Vienna
3356:2083 - PRG - Prague
3356:2084 - WAW - Warsaw
--------------------------------------------------------------------------------
country BGP communities
--------------------------------------------------------------------------------

3356:500 - UK
3356:501 - Germany
3356:502 - France
3356:503 - Netherlands
3356:504 - Belgium
3356:505 - Italy
3356:506 - Switzerland
3356:507 - Sweden
3356:508 - Spain
3356:509 - Ireland
3356:510 - Denmark
3356:511 - Austria
3356:512 - Czech Republic
3356:513 - Poland
3356:575 - USA
3356:576 - Canada
--------------------------------------------------------------------------------
regional BGP communities
--------------------------------------------------------------------------------

3356:2 - Europe
3356:3 - North America

BGP Communities accepted from customers


--------------------------------------------------------------------------------
Customer traffic engineering (TE) notes
--------------------------------------------------------------------------------

BGP Communities allow suppress or prepend to peer AS, where
- peer AS has a peering connection to Level 3
- peer AS is not a customer of Level 3
--------------------------------------------------------------------------------
Customer traffic engineering BGP communities - Suppression
--------------------------------------------------------------------------------

64960:XXX - announce to AS XXX if 65000:0
65000:0 - announce to customers but not to peers
65000:XXX - do not announce at peerings to AS XXX
--------------------------------------------------------------------------------
Customer traffic engineering BGP communities - Prepending
--------------------------------------------------------------------------------

65001:0 - prepend once to all peers
65001:XXX - prepend once at peerings to AS XXX
65002:0 - prepend twice to all peers
65002:XXX - prepend twice at peerings to AS XXX
65003:0 - prepend 3x to all peers
65003:XXX - prepend 3x at peerings to AS XXX
65004:0 - prepend 4x to all peers
65004:XXX - prepend 4x at peerings to AS XXX
--------------------------------------------------------------------------------
Customer traffic engineering BGP communities - Regional
--------------------------------------------------------------------------------

Will only work for regional peers
64980:0 - announce to customers but not to EU peers
64981:0 - prepend once to all EU peers
64982:0 - prepend twice to all EU peers
64983:0 - prepend 3x to all EU peers
64984:0 - prepend 4x to all EU peers
--------------------------------------------------------------------------------
Customer traffic engineering BGP communities - LocalPref
--------------------------------------------------------------------------------

3356:70 - set local preference to 70
3356:80 - set local preference to 80
3356:90 - set local preference to 90
--------------------------------------------------------------------------------
Customer traffic engineering BGP communities - Blackhole
--------------------------------------------------------------------------------

3356:9999 - blackhole (discard) traffic

Traffic destined for any prefixes tagged with this
BGP community will be discarded at ingress to the Level 3
network. The prefix must be one permitted by the
customer's existing ingress BGP filter.
Support@Level3.com This e-mail address is being protected from spambots. You need JavaScript enabled to view it  may need to be contacted to allow
in some cases. For some router vendors the peering
must be changed to an eBGP multihop session.
Please contact  support@Level3.com This e-mail address is being protected from spambots. You need JavaScript enabled to view it  with any questions
regarding this functionality.
Blogged with the Flock Browser

| 0 comments ]

Global Crossing (GBLX) allows customer to control their routes announced within GBLX/AS3549 network using bgp community string. These community strings can be used various attributes of their prefixes announced within GBLX network, and can be useful if you are multihomed with another IP transit.
Global Crossing has standard policy applied for its customers and peers.
Customers:
Local preference : 300
Metric policy : Accept customer's metric

Peers:
Local preference : 200
Metric policy : do not accept peers metric
BGP community string that can be used for customers to control routes:

BGP Community String Action
3549:100
set local preference 100
3549:200
set local preference 200
3549:275
set local preference 275
3549:300
set local preference 300
3549:350
set local preference 350

Control Route Propagation
GBLX provides the customer limited control over how their prefixes are propagated to various network peers. This is accomplished using as-path prepending at the GBLX-Peer border. The following BGP communities may be sent to prepend customer announced prefixes:

BGP Community String Action
3549:600
Deny inter-continental export of tagged prefix [iBGP].
3549:666
Deny inter-as export of tagged prefix
(deny to peers, send to customers) [eBGP].
For a limited subset of GBLX peering connections, more granular control of announcements is provided. If GBLX sees a BGP community matching 3549:8..., routing announcements sent to the following listed ASNs will be modified according to these rules :

ASN Peer No Export Prepend +1 Prepend +2 Prepend +3
174
Cogent
8280
8281
8282
8283
209
Qwest
8010
8011
8012
8013
577
Bellnexxia
8090
8091
8092
8093
701
MCI
8030
8031
8032
8033
1239
Sprint
8060
8061
8062
8063
1257
Tele2
8110
8111
8112
8113
1299
TeliaSonera
8250
8251
8252
8253
1668
AOL
8070
8071
8072
8073
2497
JPNIC
8080
8081
8082
8083
2516
KDDI
8100
8101
8102
8103
2828
XO
8260
8261
8262
8263
2914
NTT Verio
8120
8121
8122
8123
3257
Tiscali
8240
8241
8242
8243
3300
InfoNet Europe
8130
8131
8132
8133
3303
Swisscom
8140
8141
8142
8143
3320
DTAG
8150
8151
8152
8153
3356
Level 3
8160
8161
8162
8163
3561
Savvis
8170
8171
8172
8173
4134
ChinaNet
8230
8231
8232
8233
5511
OpenTransit
8190
8191
8192
8193
6453
Teleglobe
8210
8211
8212
8213
6461
AboveNet
8200
8201
8202
8203
6762
Seabone (TI)
8050
8051
8052
8053
6830
UPC/Chello
8180
8181
8182
8183
7018
AT&T (US)
8220
8221
8222
8223
7473
Singtel
8040
8041
8042
8043
7911
Wilcom
8020
8021
8022
8023
12956
Telefonica
8270
8271
8272
8273

Use of GBLX BGP community string will be shown below.
You are multihomed with GBLX and Verizon. You want some prefixes is using your link to Verizon for incoming traffic. This also means that you want GBLX prefer routes from Verizon that from you. As shown above, GBLX give routes form its customer with local preference 300, it will be choosen that form its peers. To have the routes from peers more prefer, you must tagged your routes sends to GBLX with community string that have value lower than default value. In the list above, community string 3549:100 will set the routes with local preference 100, this value is lower than default community for GBLX peers.


Example to set this in Cisco router:
Your prefix that want verizon as incoming is 200.200.200.0/24 and your AS is 100.
You will set prefix-list, route-map, and apply to BGP configuration.
Create prefix-list
router#config t
router(config)#ip prefix-list TO-VERIZON permit 200.200.200.0/24

Create route-map to set community
router#config t
router(config)#route-map SET_COMM permit 10
router(config-route-map)#match ip address prefix-list TO-VERIZON
router(config-route-map)#set community 3549:100
router(config-route-map)#route-map SET_COMM permit 15

Apply route-map at peer to GBLX
router#config t
router(config)#router bgp 100
router(config-router)#neigh 201.201.201.2 remote-as 3549
router(config-router)#neigh 201.201.201.2 send-community both
router(config-router)#neigh 201.201.201.2 route-map SET_COMM out

Then you can check effect of your community in GBLX route server. If it's correct, you will see your prefix have local preference 100.
Blogged with the Flock Browser