Orbitel BGP Network Configuration

 

Тема:

 

Чрез този документ се описва конфигурацията на BGP4 рутинга в мрежата на Орбител.

 

 

Идеи:

 

За гъвкаво и скалируемо управление на рутинг информацията се изпозват BGP Community атрибути. Това е транзитивен атрибут, който представлява 32 битово число, като се е прието да се използва формата AS:NUMBER, където AS е автономната система, а NUMBER e произволен номер от 1-65535. Пример: 8672:100

 

Към всеки анонс (prefix) могат да бъдат прикачвани много Community атрибута. Например:

 

BGP routing table entry for 195.24.32.0/19, version 14633450

Paths: (1 available, best #1)

Advertised to peer-groups:

ebone-client

5511 8866 8866 8672

195.158.238.174 (metric 14) from 213.174.64.2 (213.174.64.2)

Origin IGP, localpref 100, valid, internal, best

Community: 1755:130 1755:666 1755:1000 1755:2000

 

По този начин всеки анонс може да бъде маркиран със съответен номер. Така филтрирането става много лесно чрез използването на community-list в Cisco.

 

 

Реализация:

 

Всички community номера използвани в мрежата на Орбител имат като старши 16 бита автономната система на Орбител: 8672.

 

Дефиниция на номерата използвани за маркиране на входящите анонси:

 

Community Дефиниция Забележка

---------------------------------------------------------------------------------------------------------------

8672:100 Анонси получени от транзитни доставчици

8672:101 Анонси получени от SPnet

8672:102 Анонси получени от Magyar

8672:103 Анонси получени от OTE

 

8672:200 Анонси получени от peering с други доставчици

8672:201 Анонси получени от TPN

8672:202 Анонси получени от Spnet

8672:203 Анонси получени от Mobikom

8672:204 Анонси получени от Prolink

8672:205 Анонси получени от Mobiltel

8672:206 Анонси получени от Digsys

8672:207 Анонси получени от Netissat

8672:208 Анонси получени от BIAnet

8672:209 Анонси получени от ITDnet

8672:2010 Анонси получени от Lirex

8672:2011 Анонси получени от dir.bg

8672:2012 Анонси получени от top.bg

8672:2013 Анонси получени от bol.bg

8672:2014 Анонси получени от InterBGC

8672:2015 Анонси получени от headoff

8672:2016 Анонси получени от evro.net

8672:2017 Анонси получени от Neterra

8672:2018 Анонси получени от data.bg

8672:2019 Анонси получени от Министерски съвет

8672:2020 Анонси получени от online.bg

 

 

 

8672:300 Анонси получени от клиенти

 

Дефиниция на номерата използвани за установяване на политика отностно анонсирането на получен prefix. По подразбиране prefix-а се анонсира навсякъде.

 

Community Дефиниция Забележка

------------------------------------------------------------------------------------------------------------------------------

8672:1000 Не се анонсира към външни доставчици

8672:1001 Не се анонсира към SPnet

8672:1002 Не се анонсира към Magyar

8672:1003 Не се анонсира към OTE

 

8672:1100 Prepend-ва се към външни доставчици

8672:1101 Prepend-ва се към SPnet

8672:1102 Prepend-ва се към Magyar

8672:1103 Prepend-ва се към OTE

 

8672:1200 Prepend-ва се много към външни доставчици

8672:1201 Prepend-ва се много към SPnet

8672:1202 Prepend-ва се много към Magyar

8672:1203 Prepend-ва се много към OTE

 

8672:1300 Не се prepend-ва към външни доставчици

8672:1301 Не се prepend-ва към SPnet

8672:1302 Не се prepend-ва към Magyar

8672:1303 Не се prepend-ва към OTE

 

 

8672:2000 Не се анонсира към peering-ите

8672:2001 Не се анонсира към TPN

8672:2002 Не се анонсира към Spnet

8672:2003 Не се анонсира към Mobikom

8672:2004 Не се анонсира към Prolink

8672:2005 Не се анонсира към Mobiltel

8672:2006 Не се анонсира към Digsys

8672:2007 Не се анонсира към Netissat

8672:2008 Не се анонсира към BIAnet

8672:2009 Не се анонсира към ITDnet

8672:2010 Не се анонсира към Lirex

8672:2011 Не се анонсира към dir.bg

8672:2012 Не се анонсира към top.bg

8672:2013 Не се анонсира към bol.bg

8672:2014 Не се анонсира към InterBGC

8672:2015 Не се анонсира към headoff

8672:2016 Не се анонсира към evro.net

8672:2017 Не се анонсира към Neterra

8672:2018 Не се анонсира към data.bg

8672:2019 Не се анонсира към Министерски съвет

8672:2020 Не се анонсира към online.bg

 

 

8672:2100 Prepend-ва се към peering-ите

8672:2101 Prepend-ва се към TPN

8672:2102 Prepend-ва се към Spnet

8672:2103 Prepend-ва се към Mobikom

8672:2104 Prepend-ва се към Prolink

8672:2105 Prepend-ва се към Mobiltel

8672:2106 Prepend-ва се към Digsys

8672:2107 Prepend-ва се към Netissat

8672:2108 Prepend-ва се към BIAnet

8672:2109 Prepend-ва се към ITDnet

8672:2110 Prepend-ва се към Lirex

8672:2111 Prepend-ва се към dir.bg

8672:2112 Prepend-ва се към top.bg

8672:2113 Prepend-ва се към bol.bg

8672:2114 Prepend-ва се към InterBGC

8672:2115 Prepend-ва се към headoff

8672:2116 Prepend-ва се към evro.net

8672:2117 Prepend-ва се към Neterra

8672:2118 Prepend-ва се към data.bg

8672:2119 Prepend-ва се към Министерски съвет

8672:2120 Prepend-ва се към online.bg

 

 

Конфигурации за Cisco реализиращи филтрацията спрямо дефинираните community-та.

 

За реалицацията се използват т.нар. route-map. Това са набор от правила изпълнявани последователно, като всяко правило се състои от две части: match (сравнение) и set (установяване). За повече подробности можете да прочетете в книгата на Basam Halabi - Internet Routing Architectures или на http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt2/1cdindep.htm#xtocid256868

 

 

Route-map поставян на входа на peering връзките:

 

route-map <peer-name>.in permit 100

set community 8672:200 8672:<peer-number>

set local-preference 200

 

Route-map поставян на входа на клиентските връзките:

 

route-map <customer-name>.in permit 100

set community 8672:300

set local-preference 300

 

Route-map поставян на входа на транзитни доставчици (БТК, UUnet):

 

route-map <provier-name>.in permit 100

set community 8672:100 8672:<provider-number> 8672:2000

 

 

 

Route-map поставян на изхода към транзитни доставчици (БТК, UUnet):

 

route-map <provider-name>.out deny 100

match community-list 100

match community-list 101

route-map <provider-name>.out permit 200

match community-list 110

match community-list 111

set as-path prepend 8672

 

 

! Match no-transit and peering based

ip community-list 100 permit 8672:1000

ip community-list 100 permit 8672:200

 

! Match no-transit BTC

ip community-list 101 permit 8672:101

 

! Match no-transit UUnet

ip community-list 102 permit 8672:102

 

! Match prepend to transit ISPs

ip community-list 110 permit 8672:1100

! Match prepend to BTC

ip community-list 111 permit 8672:1101

 

 

Route-map поставян на изхода към peering доставчик:

 

route-map <provider-name>.out deny 100

match community-list 150

match community-list 151

route-map <provider-name>.out permit 200

match community-list 170

match community-list 171

set as-path prepend 8672

 

 

ip community-list 150 permit 8672:2000

ip community-list 150 permit 8672:100

 

ip community-list 151 permit 8672:2001 ! providers' number

 

ip community-list 170 permit 8672:2100

 

ip community-list 171 permit 8672:2101

 

 

Допълнителни настройки.

 

Гореописаните route-map-ове могат да се считат за шаблони. Те могат да бъдат допълвани с цел финна настройка на анонсите. Пример: ако не желаем да анонсираме prefix-ите получени от Мобилтел, тогава на входа на bgp сесията с тях можем да добавим следния ред към route-map-a с тях:

 

route-map mobiltel.in permit 100

set community 8672:200 8672:205 8672:2000

set local-preference 200

 

Принципът, който се следва, е: Промени по route-map-овете се правят на входната за автономната система точка.