Size: a a a

2020 June 10

МФ

Максим Фадин... in MikrotikRus
xcme
Если нужна то можно сделать, это вопрос целей и личных предпочтений. Когда каналы неравноправные я вручную стараюсь выбрать лучший, а другой оставить как резерв. Бывает один канал по оптике, а другой по воздуху. Воздушка тут исключительно как резерв тоже.
Ну там тоже типо того, я пытаюсь тунели делать внутри одного оператора по возможности, меньше вероятность падения.
источник

x

xcme in MikrotikRus
То есть по стоимости каналы по умолчанию равны, а по пропускной способности нет, потому стоимость на туннелях лучше задавать вручную
источник

x

xcme in MikrotikRus
Я задаю по 1000 / скорость исходящего канала. То есть для 50 мбитного апстрима я поставлю стоимость 20
источник

x

xcme in MikrotikRus
Для 10 мбитного апстрима - 100 и т.д.
источник

МФ

Максим Фадин... in MikrotikRus
xcme
То есть по стоимости каналы по умолчанию равны, а по пропускной способности нет, потому стоимость на туннелях лучше задавать вручную
Но балансировка же не будет работать при разной стоимости, или рос сама поймёт что можно 25% трафа до туда то пустить по тунелю с большей стоимостью?
источник

x

xcme in MikrotikRus
Да, не будет, прост она нужна не во всех топологиях. В неожиданном месте может получиться затор
источник

x

xcme in MikrotikRus
У меня был туннель на кипр, там Down 5, Up - 1 мбит
источник

x

xcme in MikrotikRus
И два туннеля оттуда. И по умолчанию косты 10 )))
источник

x

xcme in MikrotikRus
Какой-нибудь удаленный роутер может решить что это ближайший канал с точки зрения стоимости
источник

x

xcme in MikrotikRus
В своей локалке этим часто можно пренебречь, а когда туннели через инет, то лучше дважды подумать. Я только про это хотел сказать. :)
источник

x

xcme in MikrotikRus
Максим Фадин
Но балансировка же не будет работать при разной стоимости, или рос сама поймёт что можно 25% трафа до туда то пустить по тунелю с большей стоимостью?
Не, неэквивалентная только в EIGRP я знаю. Может в ISIS еще, но не факт
источник

RP

Roman Polukhin in MikrotikRus
xcme
Не, неэквивалентная только в EIGRP я знаю. Может в ISIS еще, но не факт
Нет, это прероготива только EIGRP, в IS-IS, как и в OSPF нет балансировки в случае UCMP
источник

МФ

Максим Фадин... in MikrotikRus
xcme
В своей локалке этим часто можно пренебречь, а когда туннели через инет, то лучше дважды подумать. Я только про это хотел сказать. :)
В локалке то одно, но когда нужна множественная связность и своей оптики нет, то приходится так делать)
источник

RP

Roman Polukhin in MikrotikRus
[polukhinri@ccr1016-grt01-sib] /routing ospf lsa> print detail where type=router area=backbone

instance=default area=backbone type=router id=172.16.0.128 originator=172.16.0.128 sequence-number=0x800008E2 age=1651 checksum=0xADEE options="E" body=
    flags=BORDER|EXTERNAL
        link-type=Stub id=172.16.0.128 data=255.255.255.255 metric=10
        link-type=Point-To-Point id=172.16.0.132 data=172.16.0.13 metric=10
        link-type=Stub id=172.16.0.12 data=255.255.255.252 metric=10

instance=default area=backbone type=router id=172.16.0.132 originator=172.16.0.132 sequence-number=0x8000088E age=1568 checksum=0x3F7C options="E" body=
    flags=
        link-type=Point-To-Point id=172.16.0.128 data=172.16.0.14 metric=10
        link-type=Stub id=172.16.0.12 data=255.255.255.252 metric=10
        link-type=Stub id=172.16.0.132 data=255.255.255.255 metric=10
        link-type=Stub id=172.16.16.0 data=255.255.255.0 metric=10

Это LSA type 1 (router), они в OSPFv2 протоколе, содержат информацию о топологии и префиксах, подключенных через интерфейс маршрутизаторов. На основе информации из LSA type 1 и Type 2 внутри области маршрутизаторы строят SPT деревья, в OSPFv2 только эти два LSA содержат информацию о топологии и сетях, для всех типов сетей (point-to-point, broadcast, nbma, point-to-multipoint и тд.). Остальные LSA в OSPFv2 содержат только информацию о сетях и для построения SPT дерева не требуются, информация из них лишь добавляется в дерево при повторном выполнение SPF алгоритма.

