Проблема с деревом, исчез IPX на одном участке.Как вылечить?

[Андрей Старков]

Проблема в следующем:
сеть состоит из 3-х подсетей (3 здания пусть 1з, 2з и 3з) в 1з 3 сервера Netware 2 из них с репликой и на одном есть и IPX и IP на другом только IP. в здании 3з один сервер с репликой и только IP и в здании 2з один сервер с репликой и IPX и IP. В канале 1з--3з IPX не маршрутизируется (оборуд. не позволяет) в канале 1з--2з IPX маршрутизировался.
Так сложилось исторически, сеть уже около 10 лет потихоньку меняется, развивается. Соответсвенно в кольце реплик 2 сервера из 5 были доступны друг другу и по IPX и по IP.

по плану модернизации ставит нам вышестоящая контора Cisco PIX чтобы разделить в корпоративной сети трафик различных отпочковавшихся контор друг от друга. и все мои подсетки спрятаны друг от друга за NATом теперь C IP вроде настроили - все сервисы работают, в том числе и Netware сервера видят друг друга. PIX вроде как IPX не маршрутизирует (вернее мы не знаем, в понедельник будем звонить в Москву) Соответсвенно состояние кольца реплик в NDS iMonitor желтое.
Если IPX уже не вернуть, как правильно убрать у серверов "знание" доступности другого по IPX?
В инете ищу но пока не нашел
Буду премного благодарен за любые наводки!

[Павел Гарбар]

NDS пытается связываться всеми доступными способами. Если на интересующих серверах есть оба протокола, а репликация/синхронизация доступна только по IP, то оба сервера все равно будут знать, что у другого есть и IPX адрес.
Вариантов "лечения" на вскидку несколько:
если IPX все еще нужен на обоих серверах (имеются ввиду разделенные IP), то поднимай Compatibility Mode Driver в режиме шлюза.
Если хотя бы на одном из них IPX не нужен, то убираешь его и перегружаешь сервер (для чистоты) - после репликации другой его по IPX уже искать не будет.
В SET-параметрах для NDS укажи первым TCP, а потом IPX/SPX.

[Андрей Старков]

ехал домой и сам понял что это самое простое. На одном стоит старый старый Абакус с ключом в LPT, работающим по IPX - и бухгалтера иногда в него заглядывают.
А вот второй - диспетчерский, и, по моему IPX точно прибить можно

[Андрей Старков]

Убрал я IPX на одном из серверов. Но проблем на самом деле много больше Не беря во внимание удаленные сети, где у меня нет серверов Netware было у меня 3 сети 193.125.150.0/24 192.168.44.0/24 и 192.168.80/0 центровая 193,125 в нее стекаются все каналы и из нее канал далее в выше стоящую организацию. В центре ставится PIX - понимаю в этом достаточно слабо рассказываю как понимаю.
Все наши сети прячутся за НАТом, доступа напрямую из сети в сеть нет. создается VDMZ домен с адресацией 192,168,12,0/24 и ресурсы, которые необходимы клиентам из разных сетей транслируются в эту сеть (Сейчас все всем открыто, но вторым этапом то будет разделение сетей разных предприятий, которые "народились" внутри нашей сети) так вот - в сети 193,125,150 у меня сервера выполняют функции и SLPDA и master DNS и time server и т.д. и теперь эти сервера доступны другим только через адреса в 192,168,12 причем сами об этом недогадываются
DNS поправил, создал еще одну реверс зону и в прямой для серверов сделал дублирующие записи с новыми адресами. Поправил на серверах адреса time server на 192,168,12 подредактировал slp.cfg чтобы указывал тоже на сеть 192,168,12 убедился что resolve работает как надо по имени сервера берет новый его уже адрес.
Но все равно на серверах вне сети 193,125,150 dsrepair дает ошибки 626 на имена серверов из 193,125,150

в инете сказано

From the Partition Continuity screen in NDS manager, run the Repair Network Addresses or Verify Remote Server IDs option. If you prefer to work from the server console, run the Repair Network Addresses option and Verify Remote Server ID Numbers option in DSREPAIR.

но не могу найти этот Partition Continuity screen
и как починить именно network addresses в dsrepair тоже не могу найти.

[Константин Ошмян]

