forum.opennet.ru - "OSPF и непадающий eth интерфейс " (11)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"OSPF и непадающий eth интерфейс "

Форум Маршрутизаторы CISCO и др. оборудование. (Маршрутизация)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"OSPF и непадающий eth интерфейс "	+/–
Сообщение от Ivan Pomidorov (ok) on 03-Мрт-11, 09:45
Здравствуйте. Есть два роутера соединены eth каналом, на интерфейсах этих роутеров (которые смотрят друг на друга) стоят IP (например 192.168.6.22 ----- 192.168.6.23), соответственно эта сеть для них directly connected, на обоих роутерах поднят ospf и эта сеть в нем прописана. Если eth канал организован просто кабелем, то при обрыве интерфейс падает и маршрутизер перестает рассылать соседям сообщение, что к нему присоединена эта сеть, но если канал состоит из активного оборудования (в моем случае router – switch – wimax – switch –router) то при обрыве канала где-то после коммутатора интерфейс на роутере не падает, и он продолжает слать всем сообщения о наличии у него сети 192.168.6.x. Из за этого резервирование не работает. Можно ли эту ситуацию поправить средствами ospf? Может быть другие протоколы динамической маршрутизации смогут отслеживать присутсвие соседа по icmp или каким другим способом?
Ответить \| Правка \| Cообщить модератору

Оглавление

OSPF и непадающий eth интерфейс , Serge, 10:10 , 03-Мрт-11, (1)

OSPF и непадающий eth интерфейс , ДорогойДрук, 12:32 , 03-Мрт-11, (2)

OSPF и непадающий eth интерфейс , BJ, 13:10 , 03-Мрт-11, (3)

OSPF и непадающий eth интерфейс , Ivan Pomidorov, 15:03 , 03-Мрт-11, (5)

OSPF и непадающий eth интерфейс , BJ, 19:55 , 03-Мрт-11, (7)

OSPF и непадающий eth интерфейс , fantom, 09:12 , 04-Мрт-11, (8)

OSPF и непадающий eth интерфейс , Ivan Pomidorov, 10:54 , 04-Мрт-11, (10)

OSPF и непадающий eth интерфейс , Ivan Pomidorov, 10:10 , 04-Мрт-11, (9)

OSPF и непадающий eth интерфейс , Ivan Pomidorov, 14:51 , 03-Мрт-11, (4)

OSPF и непадающий eth интерфейс , ДорогойДрук, 17:01 , 03-Мрт-11, (6)

OSPF и непадающий eth интерфейс , Ivan Pomidorov, 11:00 , 04-Мрт-11, (11)

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

1. "OSPF и непадающий eth интерфейс " +/–

Сообщение от Serge (??) on 03-Мрт-11, 10:10

> – switch – wimax – switch –router) то при обрыве канала
> где-то после коммутатора интерфейс на роутере не падает, и он продолжает
> слать всем сообщения о наличии у него сети 192.168.6.x. Из за
> этого резервирование не работает.
> Можно ли эту ситуацию поправить средствами ospf?
OSPF hello packets?

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

2. "OSPF и непадающий eth интерфейс " +/–

Сообщение от ДорогойДрук on 03-Мрт-11, 12:32

> OSPF hello packets?
какие хелло для директли коннектед?
я рекомендую изменить топологию  на роутер-вимакс-роутер
а цыска рекомендует маршрутизаторы в таких случаях соединять интерфейсами с сеткой /31 и опцией нонброадкаст.
При этом сами маршрутизаторы должны общаться через адреса на лупбеках.

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

3. "OSPF и непадающий eth интерфейс " +/–

Сообщение от BJ (ok) on 03-Мрт-11, 13:10

Используете такую конструкцию:
interface GigabitEthernet1/0/1
ip address 10.х.х.х  255.255.255.254
ip ospf network point-to-point
ip ospf dead-interval minimal hello-multiplier 3
ip ospf 1 area 0.0.0.0

Через секунду после пропадания связи, трафик перероутится.

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

5. "OSPF и непадающий eth интерфейс " +/–

Сообщение от Ivan Pomidorov (ok) on 03-Мрт-11, 15:03

