Статичке руте или протокол рутирања преко VPN-а од локације до локације?
Променљивост префикса, понашање при пребацивању и оперативна спремност одлучују. Одмерите колико кошта одржавање сваке опције исправном, па тестирајте путању отказа.
Обе опције преносе пакете између локација, па одлука није о томе који је протокол новији, а ни величина тунела је не решава. Решавају је три услова: колико се префикса мења и колико често, да ли пројекту треба аутоматски прелаз између путања, и колико механизама контролног слоја тим може да одржава у три сата ујутру. Одговорите на то искрено и избор се обично сам наметне. Остатак овог текста је шта сваки одговор кошта.
Три услова одлучују
Први услов је променљивост. Неколико стабилних подмрежа са јасним власништвом може годинама да се одржава ручно, а свака рута остаје ред који неко може да прочита и провери. Десетине префикса који се селе како пројекти долазе и одлазе други су проблем, јер сваки прелаз мора да стигне до сваког уређаја који још памти стари пут.
Други је понашање при отказу. Када резервна путања мора да постане активна без тога да то човек примети, нешто мора да открије отказ и повуче руту. Статичко рутирање то може само праћењем или условном инсталацијом, и то само за отказе које сте унапред предвидели.
Трећи је апетит за другим контролним слојем. Протокол рутирања додаје сесије, аутентификацију, филтере и политику избора, а свако од тога тражи надзор и процес промена. То је трајни оперативни трошак, а не једнократни задатак конфигурације.
| Condition | Points to static | Points to dynamic |
|---|---|---|
| Prefix churn | Rare, few, stable | Frequent, many, moving |
| Failover | Manual or tracked | Automatic withdrawal |
| Operations | No routing staff | Protocol monitoring exists |
Табела испод трећег пасуса је кратка верзија, а три одељка након ње објашњавају зашто сваки ред стоји тамо где стоји. Читајте редове према свом броју локација пре избора, јер одлука која занемарује оперативни трошак само је пола одлуке.
Колико статичко рутирање заиста кошта
Статичка рута мора да буде тачна са обе стране тунела. Додавање подмреже значи уређивање удаљеног пролаза, локалног пролаза и обично повратне путање, а заборављање било ког од њих даје једносмерни отказ који изгледа као грешка у апликацији. Апликацијски тим види истеке времена, док мрежни тим види руту која постоји и наизглед је здрава. Ниједан тим није у криву, и зато је овај отказ тако тешко сместити.
Статички запис такође остаје инсталиран након што путања испод њега нестане. Ако платформа не нуди праћење, рута наставља да показује на следећи скок који више не прослеђује, а саобраћај нестаје уместо да се пребаци. Та тишина је трошак који прихватате када бирате једноставну опцију.
Упишите метод праћења уз сваку руту, забележите које отказе покрива и држите списак уз конфигурацију тунела. Иначе следећи прекид открије корисник, а не мрежа, што је увек скупље откриће.
Колико динамичко рутирање заиста кошта
Протокол оглашава нове префиксе, повлачи недоступне и изражава преференцију између путања. То је истински корисно када би неколико локација или редундантни тунели иначе тражили усклађене измене при свакој промени. То је и разлог зашто вас протокол може изненадити у најгорем тренутку. Свака од тих радњи је промена стања коју нисте сами направили.
Он ствара два стања која могу да се разилазе. Тунел може да буде подигнут док је сесија рутирања спуштена, а сесија може да буде подигнута док њена оглашавања изостављају подмрежу која треба апликацији. Оба изгледају као мрежа која ради на пола, а ниједно се не види са странице стања тунела.
Филтери и политика зато постају део пројекта, а не накнадна мисао. Протокол који оглашава све на крају ће огласити нешто погрешно, а погрешан префикс путује брже од особе која може да га исправи. Напишите филтере пре него што се прва сесија омогући, да прво оглашавање већ буде намерно.
Контролишите шта сесија рутирања сме да каже
Одредите дозвољени списак префикса по peer-у и примените га на улазу, јер излазни филтер не може да спречи peer да вам пошаље подразумевану руту. Подразумеване руте и агрегати су скупе грешке овде: могу тихо да замене неповезане путање једним наученим записом који изгледа легитимно. Одбијте их изричито, осим ако пројекат то заиста жели.
Упишите локацију власника уз сваку мрежу пре него што се прва сесија подигне, јер је то мапирање извор списка филтера, а не украс документације. Без тога особа која уређује филтер мора да нагађа која локација треба да оглашава префикс.
Редистрибуција између два протокола је место где петље почињу и где исти префикс стиже двапут са атрибутима који се не пореде чисто. Држите редистрибуцију изван пројекта док је конкретан захтев не наметне, а ако мора да постоји, означите и филтрирајте руте на граници.
Тунелски интерфејси засновани на рутама чине динамичко рутирање лакшим за приказ, јер тунел постаје интерфејс са рутама уместо политике која упарује селекторе. То не уклања питање опсега peer-а: IPsec селектори и даље морају да дозволе саобраћај који намеравате да рутирате.
Тестирајте путању отказа, а не срећну путању
Шта год изабрали, спустите једну узлазну везу и потврдите да се саобраћај помера или да пада на начин који сте документовали. Пројекат тестиран само са обе здраве путање пројекат је који уопште није тестиран. Измерите време откривања док сте тамо, јер број који сте измерили је број који ће корисници осетити.
Затим независно потврдите повратну путању, јер је асиметрично рутирање преко VPN-а уобичајено и невидљиво док уређај који чува стање не одбаци одговоре. Ток који ради у једном смеру доказује само пола пута.
Редослед рада: пребројте префиксе, одлучите како треба откривати отказе, проверите ко може да одржава протокол, контролишите шта се оглашава, па тестирајте један прекид од почетка до краја. Сваки корак даје чињеницу која треба следећем.