Широкие сетевые маски

[911]

Доброе время суток!

Я вот тут думаю в сети сделать маску 255.255.252.0

Т.е. получится сеть 192.168.120.0/22

Какие в связи с этим могут возникнуть проблемы?

Чем плоха/хороша такая маска?

Что где фильтровать надо? (какие броадкасты и т.д.)

[EvilShadow]

Ну почему же 120.0... Может получиться и 0.0, и 4.0, и 8.0...

[911]

Ну почему же 120.0... Может получиться и 0.0, и 4.0, и 8.0...

Не, ну я к примеру сказал 192.168.120.0/23 :)

Меня интересует, какие проблемы в связи с этим возникнут/могут возникнуть?

[GateKeeper]

Ну, если обратиться к справочному руководству, то обнаружится, что проблем здесь никаких. IP создавался не только для масок по разрядности кратным 8.

[911]

Ну, если обратиться к справочному руководству, то обнаружится, что проблем здесь никаких. IP создавался не только для масок по разрядности кратным 8.

я вот имею в виду всякие броадкасты :( арп, нетбиос и т.д.

[EvilShadow]

АРП маска вообще не нужна. С нетбиосом тоже проблем нет. Другое дело - объем бродкастового трафика, но тут уже - либо резать, либо мириться :)

[GateKeeper]

911, скажу так: если должным образом не ухаживать за каждым оконечным устройством (и сдаётся мне, что в большинстве случаев это будут Win*), то чем шире маска, тем сильнее засрана сеть пакетами вида:

ARP who-has произвольный_IP && TCP connect произвольный_IP:445 && exploit

 

Червя зовут Parite-*. Естественно, это не единственная тварь с подобным поведением.

[Илья Дмитриевич]

ARP who-has произвольный_IP && TCP connect произвольный_IP:445 && exploit

это скорее всего sasser или lovesan

[911]

911, скажу так: если должным образом не ухаживать за каждым оконечным устройством (и сдаётся мне, что в большинстве случаев это будут Win*), то чем шире маска, тем сильнее засрана сеть пакетами вида:

ARP who-has произвольный_IP && TCP connect произвольный_IP:445 && exploit

 

Червя зовут Parite-*. Естественно, это не единственная тварь с подобным поведением.

Т.е. надо хотя бы в каких-то узловых точка ставить умные свичи и резать всю эту гадость?

[GateKeeper]

Т.е. надо хотя бы в каких-то узловых точка ставить умные свичи и резать всю эту гадость?

Да. Причём резать надо только маршрутизацией. В идеале такая сволота вообще не будет засирать ни таблицу коммутатора, ни линк при маске /30 на пользователя.

[user_anonymous]

Т.е. надо хотя бы в каких-то узловых точка ставить умные свичи и резать всю эту гадость?

Да. Причём резать надо только маршрутизацией. В идеале такая сволота вообще не будет засирать ни таблицу коммутатора, ни линк при маске /30 на пользователя.

Короче 1 пользователь - 1 вилан.

[911]

Т.е. надо хотя бы в каких-то узловых точка ставить умные свичи и резать всю эту гадость?

Да. Причём резать надо только маршрутизацией. В идеале такая сволота вообще не будет засирать ни таблицу коммутатора, ни линк при маске /30 на пользователя.

Короче 1 пользователь - 1 вилан.

До этого еще дожить надо :(

[Grey]

Т.е. надо хотя бы в каких-то узловых точка ставить умные свичи и резать всю эту гадость?

Да. Причём резать надо только маршрутизацией. В идеале такая сволота вообще не будет засирать ни таблицу коммутатора, ни линк при маске /30 на пользователя.

Короче 1 пользователь - 1 вилан.

До этого еще дожить надо :(

причём тут "дожить"? и причём тут вилан вообще? :)

каждому клиенту по двуххостовой подсети на линк - это никаким боком не касается виланов ... да и никак друг другу не помешает ...

я лично вообще сторонник именно такой раздачи адресов клиентам ...

[DiM_TauRus]

Смысл в этом есть. Но становится неудобоваримо при энном кол-ве пользователей в одном физическом блоке.Неудобство проявляется на уровне человека-администратора, на уровне самой реализации проблем нет.

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

[GateKeeper]

Смысл в этом есть. Но становится неудобоваримо при энном кол-ве пользователей в одном физическом блоке.Неудобство проявляется на уровне человека-администратора, на уровне самой реализации проблем нет.

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

В чём неудобство-то? Объясните мне, как админ админу?

[Grey]

Смысл в этом есть. Но становится неудобоваримо при энном кол-ве пользователей в одном физическом блоке.Неудобство проявляется на уровне человека-администратора, на уровне самой реализации проблем нет.

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

В чём неудобство-то? Объясните мне, как админ админу?

... и мне плиз ... как админу ... :)

имхо нормальный провайдерский подход ... а не подход пионернета или банальной офисной сети :)

[DiM_TauRus]

Да нормальный подход. Все верно.

Но к примеру по подсети на дом/объект - легче в запоминании. Бывает что не всегда есть консоль под рукой, а понять/ответить надо.

[Grey]

Да нормальный подход. Все верно.

Но к примеру по подсети на дом/объект - легче в запоминании. Бывает что не всегда есть консоль под рукой, а понять/ответить надо.

