С нового винграда на старом месс тупо не отображается. Смотрю там, отвечаю тут.


Да почти везде.


Ошибка. Даже две. На каждом из интефейсов. Итого четыре.
1, 2) Интерфейс не может быть сам себе шлюзом.
3, 4) Шлюз в описанной ситуации вообще нахрен не нужен.

И общая ошибка.
5) Дефолтных шлюзов не должно быть более одного.


Ошибка. На каждом из интерфейсов. Итого ещё две.
6, 7) Маршрут в подсеть интерфейса не требуется.

Как лечить:

1) Выключить RRAS.
2) Убрать шлюзы из настроек интерфейсов.
3) Запустить мастер настройки сервера, выбрать роль маршрутизатора ЛВС.
4) На все вопросы отвечать "Да", и НИЧЕГО не менять в настройках по дефолту.
5) Перегрузить сервер.
6) На рабстанциях удалить маршруты в СВОЮ подсеть, но добавить в УДАЛЁННУЮ черз шлюз в СВОЕЙ.

А если требуется аналогичным образом соединить сеть класса С с сетью класса В, т.е. у сети NETNEW параметры: IP: 192.168.20.X, SM: 255.255.0.0, все вышеописанные действия аналогичны?

Классы сетей не существуют. Забудь это слово.

А вот у сети NETNEW указанных тобой параметров быть не должно - эти приведут к общей ошибке адресации. И куче неизлечимых проблем.

Какие тогда должны быть параметры у сети NETNEW с целью достижения количества хостов порядка нескольких тысяч?

Правильные.
Например, использовать 172.16/16. Или там 10.0/16.
Или хотя бы 192.168.128/17 - не очень хорошо, но можно.
А вот 192.168.20/16 - это ошибка. неверный адрес сети. Ненулевые биты адреса в нулевых битах маски.

А если испльзовать IP: 192.168.20.X SM: 255.255.240.0

192.168.020.000 = 11000000 10101000 00010100 00000000
255.255.255.240 = 11111111 11111111 11110000 00000000
Ещё вопросы есть?

Может ;)
Попробуй соединить напрямую 2 компа с разными подсетями и прописать у каждого в качестве шлюза самого себя и попробуй попинговать друг друга - удивишься   
Ну а потом попробуй объяснить как это все работает 

_zorn_, если у тебя работает, то это следствие каких-то особенностей реализации, а не соответствие стандарту. 
Только что две соединённых кроссом ХР-шки настроил, одну 172.16.0.1/24, другую 172.16.1.1/24, и каждая сама себе шлюз. Попробовал "попинговать друг друга" - вполне ожидаемый "Превышен интервал ожидания для запроса.". Стоит же их свести в одну подсеть - пакетики полетели. Фаер есссно выключил.

 
Есть, уважаемый советчик, до сих пор Вы были правы. Ситуацию с ненулевыми битами адреса я понял. И теперь вынужден разъяснить полностью мою проблему. Сеть NETOLD с параметрами IP: 192.168.0.X SM: 255.255.255.0 представляет собой клиент-серверную сеть (домен) со статической IP-адресацией. Когда сеть создавалась, как уже понятно, она создавалась как сеть типа SOHO, никто не мог тогда предположить, что в ней будет больше 254 хостов. Однако в результате структурных изменений в организации, потребовалось гораздо большее количество IP-адресов. Т.к. адресация статическая, то изменить маску сразу у всех рабочих станций домена не получится. Изменять уже имеющиеся IP-адреса тоже нельзя т.к. они прописаны в DNS. Единственным способом, насколько я в данном случае понимаю, является изменение маски подсети на всех серверах и рабочих станциях домена, для "расширения" диапазона используемых IP-адресов. Ответьте пожалуйста, правильное ли это решение и какую в данном случае следует использовать маску подсети? 

Да не вопрос. Расширяйте. Только, начиная с некоторого момента, у вас поползёт адрес сети.

192.168.20/24
192.168.20/23
192.168.20/22
192.168.16/21
192.168.16/20
192.168.0/19
...
192.168.0/16

Компам по барабану, а вот при прописывании маршрутов это необходимо учитывать.
Ну и учтите, что на время смены масок у тех, кто сменил маску, и у тех, кто не сменил, могут возникнуть определённые проблемы. Вплоть до отсутствия доступа и даже видимости в сетеовм окружении.
Опять же учтите, что домен весьма болезненно относится к изменению адресации. А если там вертятся какие-то серверы (ну, к примеру, МS SQL), то и они не заколотятся от счастья. Могут протухнуть некоторые сертификаты... и тыды, и тыпы...
Так что чеклист на смену адресов и масок для каждого сервера будет о-о-очень длинным.

PS. Я бы на самом деле делал это в несколько этапов. И первым поставил бы перевод со статики на ДЦХП, оставаясь в той же подсети. Это нужно будет сделать одним скачком, причём изменение настроек сетевой подсистемы вполне можно выполнить и доменным логон-скриптом. А дальше уже можно просто играть адресами скопов и передаваемыми параметрами (вроде времени аренды), расширяя подсеть до требуемого размера.

Про проблемы я догадываюсь, особеммно меня беспокоит вопрос о том смогут ли пользователи домена нормально логиниться после смены маски или потребуется заново проводить сетевую идентификацию каждого пользователя, правда на некоторых форумах утверждается, что здесь ничего страшного быть не должно. Временным отсутствием доступа и потерей сетевого окружения можно пренебречь. Переход на динамическую адресацию пока не возможен по ряду причин. Но из Вашего ответа я так и не понял какую всетаки целесообразнее выбрать новую маску подсети при уже имеющихся IP: 192.168.0.0-255, для увеличения количества подключаемых хостов?

Это сообщение отредактировал(а) evgvagin - 3.10.2013, 12:35

идентификация как станции, так и пользователя выполняется по его SID, на который ИП не влияет. А вот сертификаты могут стать невалидными - если используется, скажем, VPN или HTTPS, сертификаты придётся перевыпустить.


Если надо захватить хосты подсети 192.168.20/24, и хочется иметь адрес подсети 192.168.0.0, маска должна быть не уже, чем /19, и не шире, чем /16. Одна из четырёх, любая. Шире нельзя - налезет на белый диапазон. Уже нельзя - не захватит адреса.

 Но префикс /16 как раз и соответствует маске 255.255.0.0, или это относится применительно к маршрутизации.

Да, префикс обозначает имено такую подсеть. Однако процитированные тобой слова - вот о такой нестыковке. На /16 она тоже распространяется в полный рост.