FD вообще менять не надо ?? это служебная величина

ну я имею ввиду delay и bw на том роутере где FD вычисляется

вы можете изменить вектор метрик на соседа

не могу

там dmvpn и один туннель интерфейс принимает кучу туннелей

я могу изменить на нём delay и bw, но мне это не поможет

ага, логично

и два спока анонсят одну сетку хабу?

нет, один спок - одна сеть

другой - другая

просто через 2 канала

каждый

а хаб один или два?

и какова задача?

и какова задача?

тоже пока не понял

а хаб один или два?

хаба 2 но один standby, можно опустить в задаче

что на выходе хотите получить и для чего это нужно

ага, сори, ща ещё раз попробуй сформулить

требуется что бы хаб понимал что у каналов к одному споку разные метрики

а чем оффсет-листы не устраивают?

ага, щас объясню

там получается такая петрушка, что если запихать слишком большой оффсет лист, то на стороне хаба будет RD > FD суксессора, и соотвественно этот канал вообще не будет учавствовать в выборах FS, не смотря на variance

т.е. получится такая ситуация, что со стороны спока балансировка есть, а на хабе только один маршрут

оффсет лист высчитываю из соотнощения полос каналов

тут правильнее наверно variance посчитать изходя из этого, а потом офсет лист сделать

варианс уже после проверки правила RD < FD идёт

вот

Маршрут считается feasible при выполнении двух условий: FD лучшего маршрута больше чем AD, которое анонсирует соседний маршрутизатор. Другими словами, следующий маршрутизатор на пути должен быть ближе к destination, чем локальный маршрутизатор (для предотвращения создания петель маршрутизации). FD лучшего маршрута умноженное на variance должно быть больше чем FD альтернативного маршрута.

http://xgu.ru/wiki/EIGRP#.D0.91.D0.B0.D0.BB.D0.B0.D0.BD.D1.81.D0.B8.D1.80.D0.BE.D0.B2.D0.BA.D0.B0_.D0.BD.D0.B0.D0.B3.D1.80.D1.83.D0.B7.D0.BA.D0.B8_.D0.BC.D0.B5.D0.B6.D0.B4.D1.83_.D0.BC.D0.B0.D1.80.D1.88.D1.80.D1.83.D1.82.D0.B0.D0.BC.D0.B8_.D1.81_.D1.80.D0.B0.D0.B7.D0.BD.D0.BE.D0.B9_.D0.BC.D0.B5.D1.82.D1.80.D0.B8.D0.BA.D0.BE.D0.B9

это то да

а туннельный интерфейс на хабе один?

2 тунельных интерфейса

на каждом споке тоже по 2 туннеля

Маршрут считается feasible при выполнении двух условий: FD лучшего маршрута больше чем AD, которое анонсирует соседний маршрутизатор. Другими словами, следующий маршрутизатор на пути должен быть ближе к destination, чем локальный маршрутизатор (для предотвращения создания петель маршрутизации). FD лучшего маршрута умноженное на variance должно быть больше чем FD альтернативного маршрута.

только первое условие относится к feasibility condition

и FD не бывает "лучшего" или "худшего" маршрута

оно относится к префиксу, а не к маршруту

есть префикс, например 10.0.0.0/24, и у него есть FD

а еще у него есть два successor'а, пять feasible successor'ов, и три просто_соседа_которые_анонсят_префикс

и вот через каждого из них уже есть маршрут, который может встать или не встать в rib

и за то, попадет он в rib или нет, отвечает variance

и, разумеется, чтобы попасть в rib, необходимо (но недостаточно) удовлетворять feasibility condition

кстати, variance, если мне склероз не изменяет, применяется не к FD, а к CD successor'а

так что делать то

архитектуру переделывать штоль

аккуратненько играть оффсетами?

аккуратненько играть оффсетами?

А если там rd одинаковое. Достаточно варианс= 2 и офсет на +1?

чёто не получается

А если там rd одинаковое. Достаточно варианс= 2 и офсет на +1?

нет

кстати, variance, если мне склероз не изменяет, применяется не к FD, а к CD successor'а

а они могут быть разные?

я хочу что бы они пропорционально по корзинам раскидывались

в цефе

а они могут быть разные?

"они" - кто?

"они" - кто?

потоки

я хочу что бы они пропорционально по корзинам раскидывались

Ну да, вперёд к играм с оффсетами:)

FD префикса, и к CD successor-a

потоки

это к другому вопросу было

FD префикса, и к CD successor-a

конечно

я хочу что бы они пропорционально по корзинам раскидывались

Поставьте разный bw на входящих тунелях

это к другому вопросу было

ааа, точно )

каким образом? я чет не часто термин CD встречал

Поставьте разный bw на входящих тунелях

там общий интерфейс к куче туннелей, на которых разные полосы

CD - computed distance, эффективная метрика маршрута через конкретного соседа прямо сейчас

FD - feasible distance, самая выгодная метрика через любого соседа за всю историю пассивного маршрута

ну CD = Local distance + RD так?

очень (ОЧЕНЬ) грубо говоря, да

а что еще?

дело в историчности походу )

дело в историчности походу )

именно

ERROR: S client not available

не ну понятно что метрики там компонентные

сегодня вам сосед присылает маршрут за, условно, 100 копеек

завтра этот же сосед присылает вам маршрут за 150 копеек

но DUAL не отработал, маршрут по-прежнему feasible

DUAL пересчитает...

если, например, CD маршрута через соседа сегодня - 200, а завтра - 250

у меня проблема такая, спок никогда не получит такой RD который будет больше FD. а хаб может получить при некотором оффсет листе.

почему он не должен отработать то?:)

если сегодня RD=100, CD=200, а завтра RD=150, CD=250, то DUAL сидит на попе ровно

маршрут все еще пассивный

моё решение - это сделать такой большой параметр delay на входящих интерфейсах хаба, что бы RD никада не получался бы больше FD

но завтра FD будет все равно 100

а они могут быть разные?

только мы сейчас ушли в сторону :(

моё решение - это сделать такой большой параметр delay на входящих интерфейсах хаба, что бы RD никада не получался бы больше FD

разумно

если сегодня RD=100, CD=200, а завтра RD=150, CD=250, то DUAL сидит на попе ровно

не понял, почему так? EIGRP же апдейт прислал, топология должна пересчитаться, не?

думал может есть какой нить феншуйный вариант

не понял, почему так? EIGRP же апдейт прислал, топология должна пересчитаться, не?

нет. DUAL запускается только если не остается ни одного feasible successor'а

Оо

если FS есть, то он моментально встает в риб

DUALу некогда отрабатывать

он разве non-preemptive?

т.е. я вот могу в лабе щас открыть, сделать чтобы на 2-ва интерфейса был маршрут, поменять метрику одному маршруту

и при этом что successor не сменится разве?

@dmfigol у тебя вроде была статья про EIGRP?

ну и FD с ним

не уверен, что понял вопрос

дима молчит, как партизан, но в интернете найдется все

https://dmfigol.me/blog/understanding-eigrp-metric

ну ты говоришь, если апдейт приходит с новой RD, то FD для префикса не пересчитывается, ща я лабу делаю

FD = самая выгодная метрика за всю историю наблюдений маршрута в его пассивном состоянии

если апдейт пришел с худшим RD, но маршрут остался в пассивном состоянии (т.е. он даже с худшей метрикой он удовлетворяет FC), то FD не изменится

если апдейт пришел с лучшим RD, то лучшая метрика за всю историю наблюдений (т.е. FD) зафиксируется в новое, меньшее значение