Route Servers
Предназначението на Route Servers (RS) е да улеснят процеса по маршрутизиране, така че само с две BGP сесии всеки участник да може да обменя маршрутизираща информация за анонсите на всички други участници.
На схемата е показан само единия от двата Route Serves. RS са два броя, разположени са в различни локации с цел пълна резервираност, и на практика са напълнo идентични.
Схемата илюстрира как функионира Route Server, и по какъв начин чрез него участник (member) B научава мрежа на клиент на участник A (20.10.10.0/24) и когато получи трафик за нея го изпраща през споделената комутираща инфраструктура.
С помощта на BGP Community може да се анонсира така че участника да „дава” трафика на който прецени. Поддържат се следните BGP Community за всеки анонсиран префикс:
|
BGP Community |
Указание към RS |
|
0:MEMBER-AS |
ДА НЕ СЕ АНОНСИРА НА ТОЗИ УЧАСТНИК (MEMBER) |
|
15669:MEMBER-AS |
ДА СЕ АНОНСИРА НА ТОЗИ УЧАСТНИК |
|
0:15669 |
ДА НЕ СЕ АНОНСИРА НА НИКОЙ УЧАСТНИК |
|
15669:15669 |
ДА СЕ АНОНСИРА НА ВСИЧКИ УЧАСТНИЦИ |
Local рreference на ROUTE SERVERS по подразбиране е равен на 100 (сто), като с помощта на BGP Community може да се променя съгласно таблицата:
|
BGP Community |
Указание към RS |
|
15669:65000 |
Local preference* = 0 |
|
15669:65050 |
Local preference* = 50 |
По отношение на входящия трафик (кои анонси да се приемат) контролът е изцяло при участника – той може сам да филтрира при себе си кои от всичките анонси, които е получил от Route Server да приема.
С цел пълно припокриване от функционална гледна точка на Public и Private peering, RS може да премахва собствената си AS от маршрута, който предава на участниците и по този начин те да изглеждат директно свързани без да е необходима частна BGP сесия между тях.
Получените от RS анонси ще се проверяват в RIPE и анонси, които не са надлежно описани няма да се приемат. Това се прави с цел превенция на грешки от анонсиране на префикси, които не могат да бъдат обслужени (пренесени) от съответния участник.
