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 | ДА СЕ АНОНСИРА НА ВСИЧКИ УЧАСТНИЦИ |
BGP Communities за участници с 32-битови AS.
При дефиниране на BGP Community за стойности на „MEMBER-AS” трябва да се използва информацията от долната таблица:
| Участник | AS | BGP Community (MEMBER-AS) |
| InterWorks | 197469 | 64769 |
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 и анонси, които не са надлежно описани няма да се приемат. Това се прави с цел превенция на грешки от анонсиране на префикси, които не могат да бъдат обслужени (пренесени) от съответния участник.
