OSPF разграничение маршрутов

[xvo]

Нет.

На каждом филиале вы создаёте свою area, добавляете туда туннель до офиса и нужные локальные подсети (для них интерфейсы - первая вкладка - переводите в passive).

Дальше все настройки только в офисе:
1) добавляете все area филиалов (естественно, с теми же id)
2) пихаете в них соотвествующие туннели
3) в бэкбоун пихаете офисные подсети (тоже passive, как и в филиалах)
4) настраиваете для всех area кроме backbone area ranges (как, я уже писал выше)

Кроме этого проверяете, чтобы ни один из роутеров в настройках инстанса не redistibute'ил свои connected routes, static routes, да вообще ничего.

[Vlad.Shkvara]

Нет.

На каждом филиале вы создаёте свою area, добавляете туда туннель до офиса и нужные локальные подсети (для них интерфейсы - первая вкладка - переводите в passive).

Дальше все настройки только в офисе:
1) добавляете все area филиалов (естественно, с теми же id)
2) пихаете в них соотвествующие туннели
3) в бэкбоун пихаете офисные подсети (тоже passive, как и в филиалах)
4) настраиваете для всех area кроме backbone area ranges (как, я уже писал выше)

Кроме этого проверяете, чтобы ни один из роутеров в настройках инстанса не redistibute'ил свои connected routes, static routes, да вообще ничего.

Всё отлично заработало, благодарю Вас за этот урок!

P.S. Сможете ли Вы, когда будет время и вдохновение, объяснить на пальцах тему, когда нужно что бы между определенными филиалам таки была связь.

Вы писали что в таком случае нужно анонсировать всем все сети и решать вопрос лишних маршрутов фильтрами.
Расскажете как? Думаю не мне одному будет интересно закрыть этот гештальт с OSPF до конца

P.P.S Друзья! Те кто будет идти по тому же пути что и я имейте в виду что для некоторых задач имеет смысл использовать схему, любезно разжеванную xvo, но при этом не лишним будет знать что в бекбон можно загнать не один роутер, имейте это в виду

[xvo]

Если на пальцах, то это не долго:
в OSPF получается, что роутер может выбирать только то, какие маршруты анонсировать между area, но не то, в какие area. То есть либо всем соседям, либо никому.
А в рамках одной area все роутеры вообще обязаны знать полную топологию своей area.
В этом как бы вся идея.
И пытаться обойти это никакого смысла нет.
Area ranges позволяет "оставить" часть маршрутов для потребления внутри area, и уменьшить количество маршрутов передаваемых наружу, объединяя несколько префиксов в один, но не более того.

Если же нам нужна какая-то точечная избирательность, то нужен другой подход:

Мы разрешаем всем роутерам знать топологию всей сети (возможно с упрощениями, и ислючениями, которые мы делаем на границах area через area ranges).

Дальше, на каждом конкретном роутере мы с помощью фильтров выбираем, какие из маршрутов приходящих через OSPF, мы добавляем в свою основную таблицу, и используем непосредственно для маршрутизации (а не только для "нужд" самого OSPF).
Делается это через routing filters, для дефолтного инстанса - цепочка ospf-in.
Работает по тому же принципу, как firewall - проверяя цепочку последовательно сверху вниз.
Какую конкретно логику выбрать - разрешать часть, выкинуть остальное или наоборот, выкинуть часть, разрешить остальное - это уже надо выбирать на месте, исходя из того, что менее затратно, и (что даже важнее) из соображений, какое должно быть действие при появлении в системе нового маршрута.

И собственно все.
Каждый роутер как бы "знает" всю структуру сети, но при этом сам, для себя и своих клиентов, определяет, какие из маршрутов доступны для использования, а какие - нет.

[Vlad.Shkvara]

Делается это через routing filters, для дефолтного инстанса - цепочка ospf-in.
Работает по тому же принципу, как firewall - проверяя цепочку последовательно сверху вниз.
Какую конкретно логику выбрать - разрешать часть, выкинуть остальное или наоборот, выкинуть часть, разрешить остальное - это уже надо выбирать на месте, исходя из того, что менее затратно, и (что даже важнее) из соображений, какое должно быть действие при появлении в системе нового маршрута.

Хочу понять до конца как это работает)
Ниже прилагаю упрощённую схему сети. Прошу, если Вам будет несподручно расписывать реализацию - хотя бы намекните куда копать.

