proNovell

Константин Ошмян писал(а):Т.е. формально - это стандарт, и если кто-то на этот стандарт кладёт "с прибором", то это только его личное дело. Буду благодарен, если кто-то сможет привести контраргумент в виде ссылки на авторитетный источник, из которого бы однозначно следовало, что данный стандарт соблюдать не надо.

RFC1812 (5.3.5.3)

Господа, вы оба правы, и Константин и ibm. По стандарту действительно подсети со всеми битами установленными в 0 и 1 не могут существовать, НО, Константин, представте ситуацию когда Вашей организации выдана сеть класса С, и Вам ее нужно разбить на подсети, ну скажем 4. Вы следуя стандарту не сможете применить маску 255.255.255.192, и что, откажетесь от 2-х подсетей и затребуете еще одну класса С, чтобы из 2-х сетей выделить 4 подсети???

Так что в данный момент этот стандарт знать по сути нужно при сдаче сертификациооных экзаменов, да и то не всех вендоров.

По поводу маршрутизаторов и коммутаторов уровня 3. Насколько я сейчас помню 3Com' ские маршрутизаторы проглатывали данные подсети без проблем, Cisco ввела специальную команду для этого, которая с версии 11.х вкючена по умолчанию. С остальными вендорами не работал, так что утверждать не могу. Но просто ради любопытства маршрутизаторы и коммутаторы какого производителя при данной маски впадали в ступор?

Из ОС: Windows, Solaris, Linux так же проглатывают без проблем.
И если уж говорить о NetWare то версии 4.11 и 5.0 с которыми я работал так же понимали данные подсети.

Как я понимаю - все дело в полной поддержке CIDR всем оборудованием в сети.... если обнаружится достаточно старый маршрутизатор который это дело не понимает ... будут проблемы....
А для всего оборудования с поддержкой CIDR это не принципиально

В исходных данных прописана приватная сеть, которых можно себе набрать выше крыши. Я еще понимаю, купленную сетку надо делить, за экономию оплаченных адресов боремся. А смысл залезать на грабли только потому, что это может заработать - оно Вам точно надо?

ibm писал(а):

Константин Ошмян писал(а):Буду благодарен, если кто-то сможет привести контраргумент в виде ссылки на авторитетный источник, из которого бы однозначно следовало, что данный стандарт соблюдать не надо.

RFC1812 (5.3.5.3)

Спасибо. Действительно, здесь сказано следующее:

In a CIDR routing domain, wherein classical IP network numbers are meaningless, the concept of an all-subnets-directed-broadcast is also meaningless. To the knowledge of the working group, the facility was never implemented or deployed, and is now relegated to the dustbin of history.

Полностью согласен с последними ораторами, но хотелось бы только подчеркнуть, что в документе речь идёт о CIDR routing domain, или, говоря словами XerX, "полной поддержке CIDR всем оборудованием в сети". К тому же он имеет статус "PROPOSED STANDARD", в то время как RFC0922 - STANDARD.

Сергей.М. писал(а):НО, Константин, представте ситуацию когда Вашей организации выдана сеть класса С, и Вам ее нужно разбить на подсети, ну скажем 4. Вы следуя стандарту не сможете применить маску 255.255.255.192, и что, откажетесь от 2-х подсетей и затребуете еще одну класса С, чтобы из 2-х сетей выделить 4 подсети???

Вот именно такая ситуация у меня и была некоторое время назад. И устройством, не понимающим CIDR, являлся довольно уважаемый RISC-сервер Hewlett-Packard под управлением операционной системы HP-UX 9.x, а затем - 10.x (прошли версии 10.01, 10.10 и 10.20 - со всеми ситуация одинаковая). Приходилось извращаться. Поэтому и считаю ненужным, как писал Алексей Соловьянов, умышленно использовать "подозрительные" диапазоны адресов там, где этого можно избежать.

Константин писал(а):Вот именно такая ситуация у меня и была некоторое время назад. И устройством, не понимающим CIDR, являлся довольно уважаемый RISC-сервер Hewlett-Packard под управлением операционной системы HP-UX 9.x, а затем - 10.x (прошли версии 10.01, 10.10 и 10.20 - со всеми ситуация одинаковая). Приходилось извращаться. Поэтому и считаю ненужным, как писал Алексей Соловьянов, умышленно использовать "подозрительные" диапазоны адресов там, где этого можно избежать.

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

ibm писал(а):Прошу указать ссылку или номер стандарта.

http://www.faqs.org/rfcs/rfc1219.html

2.1 Specification of the New Technique

0 (reserved to mean "this subnet")
10
01
110
001
101
:
:
011...11
111...11 (reserved to mean "all subnets")

Можно и другие указать - впрочем дальше сами найдете.

ibm писал(а):я уже начинаю совневаться в Вашей компетентности.

не сомневающийся - не верит

ibm писал(а):И в дополнение http://www.how-to.ru/linux/howto/IP-Sub ... WTO-6.html

опровержение ссылки на стандарт (даже если не приведен источник) вторичными документами - не лучшая практика.

Сергей.М. писал(а):представте ситуацию когда Вашей организации выдана сеть класса С, и Вам ее нужно разбить на подсети, ну скажем 4. Вы следуя стандарту не сможете применить маску 255.255.255.192, и что, откажетесь от 2-х подсетей и затребуете еще одну класса С, чтобы из 2-х сетей выделить 4 подсети???

