В моем случае мне понадобилось сначала связать два сервера по ospf, потом, в последствии же, добавить к этому всему еще и циску. Вся проблема заключалась в том, что по ospf на циске у меня должны были приниматься не все маршруты, допрос гугла внятных рабочих вариантов не дал, способ нашел в достаточно толстом мануале по иосу моей циски.
Итак, схема:
Имеется два сервера, с адресацией между собой 10.11.12.0/24, к ним присоединяются клиенты, у которых айпи из сетей 192.168.0.0/20 и 192.168.168.0/24, клиенты могут присоединится к любому из серверов, в зависимости от загрузки и циска, которая одним из интерфейсов смотри в сеть 10.10.10.0/24, где есть один из серверов.
Задача – между серверами обмениваться всеми маршрутами для этих подсеток, на циске же принимать только маршруты для сети 192.168.168.0/24
С двумя серверами вопросов не возникло никаких, по данному мне другом примеру я практически за 20 минут все это поднял, из которых я 15 минут крутил настроики фаервола на серверах, чтобы пропускало трафик ospf на нужных интерфейсах. Итак рассмотрим собственно саму настройку, для этого нам понадобится пакет quagga и несколько минут свободного времени.
Ставим кваггу:
yum install quagga
В квагге мы получаем целую кучу “демонов”, состав:
собственно сама зебра, ospfd, ospf6d,ripd, bgpd, ripngd.
Следующее действие не обязательно, но я предпочитаю смотреть маршруты через зебру, собственно дефолтный конфиг:
hostname router1.local
pasword qwerty
log file /var/log/quagga/zebra.log
!
ip forwarding
!
line vty
!
первый параметр говорит как нам отобразать в cli-интерфейсе приглашение, второй – как же нам залогинится, line vty – мы собственно говорим что у нас должен иметься консольный интерфейс.
service zebra start
Консольный интерфейс мы получим а-ля циско, но не стоит обольщаться – некоторые отличия имеют место быть.
собственно “настроив” зебру заходим в нее:
telnet localhost zebra
вводим пароль.
дальше даем команду enable чтобы попасть в привилегированный режим.
теперь собственно идем в конфигурационный режим:
conf t
(полный вариант команды – configure terminal)
password пишем_новый_пароль
enable password пишем_пароль_привилегированного_режима
service password-encryption – этой командой мы даем понять зебре что хорошо бы наши пароли хранить в шифрованном варианте.
далее end – выходим из режима конфигурирования и делаем wri – таким образом мы сохраняем наш конфиг. exit – выйти из зебры.
Все, простейший вариант зебры настроен. Это делать не обязательно, но в последствии может пригодится, если у нас на одном сервере будет сходится не только ospf – в зебре можно смотреть все роуты системы, полученные как по динамическим протоколам, так и статически.
Теперь собственно пришла пора ospf
создаем файл ospfd.conf
его содержимое:
hostname router1-ospf.local
password наш_пароль
log file /var/log/quagga/ospfd.log
!
line vty
!
По аналогии с зеброй заходим меняем пароль, создаем пароль для привилегированного сеанса пользователя и шифруем пароли. Запускаем service ospfd start
Теперь настройка ospf:
conf t
router ospf
router-id айпи-адрес
redistribute connected route-map ospf-out
network 10.11.12.0/24 area 0
passive-interface default
no passive-interface eth0
end
conf t
router ospf дает понять демону что мы хотим создать хост, который будет принимать и передавать на ospf-маршруты.
router-id – как же нам представляться другим участникам ospf
network X.X.X.X – таким образом мы определяем на каких интерфейсах у нас должно “крутиться” ospf, их можно объявить более одного.
passive-interface default – все интерфейсы пассивные (т.е. они не только не слушаются, но и не отсылаются ospf helo-пакеты.
no passive-interface eth0 – собственно говорим что eth0 не пассивный интерфейс.
redistribute connected route-map ospf-out этим мы говорим что известные нам маршруты, имеющие на этом ospf-пире, передавать далее. Т.е. и статические маршруты и динамические, а аксесс-листом в роутмапе мы указываем точно на какие сети мы хотим анонсировать маршруты, а какие отфильтровать.
далее создаем собственно роут-мап:
route-map ospf-out permit 1
match ip address 1
end
следующим делом мы создали нам роут мап, дали ему sequence (порядок просмотра), и сказали что руководствоваться access-list-ом номер 1
далее сформируем наш акссес-лист:
access-list 1 permit 192.168.0.0 0.0.15.255
access-list 1 permit 192.168.168.0 0.0.0.255
access-list 1 deny any
В данном мануале описано в таком порядке, чтобы это было просто понимать, но роут-мап и аксесс-лист желательно создавать прежде, чем его назначать в настройках роутинга.
не забываем сделать wri
вот собственно и все. осталось только подпилить iptables:
-A INPUT -i eth0 -p 89 -j ACCEPT
p 89 – протокол ospf.
До одного чудесного дня все было прекрасно, но вот понадобилось мне включить в обмен маршрутами циску, и, вдобавок еще и фильтровать принимаемые роуты.
И наступил час икс.. когда я провел часа 4 изголяясь с циской. по аналогии с оспфд я практически мгновенно настроил в простейшем вариант ospf, но получил еще приблизительно полторы тысячи роутов, которые циске знать и даром не надо было, вроде бы ничего плохого в этом нет, за циску они не уйдут, но у у нашей циски таблица была не безразмерная, поэтому надо было что-то с этим делать, и был риск что в один прекрасный момент таблица роутов переполнится, и тогда будут чудеса, которые придется достаточно долго отлавливать по сети.
В одном из серверов я добавил в конфиг ospfd параметр network 10.10.10.0/24 и теперь привожу конфиг для циски:
router ospf 100
(цифра 100 – произвольная, порядок процесса)
router-id айпи-маршрутизатора
network 10.10.10.0 0.0.0.255 area 0
passive-interface default
no passive-interface vlan5
distribute-list 10 in
Выходим из конфигурирования оспф и создаем наш акссес лист. Внимательно! циска в акссесс-листах принимает не маски, а вайлдкарды.
ip access-list 10 permit 192.168.168.0 0.0.0.255
ip access-list 10 deny any
Вышеописанным аксесс-листом мы перечисляем сети, которые мы должны принимать маршруты, а все, что к ним не относится мы отправляем в фильтр.
посмотреть работает ли все это на циске или зебре:
show ip route ospf
Итак, вкусности я описал, а теперь перейдем к обратной стороне медали – фильтруйте лучше то, что вы анонсируете по ospf, а не фильтруйте маршруты, получаемые по ospf, хоть в приведенном мной варианте циска не будет добавлять маршруты в свою таблицу или распространять их дальше, но, к сожалению, она все равно добавляет их в свой database для формирования карты lsa, так что в случае с очень большими сетями и непростой конфигурацией циски, есть риск что у циски все упрется не в ограничение по количеству маршрутов, а, как не печально, в память.
К сожалению я так и не нашел способа как подобные вещи можно делать на quagga ospfd, он позволяет только фильтровать маршруты, которые будут попадать из одной area в другую.
По-моему это уже обсуждалось