The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Cisco OSPF ACL"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (Маршрутизация)
Изначальное сообщение [ Отслеживать ]

"Cisco OSPF ACL"  +/
Сообщение от McLeod095 (ok) on 27-Фев-13, 17:22 
Здравствуйте!
есть вопрос по OSPF, вернее даже прошу совета как лучше организовать
есть три площадки связанных между собой, получается треугольник, если рисовать связи между площадками. Делаю ospf между ними, что бы при падении одного канала трафик шел не напрямую а через соседа, вроде все норм. Но вот назадача. на tun интерфейсах висят acl, которые разрешают трафик только тот которые необходимо и для каждой связи между площадками он свой, естественно если переключить трафик через соседа, то он не пропускает траф который идет к другой площадке. Как лучше здесь организовать acl, получается делать везде один и вешать его на gre туннели? или есть другие варианты?
Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Cisco OSPF ACL"  +/
Сообщение от GolDi (??) on 27-Фев-13, 17:33 
>[оверквотинг удален]
> есть вопрос по OSPF, вернее даже прошу совета как лучше организовать
> есть три площадки связанных между собой, получается треугольник, если рисовать связи между
> площадками. Делаю ospf между ними, что бы при падении одного канала
> трафик шел не напрямую а через соседа, вроде все норм. Но
> вот назадача. на tun интерфейсах висят acl, которые разрешают трафик только
> тот которые необходимо и для каждой связи между площадками он свой,
> естественно если переключить трафик через соседа, то он не пропускает траф
> который идет к другой площадке. Как лучше здесь организовать acl, получается
> делать везде один и вешать его на gre туннели? или есть
> другие варианты?

делать ACL не на интерфейсах, а на самом OSPF

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Cisco OSPF ACL"  +/
Сообщение от McLeod095 (ok) on 27-Фев-13, 17:34 
>[оверквотинг удален]
>> есть три площадки связанных между собой, получается треугольник, если рисовать связи между
>> площадками. Делаю ospf между ними, что бы при падении одного канала
>> трафик шел не напрямую а через соседа, вроде все норм. Но
>> вот назадача. на tun интерфейсах висят acl, которые разрешают трафик только
>> тот которые необходимо и для каждой связи между площадками он свой,
>> естественно если переключить трафик через соседа, то он не пропускает траф
>> который идет к другой площадке. Как лучше здесь организовать acl, получается
>> делать везде один и вешать его на gre туннели? или есть
>> другие варианты?
> делать ACL не на интерфейсах, а на самом OSPF

Это как?
Кстати cisco 2851

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Cisco OSPF ACL"  +/
Сообщение от Andrey (??) on 27-Фев-13, 17:58 
>[оверквотинг удален]
> есть вопрос по OSPF, вернее даже прошу совета как лучше организовать
> есть три площадки связанных между собой, получается треугольник, если рисовать связи между
> площадками. Делаю ospf между ними, что бы при падении одного канала
> трафик шел не напрямую а через соседа, вроде все норм. Но
> вот назадача. на tun интерфейсах висят acl, которые разрешают трафик только
> тот которые необходимо и для каждой связи между площадками он свой,
> естественно если переключить трафик через соседа, то он не пропускает траф
> который идет к другой площадке. Как лучше здесь организовать acl, получается
> делать везде один и вешать его на gre туннели? или есть
> другие варианты?

Перенести acl на внутренние интерфейсы?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Cisco OSPF ACL"  +/
Сообщение от McLeod095 (ok) on 27-Фев-13, 18:09 
>[оверквотинг удален]
>> есть три площадки связанных между собой, получается треугольник, если рисовать связи между
>> площадками. Делаю ospf между ними, что бы при падении одного канала
>> трафик шел не напрямую а через соседа, вроде все норм. Но
>> вот назадача. на tun интерфейсах висят acl, которые разрешают трафик только
>> тот которые необходимо и для каждой связи между площадками он свой,
>> естественно если переключить трафик через соседа, то он не пропускает траф
>> который идет к другой площадке. Как лучше здесь организовать acl, получается
>> делать везде один и вешать его на gre туннели? или есть
>> другие варианты?
> Перенести acl на внутренние интерфейсы?