под рукой у админа как минимум должна быть карта сети, т.е. расписанные адреса в удобном для понимания виде...

[DiM_TauRus]

Кроме собственно админа есть еще и "инсталяторы"-монтажники-саппорт. Почти всегда общение с ними по мобиле и в неожиданный момент.

Я же говорю сам подход верный на 100%, но в реальности вызывал некоторые "неудобства". Раздвинув рамки подсети на дом/объект стало в разы проще. Это лично у нас так вышло.

 

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

[DiM_TauRus]

Да я отлично понял что /30 пихаем в одну /24.

 

Слово "саппорт" видимо в посте моем не прочли, хотя монтажники у нас выполняют и роль саппорта, на "крутость" не претендую. К примеру при подключении нового клиента, адимн лишь заводит и активирует запись в биллинге, стандартную настройку клиентских машин монтажники выполняют сами. Это в простых условиях. И мне это кажеться удобным.

 

При строительстве же к примеру радио-каналов на промышленных объектах, вышках... участвуют уже проф-монтажники, которые соответственно только монтаж и проводят + админ.

 

В очередной раз повторю - я согласен с технической стороной подхода.

 

PS. Grey - а куда пост делся предыдущий? - я вроде как на него отвечал...

Edited January 25, 2007 by DiM_TauRus

[boykov]

Смысл в этом есть. Но становится неудобоваримо при энном кол-ве пользователей в одном физическом блоке.Неудобство проявляется на уровне человека-администратора, на уровне самой реализации проблем нет.

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

В чём неудобство-то? Объясните мне, как админ админу?

Неудобно менеджерам. Или кто там еще деньги на железо дает. Мне кажется истинным

"Всех в /30" == "весь внутренний трафик через маршрутизатор"

а в остальном -- да, все нормально, подход правильный. Становится не таким, когда в сети появляется распределенный локальный трафик. или файлопомойка популярная. imho.

[GateKeeper]

Оо Менеджерам-то зачем технические подробности знать!? Как говаривал директор по предыдущему месту работы "Что ты мне тут начинаеш всякими стандартами лечить? Я сказал, как должно быть - выполняй". Т.е. Их (менеджеров) даже заставить в технические детали вникать сложно. Это раз.

 

Два. Если попался эдакий менеджер вида "я всё знаю и вообще только на мне вся контора держится и способен я заменить каждого сотрудника и всех вцелом", то вперед - админу прежде всего для себя самого структурировать выделение блоков /30 внутри сети необходимо. А это, к примеру, база и морда к ней. При наличии соответствующего распоряжения сверху, мол этому выскочке дать данные (или доступ к ним) - манагер тыкается лицом в эту морду (естественно, для него делается read-only), после чего все вопросы у него отпадают.

 

Три. Ну, допустим, появляется файлопомойка популярная. Чем нарушается качество этого сервиса при "/30"/user ? Это при том, что сейчас железа, умеющего маршрутизацию на скорости линка (wire-speed routing) вдоволь (даже тот же d-link гордо сии обозначения употребляет). Единственно, конечно, всякого рода широковещательные сервисы, аля бродкаст-видео и т.п. В хороших железках сии бродкасты можно пробрасывать по маршрутам через сколь угодно большое (но вменяемое, естественно) количество HOP'ов. В остальном же... ведь блин живут же как-то те, кто на терминированных линках своих провайдеров - а там вообще /32 как правило. И ничего. Весь интернет грубо можно на куски /30 побить (у меня так провайдер нетерменированный неинкапсулированный линк даёт) и ничего не изменится. Так объясните мне, чем IP-домосеть отличается от IP-Сети?

[DiM_TauRus]

В обратку: если появляеться такой адимн, из-за примочек которого, почему-то не выходит что-то вовремя сделать...

 

Как я уже говорил данное решение - не везде будет лучшим.

[GateKeeper]

Ладно, признаю, я тупой. На пальцах, пожалуйста, всю гипотетическую неудобность решения.

[user_anonymous]

Пару мыслей вдогонку

Если мы имеем сети вида /30, сидящие в разных виланах, то разом решается масса одних вопросов и тутже возникает масса других :)

 

По моему, тут можно выделить такие плюсы:

* Сверхнадежная и малоресурсоемкая привязка клиента. Терминирование вилана обходится гораздо дешевле, чем скажем PPPoE

* Возможность организации сервисов типа "Личный файервол на сервере". При грамотной постановке это может быть очень востребованой услугой. Если еще пускать в веб через проксю, то можно продавать услугу типа "защитим детей от просмотра порносайтов"

* Возможность значительно уменьшить вирусное заражение сети

* Автоматическое отмирание всяческих широковещательных чатов с соответствующим увеличением пропускной способности.

* Весь внутренний трафик может быть подсчитан.

 

И минусы:

* Многие игры имеют кривой сетевой код и играть в них в такой сети будет проблематично (например Freelancer), либо от пользователя потребуются дополнительные телодвижения для подключения.

* Так как весь внутренний трафик проходит через маршрутизаторы, то на них будет большая нагрузка. Соответственно, либо они будут дорогие, либо их будет много (что создаст определенные трудности с биллингом и их обслуживанием)