Буквально сейчас наткнулся на следующий эффект.
Ситуация:
1. есть сетка станций, линки ABC-F, IP/X.25 тунели подняты с дефолтными параметрами, пинги по сетке бегают. Адреса 172.30.253.N
2. Процы станций включены в корпоративную IP-сеть, по IP тоже все бегает.
Проблема:
Падает IP линк на какую либо станцию, пропадает возможность связаться с ней и по ABC-F, что ну ни как не должно быть взаимосвязано.
route list на всех станциях выглядит примерно так же:
Destination Netmask Gateway Flags Link Use mtu hop
default 0.0.0.0 10.2.11.1 UGSc il0 62492 1500 1
10.2.11.0 255.255.255.0 10.2.11.7 UC il0 0 1500 0
10.253.1.66 255.255.255.255 10.253.1.65 UH cl0 21 1000 0
10.253.1.68 255.255.255.255 10.253.1.67 UH cl1 0 1000 0
127.0.0.1 255.255.255.255 127.0.0.1 UHl lo0 72642 16384 0
172.30.0.0 255.255.0.0 172.30.253.1 Uc tun0 56 1500 0
172.30.253.1 255.255.255.255 127.0.0.1 UHS lo0 4 16384 0

Куда копать?

В X25/nodes of network для узлов убить IP adressing mode, оставить только IP/X25 (хотя бы указать как предпочтительный). Пусть ходят по D каналу.
Вариант 2 - снести обычные линки, прописать гибридные, с основным сигналлингом на IP и с резервным в D-канале PRI.
Но это более геморойно, могут потребоваться всякие VPN overflow, IO2 платы и т.п.



Редактировано 1 раз. Последний раз 07.10.2004 22:32 пользователем vad.

В X25/nodes of network для всех узлов IP adressing mode не используется, IP/X25 addressing mode соит default.
Второй вариант на много геморойнее, лицензии на VPN overflow есть не на всех станциях, да и PRI-ные каналы более предпочтительны в плане использования.

Тогда у вас наверное стоят статик руты на адреса процессоров или я чего-то не понимаю. Если прописаны обычные линки, в нетадмине нигде не сказано про статик руты, и если (надеюсь) не используется динамический роутинг (RIP), то сеть вообще никак не должна видеть наличие или отсутствие Ethernet воткнутого в процессора.

Все линки прописаны по дефолту, статческий роутинг тоже не указывали, а, после неудачных экспрериментов, RIP поотключали тоже везде.

Обратил внимание, что данная ситуация возникает только на станции с релизом d2.314-4. Может это глюк именно этого релиза?