> Используете такую конструкцию:
> interface GigabitEthernet1/0/1
>  ip address 10.х.х.х  255.255.255.254
>  ip ospf network point-to-point
>  ip ospf dead-interval minimal hello-multiplier 3
>  ip ospf 1 area 0.0.0.0
> Через секунду после пропадания связи, трафик перероутится.
Скажите, критично ли ставить сеть /31 для связи маршрутизаторов?
Попробывал сделать как вы сказали, но с существующей сетью, не получилось... т.е. маршрутизатор продолжает распространять информацию о сети в которой оборван линк.

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

7. "OSPF и непадающий eth интерфейс " +/–

Сообщение от BJ (ok) on 03-Мрт-11, 19:55

У меня вся сеть построена на таких линках, проблем нет совсем (даже скучно стало)
То что информация о линке распространяется это нормально, что в этом плохого? Главное что OSPF процесс не будет его использовать при отсутствующем соседе.
> Скажите, критично ли ставить сеть /31 для связи маршрутизаторов?
> Попробывал сделать как вы сказали, но с существующей сетью, не получилось... т.е.
> маршрутизатор продолжает распространять информацию о сети в которой оборван линк.

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

8. "OSPF и непадающий eth интерфейс " +/–

Сообщение от fantom (ok) on 04-Мрт-11, 09:12

> У меня вся сеть построена на таких линках, проблем нет совсем (даже
> скучно стало)
> То что информация о линке распространяется это нормально, что в этом плохого?
> Главное что OSPF процесс не будет его использовать при отсутствующем соседе.
>> Скажите, критично ли ставить сеть /31 для связи маршрутизаторов?
>> Попробывал сделать как вы сказали, но с существующей сетью, не получилось... т.е.
>> маршрутизатор продолжает распространять информацию о сети в которой оборван линк.
Тунель поднять, а инфу о линке не анонсить - анонсить сеть тунеля.
Если связь между рутерами пропадет - тунель упадет и нужный эффект будет достигнут.

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

10. "OSPF и непадающий eth интерфейс " +/–

Сообщение от Ivan Pomidorov (ok) on 04-Мрт-11, 10:54

>> У меня вся сеть построена на таких линках, проблем нет совсем (даже
>> скучно стало)
>> То что информация о линке распространяется это нормально, что в этом плохого?
>> Главное что OSPF процесс не будет его использовать при отсутствующем соседе.
>>> Скажите, критично ли ставить сеть /31 для связи маршрутизаторов?
>>> Попробывал сделать как вы сказали, но с существующей сетью, не получилось... т.е.
>>> маршрутизатор продолжает распространять информацию о сети в которой оборван линк.
> Тунель поднять, а инфу о линке не анонсить - анонсить сеть тунеля.
> Если связь между рутерами пропадет - тунель упадет и нужный эффект будет
> достигнут.
Спасибо за идею, с тунелями не сталкивался... почитаю.

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

9. "OSPF и непадающий eth интерфейс " +/–

Сообщение от Ivan Pomidorov (ok) on 04-Мрт-11, 10:10

В начале я описывал часть сети, попытаюсь объяснить по другому.
Сеть выглядит так: R1 - S1 - WM - S2 - R2 - R3 (где R - router, S - switch, WM - WiMAx), при этом R1 и R3 соединены другим каналом (назовем его резервным), который также прописан в ospf. А в S1 воткнуты устройства, которые должны быть доступны при пропадании R1.
При обрывании связи на WiMAx соесед R2 (который R1) действительно умирает, но т.к. сеть в его (R1) сторону directly connected на R2, то она приходит к R3 по ospf. И получается что у R3 две записи в таблице маршрутизации (как при наличии связи по wimax так и при отсутствии, потому что интерфейс(R2, смотрящий на S2) остается поднятым), и он так и продолжает слать пакеты в основной канал.

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

4. "OSPF и непадающий eth интерфейс " +/–

Сообщение от Ivan Pomidorov (ok) on 03-Мрт-11, 14:51

>> OSPF hello packets?
> какие хелло для директли коннектед?
> я рекомендую изменить топологию  на роутер-вимакс-роутер
> а цыска рекомендует маршрутизаторы в таких случаях соединять интерфейсами с сеткой /31
> и опцией нонброадкаст.
> При этом сами маршрутизаторы должны общаться через адреса на лупбеках.
к сожалению топологию изменить не могу, коммутаторы нужны в схеме для подключения других устройств.

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

