[kostil]

Есть 3 NAS сервера, работающих под Mikrotik OS и каталист 6503 как шлюз в интернет

есть сеть реальников XX.YY.ZZ.0/28 - это внешние интерфейсы NAS и шлюз на циске XX.YY.ZZ.1, так же это OSPF backbone area между микротиками и каталистом.

получается следующим образом, пользователь с реальным адресом подлючается через PPPoE, после чего OSPF редистрибутит подлюченное соединение как /32 что по всей видимости затормаживает работу, в связи с большим количеством записей в таблице маршрутизации Mikrotik.

как правильнее реализовать такую схема, что бы избежать дистрибуции /32 учитывая тот факт, что любой из пользователей может подключиться на любой из NAS?

[Ivan Rostovikov]

>в связи с большим количеством записей в таблице маршрутизации

Большое кол-во это сколько ?

 

У меня больше 1000, для OSFP это ниразу не проблема.

[martin74]

[root@vpn1 ~]# ip r | wc -l

1439

 

это вот прям сейчас.... проблем нет.

[derini]

ASBR вас спасёт

[kostil]

сама таблица маршрутизации не очень большая, от 500 до 1000

смущает вкладка в Routing->OSPF->Routes, там порядка 5000 записей

заметил что скачки загрузки процессора как раз в тот момент когда меняется кол-во записей в LSA

 

2 derini - каким образом?

Изменено 23 октября, 2008 пользователем kostil

[martin74]

надеюсь, что такое OSPF и как работает - читали?

[kostil]

надеюсь, что такое OSPF и как работает - читали?

читал, но не сильно углублялся, хотя надо бы...

[kostil]

если не сложно, расскажите как это должно выглядеть с точки зрения OSPF

[derini]

ASBR если по простому, это режим работы маршрутера када он считает себя бордером, в этом режиме он строит все известные ему маршуты, пытается их аггрегировать по маскам, то есть если есть клиенты с соседними айпишниками он их проанонсит не как два /32 маршрута а как один /31 и так далее, по крайней мере у себя наблюдал как летали ospf анонсы про саггрегированные сетки /21

 

а вообще самый простой способ - сделать чтобы каждый из насов отдавал свой отдельный непересекающийся с другими пул и поднять discard интерфейсы, потом тупо прописать маршруты на насы статикой, и пускай они сами разбираются есть у него клиент которому надо переправиьт пакет или пакет идёт никому и его надо слить в дискард

Изменено 23 октября, 2008 пользователем derini

[kostil]

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

[IvanI]

А прокси арп не лучше?

 

[nuclearcat]

Роуты делать - бред

Удаление и добавление роута - как всегда наиболее "дорогая" по ресурсам операция, т.к. приходится перестраивать хеши.

Для NAS такое юзать - глупость

[kostil]

Роуты делать - бред

Удаление и добавление роута - как всегда наиболее "дорогая" по ресурсам операция, т.к. приходится перестраивать хеши.

Для NAS такое юзать - глупость

Это про статику или ospf?

[nuclearcat]

Про роуты вообще. Если сроутить конечно на NAS /24 сетками и не менять - то ладно. А если поднимать /32 на каждый коннект - глупо.

[kostil]

Про роуты вообще. Если сроутить конечно на NAS /24 сетками и не менять - то ладно. А если поднимать /32 на каждый коннект - глупо.

С удовольствием выслушаю ваше предложение по этому вопросу :) как это риализовать не так ресурсоемко, когда пользователю выделяется реальный ip и подключиться пользователь может к любому из NAS?

[Ivan Rostovikov]

У меня RIPv2 между 4-мя NAS и ядром.

1100 роутов. Зебра. Проблем сбыстродействием RIP - нет.

OSFP дает меньшую нагрузку на сеть но большую на CPU. Я выбрал RIP но думаю и OSFP не подкачал бы.

[kostil]

У меня RIPv2 между 4-мя NAS и ядром.

1100 роутов. Зебра. Проблем сбыстродействием RIP - нет.

OSFP дает меньшую нагрузку на сеть но большую на CPU. Я выбрал RIP но думаю и OSFP не подкачал бы.

с RIP - для снижения нагрузки на проц - это мысль:)

[nnm]

Судя по тому, что Вы пишете 'меняется кол-во записей в LSA', вы умудрились заставить OSPF думать, что он должен работать на абонентских интерфейсах и включать их в Router LSA. Если это так, то это действительно жуть т.к. практически любое изменение этого LSA это полный пересчет SPF. Как уже написал, derini, пути у вас два:

1 - Сделать так, чтобы эти префиксы были external. Т.е. для каждого генерировался-бы отдельный LSA 5. Это позволит оптимизировать пересчет топологии для 'правилных' OSPF имплементаций. Даже если вы не используете агрегацию.

2 - Таки использовать статику. При этом придется выделить отдельный пул на каждый NAS и естественно это не будет работать если у юзеров статические адреса.

[kostil]

Судя по тому, что Вы пишете 'меняется кол-во записей в LSA', вы умудрились заставить OSPF думать, что он должен работать на абонентских интерфейсах и включать их в Router LSA. Если это так, то это действительно жуть т.к. практически любое изменение этого LSA это полный пересчет SPF. Как уже написал, derini, пути у вас два:

1 - Сделать так, чтобы эти префиксы были external. Т.е. для каждого генерировался-бы отдельный LSA 5. Это позволит оптимизировать пересчет топологии для 'правилных' OSPF имплементаций. Даже если вы не используете агрегацию.

2 - Таки использовать статику. При этом придется выделить отдельный пул на каждый NAS и естественно это не будет работать если у юзеров статические адреса.

да, OSPF и правда у меня был настроен далеко не оптимально

сейчас сделал так

все пользовательские интерфейсы с реальными адресами - stub area, при этом не нужно делать redistribute connected, тобишь в LSA нет записей с серыми адресами, которые там и не нужны. в данной ситуации LSA составляет порядка 500 записей а таблица маршрутизации ~250

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

еще хотелось бы сделать суммаризацию, правда пока не понял как, что бы например два соседних адреса /32 отдавались как /31 и т.д. поставил галочку на против Inject Summary LSAs в настройках OSPF area в микротике, но что то никакого результата не наблюдаю.

 

P.S. статика сразу отпадает, т.к. адреса у юзеров статические.

Изменено 26 октября, 2008 пользователем kostil

[nnm]

еще хотелось бы сделать суммаризацию, правдо пока не понял как, что бы например два соседних адреса /32 отдавались как /31 и т.д. поставил галоску на против Inject Summary LSAs в настройках OSPF area в микротике, но что то никакого результата не наблюдаю.

 

P.S. статика сразу отпадает, т.к. адреса у юзеров статические.

Во всех известных мне реализациях OSPF суммаризация делается только статически. Независимо от того, для каких префиксов она делается (inter-area или external). Так вот чтобы динамически породить суммаризованный префикс просто по факту наличия спецификов - это что-то из области фантастики... Не думаю, что микротик тут впереди всей планеты...

[Giga-Byte]

держу два НАС-а на freebsd 7.0 + mpd5.0, на mpd включен proxy-arp