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

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

Започнете от пътя, който искате да избегнете

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

След това намерете алтернативния път. Ако единственият маршрут между офисите минава през клона, никаква метрика не може да изтегли трафика от него, защото няма къде трафикът да отиде. Резервирането не е подробност на този дизайн; то е предпоставката. Втори път, който съществува само на хартия, не се брои.

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

Тези три изгледа отговарят на различни въпроси: кой е съседен, кои интерфейси участват и с каква цена, и кой път избира устройството в момента. Разгръщането на тунел добавя четвърти: линия на диаграма не е доказателство, че съседството се е образувало по нея, а образувано съседство не е доказателство, че препращането следва същия път. Именно в тунелните дизайни тази разлика се проявява най-често.

Какво обявява максималната метрика

RFC 6987 описва рутер, който обявява своите не-задънени връзки с максималната метрика на връзката, определена като 0xffff. Рутерът все още описва себе си и връзките си; просто ги оценява в горния край на диапазона, така че всеки друг рутер изчислява път през него като скъп.

Това е промяна на router-LSA, а не премахване на топологията. Разликата е важна: изчистването на router-LSA оттегля самата информация за топологията, което може да оттегли и връзките, необходими за достигане до рутера и префиксите зад него. Запазването на обявяването и повишаването на цената му запазва тези връзки. Това е цялата разлика между тази техника и премахването.

Механизмът RFC 6987 също няма нищо общо с типовете области или с избора на определен рутер. Задънената област блокира категория обявявания за състояние на връзка на границата на областта, а задъненият рутер оценява собствените си връзки. Подобни думи, несвързан механизъм.

Защо достъпността оцелява, а транзитът не

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

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

Това е поведението, което трябва да проверите, а не да предполагате. Погледнете router-LSA, който клонът генерира, след това пътя, който друг рутер избира за дестинация зад клона и за дестинация в другия офис. Двата отговора трябва да се различават, а ако не се, промяната на метриката не достига решението, за което мислите.

Проблемът с последния път

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

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

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

За OSPFv3 RFC обсъжда R-бита като различен начин за изключване на участието в транзит. Не предполагайте, че той наследява същото поведение на последния път като техниката с максимална метрика, и не копирайте настройки между двете семейства адреси, сякаш са една и съща функция.

Докажете го при нормални и при отказни условия

Тествайте два пъти: веднъж с налични и двата пътя и веднъж с премахнат предпочитания път. Първият тест показва, че предпочитанието работи, а вторият показва какво прави мрежата, когато предпочитанието не може да бъде спазено. Пропускането на втория тест оставя важната половина непроверена.

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

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

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

Подобни статии