Laddat upp med en dubbel espresso för nu är det dags att gå över Communities. Vi har i tidigare poster gått igenom hur vi kan påverka routing-beslut i BGP via:
- Weight - Endast lokalt
- Local Preference - Endast inom ett AS/iBGP
- AS_Path Prepending & MED - Skickas till externa AS/eBGP
Gemensamt för både AS_PATH Prepending & MED är dock att din peer/ISP måste acceptera att du skickar dessa attribut, något som är långt ifrån varken best practice eller vanligt förekommande. Oftast väljer istället ISP:n att helt enkelt ignorera dessa attribut från dina routing-uppdateringar om du försöker lägga till detta. 
Tänk dig följande exempel - du som kund har köpt en dual-homed uppkoppling med en primär länk på 100Mbit & backup på 20Mbit. Hur stor tror du risken är att Telia skulle gå in och manuellt modifiera Weight eller Local Preference för dina länkar (alt. låta dig använda MED)? Med 10,000+ kunder så skulle det bli en del route-maps att hålla reda på för dem.. ;) Det är istället här användandet av Communities kommer in i bilden. BGP Communitys är ett 32bitars värde, där i det “nya formatet” (ip bgp-community new-format) delas upp i två 16bitars värde. Best practice är att använda sitt AS-nummer i det första 16bitars fältet, och sedan använda det sista fältet enligt eget önskemål för att skapa sina communitys. Så för en ISP med AS 300 hade dess community-värden exempelvis kunnat vara:
- 300:1
- 300:10
- 300:25000
- 300:60000
Om du istället skulle vilja använda det “gamla formatet” så skrivs hela värdet ut i en och samma 32bitars sträng. 300:10 hade då blivit: 0000 0001 0010 1100 0000 0000 1010 Vilket omskrivet i decimalt blir - 1,228,810. Så vi kan antingen skicka community-taggen 300:10, eller använda oss av det gamla formatet och skicka taggen 1228810 för att få samma effekt- ganska lätt att se vad som är enklast! :) Vi annonserar sedan community-taggen tillsammans med övriga BGP Attribut som Origin/Next hop/AS-Path etc, Community räknas förövrigt som du kanske kommer ihåg från posten “BGP Key Attributes” tidigare i veckan som ett “Optional Attribute”.
Alla routrar har med andra ord inte stöd för detta! Genom communitys kan vi som kund “tagga” våra routing-uppdateringar enligt de värden som vår ISP tagit fram. ISPn kan i sin tur sedan använda en default route-map för alla sina kunder där de matchar Community-värden och ifrån det sätter exempelvis ett förutbestämt Weight eller Local Preference värde. En vanlig lösning verkar vara att ISPn skickar ett excel-blad med alla sina förutbestämda communitys och dess “åtgärder”, något i stil med detta: 
Om vi som kund sedan taggar vårat nät 200.0.0.0/24 med community 300:10 kommer då ISPn att ändra Local Preference till 10. Taggar vi med community 300:201 så kommer ISPn istället att använda AS_Path Prepend och lägga till ytterligare ett AS-hopp. Vi kan även kombinera flera communities om vi så önskar, taggar vi samma route med 300:50 OCH 300:202 så ändras både Local Preference & AS_Path Prepending! Det är ganska lätt att se hur enormt mycket mer skalbart och lättanvänt detta är för vår ISP, alternativet hade ju varit att skapa individuella route-maps för varje kund som önskar någon form av routing-modifiering..
Labbexempel
Vi tar och testar detta i praktiken med ovanstående topologi.
- Länken mellan R1 & R3 är på 50M
- Länken mellan R1 & R4 är på 2M
- Länken mellan R2 & R4 är på 100M
Vi vill således att vår ISP använder länken via R2-R4 primärt för trafik som kommer från “the Internet”. Att modifiera Weight eller AS_Path-Prepending fungerar ej i detta fall, vår ISP måste istället använda Local Preference. Om du inte förstår varför så föreslår jag att du går tillbaka och läser posterna relaterat till detta länkat överst i dedå det är rätt basic vid det här laget. ;) Vår ISP har skickat följande lista med communities vi kan använda oss av: class="img-link shimmer" >
Vi börjar med att konfigurera upp vår egen utrustning så kollar vi senare på hur ISPn hanterar detta. Med ren grundkonfig kan vi se att ISP just nu föredrar den sämre länken via R1 på 50Mbit för att nå nätet 10.0.12.0/24. 
Vi börjar med att konfigurera R1 - men vad är det vi vill åstadkomma? Kom ihåg att för Local Preference så är högst värde bäst (default 100), vi vill med andra ord att ISP ändrar Local Preference till <100 för länken mellan R1 - R3, och sedan sätter ett ännu lägre värde för länken mellan R1 - R4. Enligt excel-listan behöver vi då sätta följande communities:
- Länken mellan R1 - R3 - community 65000:50
- Länken mellan R1 - R4 - community 65000:10
Vi börjar dock med en access-lista:
access-list 1 permit 10.0.12.0 0.0.0.255
Sedan en route-map:
1
2
3
4
5
6
route-map PeerToR3 permit 10
match ip address 1
set community 65000:50
route-map PeerToR4 permit 10
match ip address 1
set community 65000:10
Hur får vi då routern att skicka communities till sina peers? Vi måste först aktivera “bgp-community new format” då vi använt oss av det nya formatet att skriva communities:
ip bgp-community new-format
Vi behöver sedan bara konfigurera följande mot våra peers:
1
2
3
4
5
router bgp 500
neighbor 191.0.0.2 route-map PeerToR3 **out**
neighbor 191.0.0.2 send-community
neighbor 191.0.0.6 route-map PeerToR4 **out**
neighbor 191.0.0.6 send-community
Vi gör i princip samma sak för R2, men här behöver vi egentligen inte ändra LP då vi sänkt de andra länkarna till <100, men det är ju bra träning om inte annat.. :)
1
2
3
4
5
6
7
8
access-list 1 permit 10.0.12.0 0.0.0.255
route-map PeerToR4 permit 10
match ip address 1
set community 65000:110
ip bgp-community new-format
router bgp 500
neighbor 191.0.0.10 route-map PeerToR4 **out**
neighbor 191.0.0.10 send-community
Svårare än så är det inte! Hur har då vår ISP konfigurerat sitt nät? Vi skapar först något som kallas “community-list”, här specificerar vi våra communities så vi sedan kan använda oss av dessa i route-maps:
1
2
3
ip community-list 1 permit 65000:10
ip community-list 2 permit 65000:50
ip community-list 3 permit 65000:110
Dessa fungerar precis som en access-lista och det finns möjlighet att göra både standard & extended-versioner:
1
2
3
4
5
R3(config)#ip community-list ?
<1-99> Community list number (standard)
<100-500> Community list number (expanded)
expanded Add an expanded community-list entry
standard Add a standard community-list entry
Vi skapar sedan en default route-map vi använder till alla våra kunder:
1
2
3
4
5
6
7
8
9
10
route-map CUSTOMER_DEFAULT permit 10
match community 1
set local-preference 10
route-map CUSTOMER_DEFAULT permit 20
match community 2
set local-preference 50
route-map CUSTOMER_DEFAULT permit 30
match community 3
set local-preference 110
route-map CUSTOMER_DEFAULT permit 40
Inget konstigt direkt, istället för match ip address där vi sedan använt oss av en access-lista använder vi här istället match community, vilket hänvisar till den ip community-list vi tidigare skapat.
1
2
3
ip bgp-community new-format
router bgp 65000
neighbor x.x.x.x route-map CUSTOMER_DEFAULT **in**
Detta ger följande resultat:
R3 
R4 
R5 
Vackert! Vi behöver givetvis inte begränsa oss till endast ändra Weight/Local Preference, möjligheterna är rätt rejäla ;)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
R5(config-route-map)#set ?
as-path Prepend string for a BGP AS-path attribute
automatic-tag Automatically compute TAG value
clns OSI summary address
comm-list set BGP community list (for deletion)
community BGP community attribute
dampening Set BGP route flap dampening parameters
default Set default information
extcommunity BGP extended community attribute
interface Output interface
ip IP specific information
ipv6 IPv6 specific information
level Where to import route
local-preference BGP local preference path attribute
metric Metric value for destination routing protocol
metric-type Type of metric for destination routing protocol
mpls-label Set MPLS label for prefix
nlri BGP NLRI type
origin BGP origin code
tag Tag value for destination routing protocol
traffic-index BGP traffic classification number for accounting
vrf Define VRF name
weight BGP weight for routing table
Det får avsluta communities för den här gången, nästa post blir troligtvis om Route-Reflectors eller Confederations.