Етикет за VRF или за префикс? Реалната сметка за капацитет

Два дизайна обявяват един и същ клиентски префикс през едно и също ядро на доставчик. Единият отделя етикет за всеки префикс, другият отделя един етикет за целия VRF, и вторият изглежда по-евтин на всеки слайд. Броят на етикетите е реален, но обикновено не той е бюджетът, който свършва първи. Изборът между двата означава да броим четири ресурса, а не един, и етикетите са най-малкият от тях.

Изборът зависи и от това какво трябва да направи изходният рутер с пакета, след като свали етикета. Решението трябва да се определя от тази функционална разлика, а не от аритметиката на етикетите.

Какво всъщност спестява всяко разпределение

Разпределението за всеки префикс носи информация за препращане в етикета. Изходният рутер може да изпрати пакета направо към правилното съседство без търсене на дестинация, затова то се мащабира добре при големи набори от маршрути в VRF и затова изразходва един етикет за всеки обявен префикс във всеки VRF. Разпределението за VRF, например Junos vrf-table-label, обявява един етикет за всяка инстанция за маршрутизация и използва този етикет, за да избере таблицата на VRF; след това рутерът извършва IP търсене в таблицата.

Това е истинска архитектурна разлика, а не настройка. Етикетирането за VRF дава по-малко пространство за етикети и по-просто обявяване, на цената на едно търсене и на етикет, който не казва нищо за дестинацията. Етикетирането за префикс дава на изходната линейна карта повече информация предварително и струва етикети пропорционално на маршрутите, които носите.

Регистърът на етикетите е малкият

Етикетите MPLS са крайни, но пространството за етикети е достатъчно голямо, че обикновените доставчици да не го изчерпват с няколко хиляди префикса. Етикетирането за VRF наистина помага на платформи с малки хардуерни таблици за етикети или при дизайни, в които един VRF носи пълен интернет канал и етикетите за префикс умножават търсенето на етикети по броя на маршрутите. Това са реални ограничения и те са причината функцията да съществува. Никое от тях не е свързано с броя на префиксите в таблицата.

Пребройте етикетите както за услугата, така и за транспорта, преди да изберете. Дизайнът за VRF все още се нуждае от транспортни етикети за loopback адресите и за всеки хоп по пътя, и все още се нуждае от състояние на съседство. Ако заданието брои само услугови етикети, спестяването се измерва по грешния регистър.

Каналите с маршрути струват памет преди етикетите

Всеки получен път изразходва памет на контролната плоскост, обработка на обновявания и време за сходимост, независимо дали VRF използва един етикет или десет хиляди. Пълният интернет канал вътре в VRF е скъп заради BGP пътищата, RIB, записите в FIB и промените зад тях, а не заради етикета пред таблицата. Същият канал увеличава и обхвата на щетите от изтичане на маршрут или политическа грешка в този наемател.

Затова попитайте какво всъщност изисква клиентът. Ако договорът е частни обекти плюс изход по подразбиране, пълната таблица добавя разходи, без да добавя изискване. Това е търговски въпрос и заслужава писмен отговор, а не допускане, наследено от предишния дизайн. Ако услугата наистина се нуждае от канала за политика или за избор на локален изход, направете го отделен ред с собствен резерв на капацитет и собствено поведение при отказ.

Кога етикетирането за VRF е правилното по подразбиране

То е добро по подразбиране, когато платформата го документира като поддържано, когато броят на маршрутите в VRF е голям и когато цената на изходното търсене е приемлива за профила на трафика. То е и естественият избор, когато оперативната простота е по-важна от изстискването на последната микросекунда от препращането, защото един етикет на наемател е по-лесен за обяснение и одит от етикет на префикс.

То е грешното по подразбиране, когато документацията на платформата обвързва функцията с конкретен хардуер или ограничения на версията, или когато дизайнът зависи от решения за препращане по префикс на изхода. Прочетете собствения справочник на платформата за твърдението, преди да приемете поведението; командата Junos е документирана, но именно ограниченията на хардуера и версията около нея решават внедряването.

Бюджет, който можете да защитите

Изградете случая за капацитет като пет отделни числа: получени пътища, избрани маршрути, инсталирани записи за препращане, услугови етикети и транспортни етикети. Добавете състояние на следващ хоп и съседство, брой наематели и модел на резервиране. Снимката на щастливия път на един VRF не е число за мащаб, а номиналният размер на пространството за етикети не е налична хардуерна таблица.

След това се съгласете за режима на отказ, както и за устойчивото състояние. Какво се случва, когато каналът нарасне с половината, когато наемател добави втори VRF или когато платформата се нуждае от рестарт, за да преоразмери таблица? Бюджет, който издържа на тези въпроси, струва повече от брой етикети, който работи само на хартия.

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