Ну это не вариант, потому как лучше все таки acl вешать к интерфейсу приемнику, так не будет лишних опраций.
Сейчас на каждом узле по два туннеля и на каждом туннеле свой acl, вот и думал как сделать.
Тем более что даже если объеденить два acl в один и повесить его на каждый туннель, то все равно в нем необходимо будет прописывать правила разрешающие прохождение трафика относящего к двум другим соседям, что при большом количестве сетей вытекает в n количество правил на каждом маршрутизаторе.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Cisco OSPF ACL"  +/
Сообщение от crash (ok) on 28-Фев-13, 06:33 
>[оверквотинг удален]
>>> трафик шел не напрямую а через соседа, вроде все норм. Но
>>> вот назадача. на tun интерфейсах висят acl, которые разрешают трафик только
>>> тот которые необходимо и для каждой связи между площадками он свой,
>>> естественно если переключить трафик через соседа, то он не пропускает траф
>>> который идет к другой площадке. Как лучше здесь организовать acl, получается
>>> делать везде один и вешать его на gre туннели? или есть
>>> другие варианты?
>> Перенести acl на внутренние интерфейсы?
> Ну это не вариант, потому как лучше все таки acl вешать к
> интерфейсу приемнику, так не будет лишних опраций.

каких именно операций? Вешаете на внутренних интерфейсах листы и разрешаете только то что вам надо. А так вы сами себе геморрой придумываете. Либо разрешайте в туннелях трафик для всех филиалов.


Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Cisco OSPF ACL"  +/
Сообщение от sTALK_specTrum on 28-Фев-13, 08:32 
> Тем более что даже если объеденить два acl в один и повесить
> его на каждый туннель, то все равно в нем необходимо будет
> прописывать правила разрешающие прохождение трафика относящего к двум другим соседям,
> что при большом количестве сетей вытекает в n количество правил на
> каждом маршрутизаторе.

Да ну нафиг. Если аклы стоят на входе внешних интерфейсов, в общем случае добавить в конце пару строк типа:
deny ip any <внутренняя_сеть>
permit ip <сети_всех_филиалов> any
И пусть они между собой через этот филиал летают.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Cisco OSPF ACL"  +/
Сообщение от McLeod095 (ok) on 28-Фев-13, 10:59 
>> Тем более что даже если объеденить два acl в один и повесить
>> его на каждый туннель, то все равно в нем необходимо будет
>> прописывать правила разрешающие прохождение трафика относящего к двум другим соседям,
>> что при большом количестве сетей вытекает в n количество правил на
>> каждом маршрутизаторе.
> Да ну нафиг. Если аклы стоят на входе внешних интерфейсов, в общем
> случае добавить в конце пару строк типа:
> deny ip any <внутренняя_сеть>
> permit ip <сети_всех_филиалов> any
> И пусть они между собой через этот филиал летают.

Ну пока так и сделал, ну и один ACL на все внешние интерфейсы впихнул. Но т.к. сетей много, то уже таких правил permit много.
А при помощи Zone-Based Policy Firewall нельзя решить? Просто пока только наткнулся на это, только начал читать.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Cisco OSPF ACL"  +/
Сообщение от sTALK_specTrum on 28-Фев-13, 11:23 
> Но т.к. сетей много, то уже таких правил permit много.

Зачем? Если сетка нормально была спланирована, то сети филиалов должны красиво объединяться в один диапазон. Записал всех в 172.16.0.0 0.15.255.255 и не мучиться. Например.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Cisco OSPF ACL"  +/
Сообщение от McLeod095 (ok) on 28-Фев-13, 12:00 
>> Но т.к. сетей много, то уже таких правил permit много.
> Зачем? Если сетка нормально была спланирована, то сети филиалов должны красиво объединяться
> в один диапазон. Записал всех в 172.16.0.0 0.15.255.255 и не мучиться.
> Например.

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру