Од RIP руте на CE до удаљеног VRF-а: где се извршава export

RIPv2 update стиже на provider edge, упада у VRF routing табелу и ту се зауставља осим ако га нешто изричито не export-ује. Три одлуке се дешавају редом и свака може да одбије префикс из сопственог разлога. Читање њих као једног догађаја разлог је зашто људи траже грешку на погрешном уређају када удаљена локација не може да достигне мрежу коју CE јасно оглашава. Пратите руту кроз PE и редослед постаје очигледан.

Шта PE ради са RIP update-ом

PE прима update на VRF интерфејсу, проверава да је извор дозвољен сусед и инсталира префикс у VRF routing табелу са бројем хопова изведеним из огласа. Та табела је обична routing табела са сопственим административним дистанцама и сопственим избором најбоље путање. Ако CE исти префикс огласи двапут са различитим метрикама, у табели преживи само бољи. Ништа у овом кораку не укључује backbone провајдера.

Префикс сада постоји унутар routing контекста једног клијента, што је далеко од тога да буде доступан било где другде.

Export је политички чин, а не последица протокола

Да би напустила VRF, рута мора бити редистрибуирана у MP-BGP процес који носи VPN руте и потребан јој је route target extended community који одређује који удаљени VRF-ови могу да је import-ују. Архитектура у RFC 4364 држи те размене одвојене од CE-PE протокола управо због тога. Коришћење RIP-а на ивици не говори ништа о томе шта би требало да пређе мрежу провајдера.

Запишите export уговор пре него што било шта конфигуришете: клијентске префиксе који морају бити доступни на даљину, руте које морају остати локалне и све default руте, специфичније руте или изузетке за дељене сервисе. Упоредите тај уговор са стварним VRF-ом, а не са истоименим VRF-ом другог клијента.

Import страна је друга политика са сопственим route target-има, а одговарајући export са неодговарајућим import-ом даје префикс који постоји у backbone-у и не појављује се ни у једној удаљеној табели.

Редистрибуција и изричито origination понашају се различито

Редистрибуција узима руте које већ постоје у VRF табели и копира их у BGP, филтриране route map-ом. Мапа одлучује који су префикси прихватљиви и које атрибуте носе, а метрика мора бити постављена изричито јер број хопова RIP-а нема значење као BGP метрика. Све што оставите неподешено наслеђује се на начин који обично изненади особу која чита конфигурацију пола године касније.

Узајамна редистрибуција је место где настаје тиха штета. Префикс export-ован у BGP може се вратити кроз другу тачку редистрибуције, а без tag-ова или филтера рута осцилује док обе табеле у сваком тренутку изгледају уверљиво. Филтрирајте по tag-овима примењеним на ивици уместо да се поуздате у топологију да спречи повратну путању.

Изричито origination изгледа уредније и није безусловно. Network statement обично захтева одговарајућу руту у routing табели пре него што се префикс originate-ује, тако да оглас нестаје у тренутку када CE престане да га оглашава. То је често понашање које желите и није исто као статичка рута која остаје конфигурисана заувек. Проверите стварно правило платформе уместо да претпоставите једно од два понашања.

У сваком случају, питање за сваки префикс је који активни извор га чини прихватљивим и шта се дешава када тај извор нестане.

Проверите ланац на четири места

Погледајте CE оглас, VRF routing табелу, VPN routing табелу са њеним route target-ом и import у удаљеном VRF-у, тим редом. На IOS-у то значи излаз CE суседа, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, и исту команду на удаљеном PE-у. На IOS-XR еквивалентни излаз се налази под show bgp vrf CUSTOMER ipv4 unicast. Имена команди се разликују, четири контролне тачке не.

Проверите префикс који би требало да буде одбијен једнако пажљиво као онај који би требало да прође, јер политика која дозвољава све изгледа идентично исправној док не дође прво изузеће. Затим посматрајте withdrawal: искључите CE интерфејс и потврдите да удаљени запис нестаје у оквиру очекиваног тајмера уместо да остане.

Забележите ко је власник сваке политике. Када провајдер управља CE-ом, испоручено понашање припада уговору о услузи, а други протокол или политика withdrawal-а на управљаном уређају је прво проблем документације, а тек потом проблем routing-а.