Да, 100 раз да! или будьте морально готовы к необъяснимым глюкам (я прекрасно помню на iXBT чел жаловался как раз на то что у него подсеть 192,168,0,0/28 не рутилась)

Влад А.Сокол aka Akina писал(а):

Сергей.М. писал(а):представте ситуацию когда Вашей организации выдана сеть класса С, и Вам ее нужно разбить на подсети, ну скажем 4. Вы следуя стандарту не сможете применить маску 255.255.255.192, и что, откажетесь от 2-х подсетей и затребуете еще одну класса С, чтобы из 2-х сетей выделить 4 подсети???

Да, 100 раз да! или будьте морально готовы к необъяснимым глюкам (я прекрасно помню на iXBT чел жаловался как раз на то что у него подсеть 192,168,0,0/28 не рутилась)

Ну что ж, флаг Вам в руки, а большинство людей проверят поддерживает ли их оборудование/ОС нулевые подсети и преспокойно используют маску /26, и при этом у них не возникнет ситуации как у того чела с iXBT.

Сергей.... ответте мне на один вопрос....
Зачем действовать не по стандарту когда можно сделать по стандарту... ?

Павел Орлов aka XerX писал(а):Как я понимаю - все дело в полной поддержке CIDR всем оборудованием в сети....

Кстати самое обидное, что NW поддерживает CIDR не полностью. http://support.novell.com/cgi-bin/searc ... 069353.htm

Дожили.... вот это новость

Павел Орлов aka XerX писал(а):Сергей.... ответте мне на один вопрос....
Зачем действовать не по стандарту когда можно сделать по стандарту... ?

Павел, Вы сами прекрасно понимаете, что стандарты имеют тенденцию меняться. То что сегодня является стандартом завтра уже может не являтся. Введение возможности маршрутизации нулевых подсетей производителями оборудование и ОС в данном случаи расширяет стандарт, т.е. они не обязуют Вас делать это. Не хотите, Ваше право, есть возможность и это несет определенные выгоды для Вас можете использовать. Небольшой пример, к Вашей БОЛЬШОЙ организации подключаете новый филиал. На филиал выделена подсеть класса С. По требованиям данная подсеть должна быть поделена на подсети для 2-х департаментов, в каждом не менее 90 хостов. По стандарту сеть с маской /25 существовать не может. Результат, вы можете выделить дополнительную сеть класса С (если это возможно) для филиала, либо если оборудование/ОС поддерживает нулевые подсети использовать маску /25. В данном случаи Вам решать как поступить, и любое из Ваших решений будет впринципе верным.
Пример из собственной практики. Всем известно, что нильзя использовать 2 адреса из одной подсети для одного устройства. Вылетел как то сервачек у меня, необходимо было временно использовать соседний для выполнения еще и задач 1-го. Пришлось временно присваивать адреса 1-го как вторичные на 2-м. Нарушение стандарта? ДА!!, но позволило временно выйти из сложившейся ситуации, пока не восстановили 1-й. Операционка Solaris 8.


Уфф... понаписал то .
Попрбую подвести итог. Стандарты знать надо обязательно, и стараться им следовать, НО и необходимо учитывать расширения этих стандартов в своей деятельности. А говорить что делать так правильно а так низя не совсем корректно.


P.S. Ну и напоследок, что все сервера в Инете работают только по 80 порту

Павел Орлов aka XerX писал(а)::lol: Дожили.... вот это новость

Ха, а с CIDR-ом в 4.11/4.2 они вообще интересно поступили - в sp8(a) он был, а в sp9 - уже нет. Мне из-за этого пришлось на всех наших 4.11+sp9 TCPIP.NLM от sp8 руками прикручивать (у нас в сети маска /21 уже много лет - восемь сетей класса C подряд).

Сергей.М. писал(а):Небольшой пример, к Вашей БОЛЬШОЙ организации подключаете новый филиал. На филиал выделена подсеть класса С.

Сергей, согласитесь, что в изначальном вопросе ситуация была обрисована явно другая: сеть с приватными адресами 192.168.x.x, где абсолютно не было необходимости подкладывать себе потенциальные грабли в то время как можно соблюсти (пусть даже слегка устаревшие) стандарты.

Сергей.М. писал(а):Всем известно, что нильзя использовать 2 адреса из одной подсети для одного устройства.

Мне неизвестно. Более того, мне известно прямо противоположное - так делать не только "нильзя", но очень даже можно, о чём говорится даже в таком древнем документе как RFC0791 "Internet Protocol" (Sep-01-1981, Status: STANDARD), раздел 2.3:

Care must be taken in mapping internet addresses to local net addresses; a single physical host must be able to act as if it were several distinct hosts to the extent of using several distinct internet addresses.

...и далее (раздел 3.2):

The local address, assigned by the local network, must allow for a single physical host to act as several distinct internet hosts. That is, there must be a mapping between internet host addresses and network/host interfaces that allows several internet addresses to correspond to one interface. It must also be allowed for a host to have several physical interfaces and to treat the datagrams from several of them as if they were all addressed to a single host.

Давайте всё же обосновывать свои слова, коллеги! "Всем известно", так же как "любимый" аргумент "...и вообще!" - всё-таки убеждают слабо.