в инете сказано

From the Partition Continuity screen in NDS manager, run the Repair Network Addresses or Verify Remote Server IDs option. If you prefer to work from the server console, run the Repair Network Addresses option and Verify Remote Server ID Numbers option in DSREPAIR.

но не могу найти этот Partition Continuity screen
и как починить именно network addresses в dsrepair тоже не могу найти.

1) сначала находим сам NDS Manager. В NetWare версий 4.x-5.x он живёт в тут: SYS:\PUBLIC\WIN32\ndsmgr32.exe, в NetWare 6.x его там уже нет (видимо, мигрировал в iManager).
2) в левом верхнем окне NDS Manager-а выбираем раздел NDS (partition), после чего из меню Object выбираем пункт Patition Continuity. То же самое можно выбрать не из меню, а из тулбара (кнопка с тремя прямоугольничками, выстроенными по диагонали).
3) DSREPAIR на сервере -> Advanced options menu -> Servers known to this database -> выбираем сервер -> Repair all network addresses либо Repair selected server's network address.

[Сергей.М.]

IPX Cisco PIX не понимает, это верно. Так что имеет смысл переходить на чистый IP. NAT можете не "использовать", вернее транслировать адреса сами в себя, а не в спецально выделенные адрес/адреса. Ну а дальше только списками доступа разрешать, ибо доступ с интерфейса с меньшим security level на больший по умолчанию запрещен.

[Андрей Старков]

PIX настроен не мною и настроен с НАТом и тому подобное с планами на будущее. нужно именно так.
когда спал цейтнот и я подумал "А ведь на эти грабли я наступал!" в настройках SLP SLP DA Discovery Options по умолчанию стоит 2 - DHCP, а DHCP опция slp-agent указывала на старый IP. Поправил DHCP. на сервере установил 4- Static slp.cfg и дерево устаканилось, в iMonitore стало зелененьким
прошел по всем серверам полечил Network Addresses (Спасибо Константину Ошмяну!)
на одном из серверов правда осталось каждые 5 секунд Established connection, Unable to connect Но думаю и здесь разберусь.

[Андрей Старков]

поблема то так и не решена!
Выше я достаточно подробно описал что у меня было и что у меня стало. Точнее за НАТом спряталась сетка 193.125.150.0 сети 80,0 и 44,0 ее напрямую не видят, но друг друга продолжают видеть прекрасно, так сделано.
на серверах в сетях 80,0 и 44,0 (там по одному с RW репликой) в dsrepair\Advanced Option\Servers to known to this database сервера, находящиеся в сети 193,125 (их 3 - 2 с репликами один без) видны как down (причем на сервере в сети 44,0 все три в down а на сервере в сети 80.0 2 в down а один, без реплики NDS в UP)

на серверах в "центре" (193,125,150,0) все сервера видны в UP.
Везде по display slp servicies показываются конечно же адреса из сетки 193,125,150,0 ( ну и из 44,0 и 80,0) что естественно, сами сервера в сетке 193,125 даже и не подозревают что другим они достуаны через сеть 192,168,12,0! Мультикасты на ПИКсе не пропускаются. Что то можно сделать, не поднимая мультикасты на Cisco PIX?

Лечил уже и базы и сетевые адреса в dsrepair везде по кругу.
DNS настроен везде нормально. nslookup RPBSERV (сервер в сети 193,125) возвращает оба его адреса и в родной сети и в VDMZ зоне

Куда копать пока ума не приложу. Ваше мнение?

[Андрей Старков]

положил рядом логи серверов в сети 44,0 и 80,0 - с точностью до секунды и на одном и на другом:

Established connection SERVER1

Established connection SERVER2

Unable to connect SERVER1

Unable to connect SERVER2

Established на оба сервера одновременно и Unable to connect тоже одновременно, между Established и Unable всегда 5 сек.
между Unable и следующим Established 1 минута 28-33 сек иногда 2м.25 сек. иногда 50 сек. Т.е. закономерность есть

У меня в кольце реплик на одних Send Delta на других Receive Delta уже 329 часов красным кирпичом горят!
Куда копать?
или сформулируем по другому, в NDS iMonitor в DSTrace Configuration какие опции взвести и посмотреть, чтобы понять что творится?