6. "OSPF и непадающий eth интерфейс " +/–

Сообщение от ДорогойДрук on 03-Мрт-11, 17:01

>>> OSPF hello packets?
>> какие хелло для директли коннектед?
>> я рекомендую изменить топологию  на роутер-вимакс-роутер
>> а цыска рекомендует маршрутизаторы в таких случаях соединять интерфейсами с сеткой /31
>> и опцией нонброадкаст.
>> При этом сами маршрутизаторы должны общаться через адреса на лупбеках.
> к сожалению топологию изменить не могу, коммутаторы нужны в схеме для подключения
> других устройств.
Коммутаторы можно подключить в другие интерфейсы роутеров.
/31 желательно использовать, чтобы кроме 2 интерфейсов роутеров никто больше не использовал адресацию из этой подсети. Таким образом наличие поднятого линка не повлияет на сетевые сервисы, даже если каждая циска будет по оспф считать эту сеть работающей.

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

11. "OSPF и непадающий eth интерфейс " +/–

Сообщение от Ivan Pomidorov (ok) on 04-Мрт-11, 11:00

Всем спасибо за ответы, ситуацию поправил поставив стоимости на интерфейсы. Т.е. теперь основной канал с меньшей стоимостью работает постоянно, а на резервныйканал трафик  переходит при пропаадании основного, ну соотвественно возвращается на основной при востановлении.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "OSPF и непадающий eth интерфейс "	+/–
Сообщение от Serge (??) on 03-Мрт-11, 10:10
> – switch – wimax – switch –router) то при обрыве канала > где-то после коммутатора интерфейс на роутере не падает, и он продолжает > слать всем сообщения о наличии у него сети 192.168.6.x. Из за > этого резервирование не работает. > Можно ли эту ситуацию поправить средствами ospf? OSPF hello packets?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "OSPF и непадающий eth интерфейс "	+/–
	Сообщение от ДорогойДрук on 03-Мрт-11, 12:32
	> OSPF hello packets? какие хелло для директли коннектед? я рекомендую изменить топологию на роутер-вимакс-роутер а цыска рекомендует маршрутизаторы в таких случаях соединять интерфейсами с сеткой /31 и опцией нонброадкаст. При этом сами маршрутизаторы должны общаться через адреса на лупбеках.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "OSPF и непадающий eth интерфейс "	+/–
	Сообщение от BJ (ok) on 03-Мрт-11, 13:10
	Используете такую конструкцию: interface GigabitEthernet1/0/1 ip address 10.х.х.х 255.255.255.254 ip ospf network point-to-point ip ospf dead-interval minimal hello-multiplier 3 ip ospf 1 area 0.0.0.0 Через секунду после пропадания связи, трафик перероутится.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "OSPF и непадающий eth интерфейс "	+/–
	Сообщение от Ivan Pomidorov (ok) on 03-Мрт-11, 15:03
	> Используете такую конструкцию: > interface GigabitEthernet1/0/1 > ip address 10.х.х.х 255.255.255.254 > ip ospf network point-to-point > ip ospf dead-interval minimal hello-multiplier 3 > ip ospf 1 area 0.0.0.0 > Через секунду после пропадания связи, трафик перероутится. Скажите, критично ли ставить сеть /31 для связи маршрутизаторов? Попробывал сделать как вы сказали, но с существующей сетью, не получилось... т.е. маршрутизатор продолжает распространять информацию о сети в которой оборван линк.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	7. "OSPF и непадающий eth интерфейс "	+/–
	Сообщение от BJ (ok) on 03-Мрт-11, 19:55
	У меня вся сеть построена на таких линках, проблем нет совсем (даже скучно стало) То что информация о линке распространяется это нормально, что в этом плохого? Главное что OSPF процесс не будет его использовать при отсутствующем соседе. > Скажите, критично ли ставить сеть /31 для связи маршрутизаторов? > Попробывал сделать как вы сказали, но с существующей сетью, не получилось... т.е. > маршрутизатор продолжает распространять информацию о сети в которой оборван линк.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	8. "OSPF и непадающий eth интерфейс "	+/–
	Сообщение от fantom (ok) on 04-Мрт-11, 09:12
	> У меня вся сеть построена на таких линках, проблем нет совсем (даже > скучно стало) > То что информация о линке распространяется это нормально, что в этом плохого? > Главное что OSPF процесс не будет его использовать при отсутствующем соседе. >> Скажите, критично ли ставить сеть /31 для связи маршрутизаторов? >> Попробывал сделать как вы сказали, но с существующей сетью, не получилось... т.е. >> маршрутизатор продолжает распространять информацию о сети в которой оборван линк. Тунель поднять, а инфу о линке не анонсить - анонсить сеть тунеля. Если связь между рутерами пропадет - тунель упадет и нужный эффект будет достигнут.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	10. "OSPF и непадающий eth интерфейс "	+/–
	Сообщение от Ivan Pomidorov (ok) on 04-Мрт-11, 10:54
	>> У меня вся сеть построена на таких линках, проблем нет совсем (даже >> скучно стало) >> То что информация о линке распространяется это нормально, что в этом плохого? >> Главное что OSPF процесс не будет его использовать при отсутствующем соседе. >>> Скажите, критично ли ставить сеть /31 для связи маршрутизаторов? >>> Попробывал сделать как вы сказали, но с существующей сетью, не получилось... т.е. >>> маршрутизатор продолжает распространять информацию о сети в которой оборван линк. > Тунель поднять, а инфу о линке не анонсить - анонсить сеть тунеля. > Если связь между рутерами пропадет - тунель упадет и нужный эффект будет > достигнут. Спасибо за идею, с тунелями не сталкивался... почитаю.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	9. "OSPF и непадающий eth интерфейс "	+/–
	Сообщение от Ivan Pomidorov (ok) on 04-Мрт-11, 10:10
	В начале я описывал часть сети, попытаюсь объяснить по другому. Сеть выглядит так: R1 - S1 - WM - S2 - R2 - R3 (где R - router, S - switch, WM - WiMAx), при этом R1 и R3 соединены другим каналом (назовем его резервным), который также прописан в ospf. А в S1 воткнуты устройства, которые должны быть доступны при пропадании R1. При обрывании связи на WiMAx соесед R2 (который R1) действительно умирает, но т.к. сеть в его (R1) сторону directly connected на R2, то она приходит к R3 по ospf. И получается что у R3 две записи в таблице маршрутизации (как при наличии связи по wimax так и при отсутствии, потому что интерфейс(R2, смотрящий на S2) остается поднятым), и он так и продолжает слать пакеты в основной канал.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	4. "OSPF и непадающий eth интерфейс "	+/–
	Сообщение от Ivan Pomidorov (ok) on 03-Мрт-11, 14:51
	>> OSPF hello packets? > какие хелло для директли коннектед? > я рекомендую изменить топологию на роутер-вимакс-роутер > а цыска рекомендует маршрутизаторы в таких случаях соединять интерфейсами с сеткой /31 > и опцией нонброадкаст. > При этом сами маршрутизаторы должны общаться через адреса на лупбеках. к сожалению топологию изменить не могу, коммутаторы нужны в схеме для подключения других устройств.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	6. "OSPF и непадающий eth интерфейс "	+/–
	Сообщение от ДорогойДрук on 03-Мрт-11, 17:01
	>>> OSPF hello packets? >> какие хелло для директли коннектед? >> я рекомендую изменить топологию на роутер-вимакс-роутер >> а цыска рекомендует маршрутизаторы в таких случаях соединять интерфейсами с сеткой /31 >> и опцией нонброадкаст. >> При этом сами маршрутизаторы должны общаться через адреса на лупбеках. > к сожалению топологию изменить не могу, коммутаторы нужны в схеме для подключения > других устройств. Коммутаторы можно подключить в другие интерфейсы роутеров. /31 желательно использовать, чтобы кроме 2 интерфейсов роутеров никто больше не использовал адресацию из этой подсети. Таким образом наличие поднятого линка не повлияет на сетевые сервисы, даже если каждая циска будет по оспф считать эту сеть работающей.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору

11. "OSPF и непадающий eth интерфейс "	+/–
Сообщение от Ivan Pomidorov (ok) on 04-Мрт-11, 11:00
Всем спасибо за ответы, ситуацию поправил поставив стоимости на интерфейсы. Т.е. теперь основной канал с меньшей стоимостью работает постоянно, а на резервныйканал трафик переходит при пропаадании основного, ну соотвественно возвращается на основной при востановлении.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору