Зашто се ваша BGP сесија не појављује у VPC табели рута

Прича која се понавља јесте да ће рутинг демон на EC2 VPN уређају научити VPC његове удаљене префиксе чим BGP проради. Пола тога је тачно. Сесија проради и ништа се у VPC табели рута због тога не мења, зато је први симптом обично подмрежа која тихо баца саобраћај у црну рупу.

Овде се мешају две различите ствари: пееринг са route server-ом и инсталирање рута у табелу.

Мит: подигните BGP и VPC ће научити префиксе

BGP је разговор између два саговорника, а у овом дизајну саговорници су рутинг демон на вашем уређају и endpoint VPC Route Server-а који AWS поставља у подмрежу коју поседујете. Тај разговор носи префиксе. Он не дира табелу рута ваших радних подмрежа, јер те табеле уче само кроз пропагацију која мора бити омогућена на свакој од њих. Док се то не догоди, VPC ткиво не зна ништа о томе шта уређај зна.

Кораци постављања су одвојени с разлогом: повежите, креирајте endpoint, успоставите пееринг, затим омогућите пропагацију.

Route Server је контролна раван, а не тунел

Route Server не шифрује, не прослеђује и не прегледа ни један пакет. Постоји да размени BGP с уређајем и преда добијене префиксе табелама рута које су конфигурисане да их примају. Раван података је непромењена: пакети и даље излазе кроз мрежни интерфејс уређаја, путују његовим VPN-ом и враћају се истим путем.

То значи да је провера извора и одредишта на инстанци која прослеђује и даље битна, јер инстанца сада прослеђује саобраћај адресиран на неког другог.

Сигурносне групе и контроле подмреже и даље важе за прослеђени ток. Route Server неће натерати уређај који одбацује саобраћај да га проследи, нити ће поправити недостајућу повратну руту на удаљеној страни.

Пропагација је по табели рута, не по VPC-у

Повезивање route server-а с VPC-ом и омогућавање пропагације у табели рута су две одлуке, а само друга мења оно што подмрежа ради. VPC са шест табела рута може примити пропагирани префикс у једној, а не у осталих пет, што је тачно исправно за hub подмрежу и тачно оно што ствара збуњујући резултат «ради напола». Чак и тамо где је пропагација укључена, конкурентна рута може победити, јер VPC избор рута преферира најдужи префикс, а при истој дужини преферира статичку руту над пропагираном. Та преференција се примењује тихо.

Проверите ефективну табелу за конкретну подмрежу, а не листу префикса које уређај објављује. API на то питање одговара директно: aws ec2 associate-route-server и aws ec2 enable-route-server-propagation --route-table-id <id> су два корака која људи забораве, а aws ec2 describe-route-tables --route-table-ids <id> показује да ли је префикс уопште стигао као route server унос.

Уређај и даље носи сваки пакет

Објављивати доступност није исто као имати је. BGP сесија може остати успостављена док је VPN уређаја пао, а статичка објава која се никада не мења стално вуче саобраћај ка мртвом путу. Route Server подржава откривање кварова као што је BFD, али то тестира животност партнера, а не здравље свега иза партнера.

Вежите објаву за стварну удаљену руту: објавите префикс када су тунел и удаљена мрежа горе, и повуците га када нису.

Повуците префикс и гледајте шта се дешава

Тестирајте у фазама, и нека задња фаза буде уклањање. Потврдите да објава стиже, да се префикс појављује у свакој предвиђеној табели, да је уређај следећи хоп, да прослеђивање прелази активни тунел и да удаљена страна одговара. Затим повуците тестни префикс, или затворите одобрени тунел, и посматрајте да ли се саобраћај помера тамо где дизајн каже да треба. Забележите табеле пре и после док је тест још отворен.

Премештање руте на други уређај не премешта сесије које је носила, јер стање NAT-а и firewall-а остаје на првом уређају.

За фиксни скуп од десетак префикса статичке руте у VPC табелама остају јефтинији одговор. Route Server заслужује своје место када се листа префикса заиста мења и када политика повлачења може објаснити особи која је на дежурству.