[Иван Левшин aka Ivan L.]

[url=NDS / eDirectory Health Check Procedures - Cross Platform]http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=10060600&sliceId=&dialogID=15841593&stateId=0%200%2015843759[/url]
Смотрел?

Офф - блин, как правильно тэгами [url] обрамлять?

[Владимир Горяев]

[url=NDS / eDirectory Health Check Procedures - Cross Platform]http://www.novell.com/...[отгрызено][/url]
Смотрел?

Офф - блин, как правильно тэгами [url] обрамлять?

с точность до наоборот

Код: Выделить всё

[url=ссылка]название ссылки[/url]

. правь

[Андрей Старков]

[url=NDS / eDirectory Health Check Procedures - Cross Platform]http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=10060600&sliceId=&dialogID=15841593&stateId=0%200%2015843759[/url]
Смотрел?

и Cross Platform и только для Netware эти ТИДы даже отпечатаны на бумажке
я вроде понимаю почему это происходит но не знаю как исправить
со стороны "центрального сервера" все видится и синхронизируется посмотрел по dstrace реплика уходит на все сервера. Время синхронизировано. и на стороне серверов в сетях 80,0 и 44,0 time выдает Time is synchronized to the network и в dsrepair по Time Synchronization дооооолго думает но говорит что синхронизировано.

нарыл ТИД Error: -625, -626 in DSRepair | Time Synchronization and Report Synchronization Status. (10094055)
В соответствии с его рекомендациями сделал SET NCP OVER UDP = OFF (только сделал это в Monitor/Server Parameters/NCP)
в display modified environment он уже показывается, но сомнения Надо ли все-таки перегружать сервер? (иначе он прописывается в startup.ncf а раньше такие установки работали только после перегрузки!)

еще вопрос: последний абзац ТИДа звучит-

NAT routers will not translate IP addresses inside NCP packets. The real IP address(es) of a NetWare server are stored with the Server object and registered with SLP. Hence, if the IP address of a NetWare server is resolved per NDS or SLP, it will be the real IP address, not the translated version. So, the real IP addresses of a NetWare server should be routable within your Novell network. Please either exclude non-routable IP addresses with SET NCP EXCLUDE IP ADDRESSES or include routable IP addresses with SET NCP INCLUDE IP ADDRESSES with MONITOR.NLM > 'Server parameters' > 'NCP'.

я решил что мне надо в INCLUDE IP ADDRESSES прописать NAT translated 192.168.12.5 и через ; родной 193.125.150.5 Это правильно или нет?

[Сергей.М.]

Скорей всего у вас закрыт доступ с этих серверов в "центр". Смотрите access-list's на PIX.

[Андрей Старков]

сеть в "центре" действительно спрятана за NATом и напрямую недоступна. Но все ресурсы из нее, которые необходимы ВСЕМ отображаются в VDMZ зону. Т.е если сервер имеет адрес 193.125.150.5 для все сетей он доступен по адресу 192.168.12.5
Сам сервер знает только о своем адресе в сети 193.125 соответсвенно именно его он рекламирует через SLP и объект сервер в дереве.
В DNS прописаны оба его адреса. с других серверов ping ИМЯ_СЕРВЕРА идет, nslookup ИМЯ_СЕРВЕРА возвращает его IP из VDMZ зоны, все правильно, другие адреса недоступны.

Вся проблема как я понимаю выделена жирным. На PIXе сейчас ничего не закрыто. Т.Е. если ресурсы выведены в VDMZ то доступ к ним полный отовсюду. из "центра" все остальные сети доступны полностью.

SET NCP OVER UDP = OFF и
SET NCP PROTOCOL PREFERENCES = TCP UDP установил на всех серверах и сегодня ночью еще все перегрузил (кроме одного)

Думал чтобы сам сервер знал обо всех своих адресах (и рекламировал их) прописать ему как то 2 адреса, но оба адреса должны быть из одной подсети, а у меня они абсолютно разные. Проблема остается!

[Boris Morozov]

я с такой штукой боролся, иначе как VPN туннель туда пробить у меня не решалось. Клиент не цепляется, дает ошибку 8801 вроде, дерево не синхрится. Веб управление работает нормально.
Надо как-то заставить сервер светиться внешним адресом.