К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

Вопрос сетевым администраторам.

935
0 - 06.11.2018 - 08:42
Господа, подскажите из опыта, сколько устройств желательно размещать в одной подсети, чтобы не возникало торможений из-за обмена широковещательными сообщениями.
Скажем, есть маска 255.255.255.0, в которой можно разместить 254 хоста. Нужно ли разбивать на подсети? Вопросов безопасности и удобства, пока не касаемся.



1 - 06.11.2018 - 11:41
Люблю темы про сферических коней в вакууме. по твоему вопросу бить не надо, пихай все 254 хоста.
935
2 - 06.11.2018 - 17:47
2 1 ну а скажем, 255.255.0.0 тоже отлично заработает? без тормозов? :)
3 - 06.11.2018 - 21:47
ззззммммм. пойду ка я спать.
v
4 - 06.11.2018 - 23:53
Cisco рекомендует не более 500 хостов (/23). /24 обычно идеальный вариант для локалки.
935
5 - 07.11.2018 - 16:30
v спасибо.. такой развернутый ответ я и хотел услышать..
6 - 07.11.2018 - 17:46
смотря что в локалке ) у меня есть сетка /21 маске , там коллизионный домен - одна площадка и там не юзеры трафа минимум. а так больше /22 в работе не припомню c компами на локалку обычно /24 и меньше. со временем все начинают сегментироваться где можно это и удобнее и часто полезнее с точки зрения ИБ. Ну а там зависит смотря что от чего и через что траф идет бывает просто железяк задохлый на маршрутизации.
7 - 20.11.2018 - 09:25
колизионный домен? У вас что, хабы?
8 - 20.11.2018 - 10:23
Цитата:
Сообщение от Добрых дел мастер Посмотреть сообщение
колизионный домен? У вас что, хабы?
Вы таки не поверите, но в одной ЦРБ видел хаб на 24 порта, 10/100 Comp чего то. так что ваш вопрос может быть актуален.
9 - 20.11.2018 - 21:10
В одном ростелекоме я видел, как провода вяжут вязальной нитью (вместо забивки в кроссы).
10 - 20.11.2018 - 22:20
Цитата:
Сообщение от Добрых дел мастер Посмотреть сообщение
У вас что, хабы?
На этикетке написано свитчи, но по факту при заполнении таблиц они легко становятся хабами ) Да прост я продолжаю называть также одноранговые сети несмотря на то что вроде как свитчи разделяют колизии.
11 - 21.11.2018 - 00:54
не так просто переполнить таблицу мак адресов. Это прям постараться надо. Хотя, если девайс дохленький - все можно.
А зачем так? Ты, насколько я помню, из системного оператора? А они, вроде, нищетой не страдают. Наоборот, если что-то чебурекнется - все будут страдать.
Модератор
12 - 21.11.2018 - 07:25
провода вяжут не вместо, а перед "забивкой в кроссы" или плинты, косоплет называется
свичти которые держат в памяти не маки, а хеши маков, и зачастую они могут пересекаться, и бывает так что люди с разными маками но работает только один, сразу в утиль и расторжение контаркта
я вообще пихаю в /21 сети, тока в них самба порты и широковещалка порезана на портах в сторону юзверя, т.е. сегмент как бы уже и не широковещательный
13 - 21.11.2018 - 20:21
не, там вместо. Не было там кросса в привычном смысле слова. Кажется, пайка там была, но давно было, точно не помню.
хеш вместо мак адреса? 6 байт превращают во сколько? в 4? Нафига? А в каких это моделях?
Rat
14 - 22.11.2018 - 16:17
А меня вот какой вопрос мучает. Допустим, сеть с маской 24, диапазон адресов 1.254. Допустим, в сети 4 узла. Как лучше адресовать? 1..4, 126..129, 251..254 или случайным образом. Интересует в первую очередь производительность сети. Каким образом сиська это комментирует?
15 - 23.11.2018 - 01:18
11-Добрых дел мастер > я ушел на вольные хлеба - другие задачи, новая жизнь )
16 - 23.11.2018 - 12:03
Цитата:
Сообщение от Rat Посмотреть сообщение
А меня вот какой вопрос мучает. Допустим, сеть с маской 24, диапазон адресов 1.254. Допустим, в сети 4 узла. Как лучше адресовать? 1..4, 126..129, 251..254 или случайным образом. Интересует в первую очередь производительность сети. Каким образом сиська это комментирует?
Сам вопрос не правильно поставлен. Производительность не зависит от количества, и тем более "расположения" хостов в пределах подсети. Производительность зависит от количество и качества(размер пакета) пакетов/фреймов.
Один из примеров, в студенческие времена, я тестировал эстеру(российский криптошлюз, солярис+цисковской cli+криптопро, адовая смесь) в приватке ЮТК, было 2 эстеры, и у одной снесло башню сетевки и она начала срать в сеть мелкими пакетиками. Вообщем легла вся приватка до 65 каталиста, а он задумался, часа на 3. Когда сетевики дошли до нашего кабинета и когда выяснили, что виновата 1(одна) железка в культурном шоке были все. Конечно, после этого все возможные защиты на портах поставили, но факт остается фактом. А так же для себя обозначил, тесты только в дмз или на столе без привязки к корпоративной сети
Rat
17 - 24.11.2018 - 11:27
16-petrovichr > однако тема выбора адресов ip4 не раскрыта. Полагаю, это стоит всесторонне обсудить! Я верю в то что самое лучшее это 1,2,4,8,32 и т.д. до 128. Получаем 7 узлов в сети, а 7 это магическое число (7 одного не ждут, волк и 7 козлят, белоснежка... ну и так далее). Не может быть чтобы сиська про это умолчала. Вопрос не праздный.
Rat
18 - 24.11.2018 - 11:28
17-Rat > ошибся, правильно так: 2,4,8,16,32,64,128 либо 1, 3, 7, 15, 31, 63, 127.
19 - 24.11.2018 - 22:28
жирновато. С козлятами уже перебор.
v
20 - 25.11.2018 - 06:43
Производительность никак не изменится. Обычно просто резервируют диапазоны.
Например
1..10 - сетевое железо
11..20 - свервера
21..30 - юзеры со статическими ип
31..100 - DHCP
201..xx - vpn
ну это кому как вздумается..
21 - 25.11.2018 - 11:52
в первый раз вижу такое "обычно". Если бы хотелось так разносить - уж лучше в отдельные подсети. Что делать, если серверу понадобится 11-й айпишник (а с виртуализацией это прям легко)?
имхо, отдельная подсеть для сетевого железа, статика для совсем уж инфраструктурных серверов, а остальное - дхцп и если надо - резервация на нем.
v
22 - 26.11.2018 - 23:07
Речь вроде шла а малой сети. Там может и раутера не быть, чтобы подсети создавать.
Но даже в сетях с большим колличеством подсетей вплоне естестствеено резервировать диапазоны, которые не будут выдаваться через DHCP.


К списку вопросов
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск




Copyright ©, Все права защищены