Если бы нам нужно было достичь сети 172.16.16.0/24, у которой метрика интерфейса 10, нам бы пришлось направить пакеты через сеть 172.16.0.12/30, у которой метрика тоже 10, и того 20. О чём нам сказал бы маршрут в OSPF RIB, команду вам уже подсказали.
источник

МФ

Максим Фадин... in MikrotikRus
Roman Polukhin
[polukhinri@ccr1016-grt01-sib] /routing ospf lsa> print detail where type=router area=backbone

instance=default area=backbone type=router id=172.16.0.128 originator=172.16.0.128 sequence-number=0x800008E2 age=1651 checksum=0xADEE options="E" body=
    flags=BORDER|EXTERNAL
        link-type=Stub id=172.16.0.128 data=255.255.255.255 metric=10
        link-type=Point-To-Point id=172.16.0.132 data=172.16.0.13 metric=10
        link-type=Stub id=172.16.0.12 data=255.255.255.252 metric=10

instance=default area=backbone type=router id=172.16.0.132 originator=172.16.0.132 sequence-number=0x8000088E age=1568 checksum=0x3F7C options="E" body=
    flags=
        link-type=Point-To-Point id=172.16.0.128 data=172.16.0.14 metric=10
        link-type=Stub id=172.16.0.12 data=255.255.255.252 metric=10
        link-type=Stub id=172.16.0.132 data=255.255.255.255 metric=10
        link-type=Stub id=172.16.16.0 data=255.255.255.0 metric=10

Это LSA type 1 (router), они в OSPFv2 протоколе, содержат информацию о топологии и префиксах, подключенных через интерфейс маршрутизаторов. На основе информации из LSA type 1 и Type 2 внутри области маршрутизаторы строят SPT деревья, в OSPFv2 только эти два LSA содержат информацию о топологии и сетях, для всех типов сетей (point-to-point, broadcast, nbma, point-to-multipoint и тд.). Остальные LSA в OSPFv2 содержат только информацию о сетях и для построения SPT дерева не требуются, информация из них лишь добавляется в дерево при повторном выполнение SPF алгоритма.

Если бы нам нужно было достичь сети 172.16.16.0/24, у которой метрика интерфейса 10, нам бы пришлось направить пакеты через сеть 172.16.0.12/30, у которой метрика тоже 10, и того 20. О чём нам сказал бы маршрут в OSPF RIB, команду вам уже подсказали.
т.е. грубо говоря косты складываются, если пакетам придётся идти через каскад тунелей? Если например придётся пройти по двум тунелям, то кост уже будет 30 при использовании 10 по умолчанию?
источник

RP

Roman Polukhin in MikrotikRus
Максим Фадин
т.е. грубо говоря косты складываются, если пакетам придётся идти через каскад тунелей? Если например придётся пройти по двум тунелям, то кост уже будет 30 при использовании 10 по умолчанию?
Представте дерево, корень это вы, дальше тунель это ветка, маршрутизатор на той стороне тунеля это узел, если за ним ещё один тунель, то ветка продолжается до следующего узла, к которому подключена сеть, это лист. У каждого исходящего интерфейса через который проходят пакеты есть стоимость пути, которая последовательно складывается от корня, до листа.
источник

RP

Roman Polukhin in MikrotikRus
Root (10) -> R1 (10) -> R2 (10) -> Network, 10 + 10 + 10 = 30
источник

МФ

Максим Фадин... in MikrotikRus
Roman Polukhin
Представте дерево, корень это вы, дальше тунель это ветка, маршрутизатор на той стороне тунеля это узел, если за ним ещё один тунель, то ветка продолжается до следующего узла, к которому подключена сеть, это лист. У каждого исходящего интерфейса через который проходят пакеты есть стоимость пути, которая последовательно складывается от корня, до листа.
Это примерно понял.
А балансировку получается можно делать только лишь когда общий кост у двух маршрутов совпадает?
источник

RP

Roman Polukhin in MikrotikRus
Максим Фадин
Это примерно понял.
А балансировку получается можно делать только лишь когда общий кост у двух маршрутов совпадает?
Верно, только если стоимость пути от корня до сети назначения одинаковая, и ни как иначе в случае link-state протоколов.

Важна только стоимость; задержка, надёжность, качество, потери, всё это в OSPF и в link-state протоколах в целом не существует.
источник

МФ

Максим Фадин... in MikrotikRus
А пропорции как то нарезать можно, как выше человек писал?
Или при разных костах трафик пойдёт по большему косту только когда меньший упадёт?
источник