Защо BGP сесията не се появява в таблицата с маршрути на VPC

Историята, която се повтаря, е, че демон за маршрутизация на VPN устройство в EC2 ще научи VPC на отдалечените му префикси, щом BGP се вдигне. Половината от това е вярно. Сесията се вдига и нищо в таблицата с маршрути на VPC не се променя заради нея, поради което първият симптом обикновено е подмрежа, която тихо изхвърля трафика в черна дупка.

Тук се бъркат две различни неща: пиъринг със сървър за маршрути и инсталиране на маршрути в таблица.

Мифът: вдигнете BGP и VPC ще научи префиксите

BGP е разговор между двама събеседници, а в този дизайн събеседниците са демонът за маршрутизация на вашето устройство и крайна точка VPC Route Server, която AWS поставя в подмрежа, която притежавате. Този разговор пренася префикси. Той не докосва таблицата с маршрути на вашите работни подмрежи, защото тези таблици се учат само чрез разпространение, което трябва да бъде включено на всяка от тях. Докато това не стане, тъканта на VPC не знае нищо за това, което знае устройството.

Стъпките за настройка са отделни по причина: свързване, създаване на крайната точка, пиъринг, след това включване на разпространението.

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

Route Server не криптира, не препраща и не инспектира нито един пакет. Той съществува, за да обменя BGP с устройството и да предаде получените префикси на таблиците с маршрути, конфигурирани да ги получават. Равнината на данните е непроменена: пакетите все още излизат през мрежовия интерфейс на устройството, пътуват през неговия VPN и се връщат по същия път.

Това означава, че проверката на източника и дестинацията на препращащия инстанс все още е важна, защото инстансът сега препраща трафик, адресиран до някой друг.

Групите за сигурност и контролите на подмрежата също важат за препращания поток. Route Server няма да накара устройство, което изхвърля трафик, да го препраща, и няма да поправи липсващ обратен маршрут от отдалечената страна.

Разпространението е за всяка таблица с маршрути, не за целия VPC

Свързването на сървъра за маршрути с VPC и включването на разпространение в таблица с маршрути са две решения и само второто променя поведението на подмрежата. VPC с шест таблици с маршрути може да получи разпространен префикс в една и да не го получи в останалите пет, което е точно правилното за хъб подмрежа и точно това създава озадачаващия резултат «работи наполовина». Дори когато разпространението е включено, конкурентен маршрут може да спечели, защото изборът на маршрут във 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 и защитната стена остава при първото устройство.

За фиксиран набор от дузина префикси статичните маршрути в таблиците на VPC остават по-евтиният отговор. Route Server заслужава мястото си, когато списъкът с префикси наистина се променя и политиката за оттегляне е нещо, което можете да обясните на дежурния.