Итак у нас есть условных 3 филиала, каждых со своей ареа, с тоннелями на оф1.

Есть тоннели между оф1 и оф2, оба без арей, в бекбоне. И есть ф4 с тоннелями на оф2, с ареа.

На данный момент на оф2 сделанно так что во вкладке Area Ranges загнаны ареа ф1, ф2, ф3 и снята галка Advertise, а на оф2 аналогичным образом сделано с ареа ф4.

Задача-минимум - сделать так что бы сети ф1, ф2 и ф3 маршрутизировались не только на оф1, а и на оф2 тоже, но при этом что бы сами по себе ф1, ф2, ф3 между собой маршрутов не имели.

Задача-максимум - что бы при этом ф4 имел маршруты на каждый узел, но на него маршрут не имел никто.

P.S. я почему-то думал что если я поставлю, допустим на оф1 в Area Ranges галку Advertise на ф1 то маршруты на него появятся на всех узлах, а я потом через routing filters сделаю ospf-in подсеть ф1 discard на узлах где не надо. Но нет, он на оф2 недоступен.

Надеюсь что дал данные внятно, готов уточнить детали

[xvo]

1) Объясните точнее, где проходят границы area (либо нарисуйте, либо опишите к каким area относятся сами туннели).
Это имеет принципиальное значение.

2)

Задача-максимум - что бы при этом ф4 имел маршруты на каждый узел, но на него маршрут не имел никто.

Зачем? В том, чтобы иметь маршруты только в одном направлении нет никакого практического смысла: доступа все равно не будет в обе стороны. Так что либо в обе стороны, либо никуда. А вопрос доступа решается firewall’ом, а не наличием/отсутствием маршрутов.

[Vlad.Shkvara]

1) Объясните точнее, где проходят границы area (либо нарисуйте, либо опишите к каким area относятся сами туннели).
Это имеет принципиальное значение.

Туннели с каждого филиала относятся к соответствующей его номеру area
т.е. между ф1 и оф1 два тоннеля - оба находятся в area1

тоннели между оф1 и оф2 находятся в backbone

[xvo]

Тогда по идее всё должно бы работать так, как вы описываете: на оф2 должен прилетать просуммированный (так как он указан в area ranges на оф1) маршрут до ф1 через оф1.

[Vlad.Shkvara]

Тогда по идее всё должно бы работать так, как вы описываете: на оф2 должен прилетать просуммированный (так как он указан в area ranges на оф1) маршрут до ф1 через оф1.

Увы, но нет. Но есть какая-то фигня из разряда уличной магии.

Если я на оф1 захожу в Area ranges и снимаю/ставлю галку Advertise то на оф2 на пару секунд появляется маршрут на тот филиал, который тыкаю. Даже десяток пингов успевает проскочить. Не могу этого объяснить. Да, для моей цели галка должна стоять в конечном итоге или нет? Не до конца понимаю понятие суммирования

[xvo]

Если я на оф1 захожу в Area ranges и снимаю/ставлю галку Advertise то на оф2 на пару секунд появляется маршрут на тот филиал, который тыкаю. Даже десяток пингов успевает проскочить. Не могу этого объяснить.

Значит скорее всего именно в area ranges все настроено правильно, а косяк где-то еще.

Да, для моей цели галка должна стоять в конечном итоге или нет? Не до конца понимаю понятие суммирования

Для тех случаев, когда маршруты до сетей нужно передать из area в area, должна стоять, либо эти сети вообще не должны там упоминаться.

Суммирование нужно для уменьшения нагрузки на маршрутизаторы путем снижения количества передаваемых маршрутов.
Двумя способами:
1) Вместо многих маршрутов можно передать один, который будет включать их.
2) А можно, грубо говоря, его подготовить, но в итоге не передавать даже его.

[Vlad.Shkvara]

Значит скорее всего именно в area ranges все настроено правильно, а косяк где-то еще.

фаерволы проверял - отключил на время и там и там - не помогает

Больше пока идей нет где может быть собака зарыта.

Для тех случаев, когда маршруты до сетей нужно передать из area в area, должна стоять, либо эти сети вообще не должны там упоминаться.

Бекбон в этом плане не считается как отдельная area, в него передается независимо от состояния галочки?

Кстати на ф1 есть маршрут на оф2, прилетает, но пингуется он исключительно во время смены состояния галочки на пару сек