Перейти к содержимому
Калькуляторы

Недорогой надёжный гигабитный комутатор

Отсыхание управления, висяки и общая кастрированость испугали. Всё-таки в долгий зимний вечер тащить свою задницу за 15 километров и на вышку - сомнительное удовольствие.

 

Внял голосу разума, заказал DGS-3000-10TC; что интересно, у него внутри (судя по описанию) вроде даже какая-то защита от статики реализована. Облеплю внешними грозозащитами, авось как-то выживет.

 

Кстати, может быть у кого-то из форумчан есть фотография его потрохов? Интересно, как его спаяли, и, соответственно, долго ли он прослужит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Бред, DES1228 последней ревизии и 3200-28 - практически идентичная аппаратная платформа. Более ранние - ничем не отличались от DES3028, кроме прошивки (умельцы их благополучно перешивали в 3028).

И да, причем тут скорость проца к собссно кол-ву изменений настроек???

Свободного DES-1228 у меня в зоне досягаемости нет. Завтра возьму на складе его одноклассника DES-1210-28 и, для сравнения, DES-3200-10, сброшу их в дефолтные насройки (чтобы никто не сказал, что я их криво настроил) и подключу напрямую к ноутбуку без нагрузки (чтобы никто не сказал, что я взвалил на них непосильную ношу), после чего выложу на форум результаты серии пингов интерфейсов этих свитчей.

Потом прокомментирую, почему такой результат.

Изменено пользователем Ob-iVan

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

после чего выложу на форум результаты серии пингов интерфейсов этих свитчей.

Ну и нафига? Что этим собираетесь доказать? :)

Вот вам живой пример: пинг на Huawei S2326TP-EI:

 

PING 10.x.x.x (10.x.x.x) 56(84) bytes of data.
64 bytes from 10.x.x.x: icmp_seq=1 ttl=254 time=17.0 ms
64 bytes from 10.x.x.x: icmp_seq=2 ttl=254 time=7.83 ms
64 bytes from 10.x.x.x: icmp_seq=3 ttl=254 time=6.15 ms
64 bytes from 10.x.x.x: icmp_seq=4 ttl=254 time=5.92 ms
64 bytes from 10.x.x.x: icmp_seq=5 ttl=254 time=6.74 ms
64 bytes from 10.x.x.x: icmp_seq=6 ttl=254 time=6.05 ms
64 bytes from 10.x.x.x: icmp_seq=7 ttl=254 time=7.95 ms
64 bytes from 10.x.x.x: icmp_seq=8 ttl=254 time=41.5 ms
64 bytes from 10.x.x.x: icmp_seq=9 ttl=254 time=7.59 ms
64 bytes from 10.x.x.x: icmp_seq=10 ttl=254 time=9.40 ms
64 bytes from 10.x.x.x: icmp_seq=11 ttl=254 time=5.90 ms

 

а вот - результат пинга TL-SL2210WEB:

PING 10.x.x.y (10.x.x.y) 56(84) bytes of data.
64 bytes from 10.x.x.y: icmp_seq=1 ttl=63 time=0.712 ms
64 bytes from 10.x.x.y: icmp_seq=2 ttl=63 time=0.594 ms
64 bytes from 10.x.x.y: icmp_seq=3 ttl=63 time=0.590 ms
64 bytes from 10.x.x.y: icmp_seq=4 ttl=63 time=0.586 ms
64 bytes from 10.x.x.y: icmp_seq=5 ttl=63 time=0.612 ms
64 bytes from 10.x.x.y: icmp_seq=6 ttl=63 time=0.612 ms
64 bytes from 10.x.x.y: icmp_seq=7 ttl=63 time=0.633 ms
64 bytes from 10.x.x.y: icmp_seq=8 ttl=63 time=0.598 ms
64 bytes from 10.x.x.y: icmp_seq=9 ttl=63 time=0.582 ms

 

Оба в реальной сети под нагрузкой. Хуавей ничем непосильным не нагружен (кучка вланов, снмп; STP, опция 82 и прочие софт-плюшки не юзаются).

Несколько не вяжется с вашим видением реальности, не находите?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Извините, но если оценивать качество свича по пингу, то здесь безоговорочно победит продвигаемый Сабом микротик, которому позорно сольют циски и прочие джуны.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если оценивать качество свича по пингу, то здесь безоговорочно победит продвигаемый Сабом микротик,

Или вебсмарт. Ввиду заметно более простой ОС и меньшего кол-ва фоновых процессов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Извините, но если оценивать качество свича по пингу, то здесь безоговорочно победит продвигаемый Сабом микротик, которому позорно сольют циски и прочие джуны.

andryas, если на свитч хороший пинг, то само по себе это еще но означает, что это хороший свитч ;)

Впрочем, лично я ничего против Микротиков не имею, хотя сам ими и не пользуюсь.

 

А вот если пинг на свитч паршивый, то это серьезный повод задуматься о многом. Например о том, можно ли использовать пингование этого свитча для мониторинга сети, удастся ли скачать с него до конца таблицу MAC'ов на портах по snmp до ухода в глубокий таймаут, можно ли будет зайти на него во время жесткого флуда и отключить нужный порт и т.д.

 

P.S.: Поверьте, если вы раньше не пробовали пинговать DES-1210-28, его пинги вас впечатлят ;)

Это не просто плохо. Это запредельно.

Изменено пользователем Ob-iVan

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Или у вас хобби - выдумывать свое нескучное ТЗ, а потом - убеждать ТСа в том, что именно это ему и нужно? Вы, случаем, не интегратором работаете? :)

Все зависит от конечной стоимости (включая стоимость обслуживания), не?

Если свич меняется несколько раз за сезон, а конфигурится только при установке - устанавливать циски ценой в 1 килобакс, когда по функционалу хватит свича за 150-200 баксов, + отдельного провода питания на свич (на случай если он вдруг повиснет - чтобы не ребутить всю БС/не лезть наверх) - по-вашему, целесообразно?

 

Нужен надёжный (невиснущий) экономичный гигабитный комутатор.

 

Соорудив грозозащиту и нормальное питание, менять часто не прийдется.

А надежный это не про длинк/тплинк.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А затащить наверх волокна и поставить в ящике вместо коммутатора кучу конвертеров с которых уже внизу принять все в сфп порты коммутатора не лучше?

Сгорел конвертер на вышке - послал кого угодно его заменить и все. Сгорел один поменяли один, сгорели два - два сменили, вместо целого коммутатора.

Ничего перенастраивать не надо. Или такой вариант по какой-то причине не катит?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Такой вариант есть, это Mikrotik RB260GS, получается экономия волокон - одного хватает на целых 5 портов, по цене как медик. Да еще и пинговаться умеет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А вот если пинг на свитч паршивый, то это серьезный повод задуматься о многом

Ок, хуавеи и циски - паршивые свичи. Тплинк, по вашему критерию - просто замечательный свич....

 

Соорудив грозозащиту и нормальное питание, менять часто не прийдется.

При попадании молнии в объект - грозозащита обычно не спасает :)

 

А надежный это не про длинк/тплинк.

Длинки ненадежные, да:

Device Type         : DGS-3100-24TG  Gigabit stackable L2 Managed Switch
...
Boot PROM Version   : 1.0.1.05
Firmware Version    : 3.60.37
Hardware Version    : b1
...
System Up Time      : 424 days 10 hours 23 mins 34 seconds

 

а вот один из вебсмартов от тплинка (тех самых виснущих в некоторых случаях):

Hardware Version:	TL-SL2210WEB 1.0
Software Version:	1.3.5 Build 20070307 Rel.33086
System Description:	8FE+2G Web-Smart Switch
Run Time:	86 Day - 6 Hour - 48 Min - 55 Sec

Может, вы не умеете готовить коммутаторы? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А вот если пинг на свитч паршивый, то это серьезный повод задуматься о многом

Ок, хуавеи и циски - паршивые свичи. Тплинк, по вашему критерию - просто замечательный свич....

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

 

Вы "забыли" первую фразу из моего постинга. Вот как это звучало в оригинале ("забытая Вами фраза выделена красным"):

 

если на свитч хороший пинг, то само по себе это еще но означает, что это хороший свитч ;)

...

А вот если пинг на свитч паршивый, то это серьезный повод задуматься о многом.

Это к вопросу о том, замечательный ли свитч TP-Link.

 

Теперь о том, паршивый ли свитч Huawei.

Вам кажется, что приведенные Вами результаты пингов Huawei S2326TP-EI так ужасны?

Тогда Вы не видели настоящего ужаса.

 

Итак, привожу обещанные результаты тестирования двух свитчей разных классов от одного и того же производителя.

Оба свитча сброшены в дефолтные настройки и подключена напрямую к Gigabit Ethernet порту ноутбука с Windows 7.

Нагрузки на свитчи (кроме самих пингов) в момент тесрирования нет.

 

Первый свитч - стандартная "рабочая лошадка" D-Link DES-3200-10:

 

C:\Users\Ivan>ping -n 20 10.90.90.90

Обмен пакетами с 10.90.90.90 по с 32 байтами данных:
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=4мс TTL=30
Ответ от 10.90.90.90: число байт=32 время=3мс TTL=30

Статистика Ping для 10.90.90.90:
   Пакетов: отправлено = 20, получено = 20, потеряно = 0
   (0% потерь)
Приблизительное время приема-передачи в мс:
   Минимальное = 3мсек, Максимальное = 4 мсек, Среднее = 3 мсек

Ничего заслуживающего комментариев. Пинги - как пинги.

 

А теперь - гвоздь программы! Web-Smart свитч D-Link DES-1210-28.

Вот его полные данные:

Device Type 	DES-1210-28
Boot Version 	        1.00.002
Firmware Version 	2.10.000
Protocol Version 	2.001.004
Hardware Version 	B1
Serial Number 	        QBL21C6000707

 

А теперь - пинги:

C:\Users\Ivan>ping -n 20 10.90.90.90

Обмен пакетами с 10.90.90.90 по с 32 байтами данных:
Ответ от 10.90.90.90: число байт=32 время=586мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=16мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=196мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=7мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=6мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=416мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=7мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=32мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=19мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=10мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=274мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=5мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=8мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=533мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=6мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=161мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=20мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=5мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=415мс TTL=64
Ответ от 10.90.90.90: число байт=32 время=5мс TTL=64

Статистика Ping для 10.90.90.90:
   Пакетов: отправлено = 20, получено = 20, потеряно = 0
   (0% потерь)
Приблизительное время приема-передачи в мс:
   Минимальное = 5мсек, Максимальное = 586 мсек, Среднее = 136 мсек

Вот, что я называю ПЛОХИМИ ПИНГАМИ! И вот что такое Web-Smart серии 1210 "во всей своей красе".

В момент тестирования он не делал вообще ничего: только отвечал на пинги. И при этом умудрялся думать более чем пол секунды над самым простым действием - возвратом ICMP пакета (а если запустить серию из 1000 пингов, то и секундные задержки можно встретить)

 

И Вы всерьез утверждаете, что такой дохлый CPU способен полноценно динамически управлять системой коммутации пакетов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А теперь - гвоздь программы! Web-Smart свитч D-Link DES-1210-28.

 

Обмен пакетами с 10.90.90.90 по с 32 байтами данных:

Ответ от 10.90.90.90: число байт=32 время=586мс TTL=64

Ответ от 10.90.90.90: число байт=32 время=16мс TTL=64

Ответ от 10.90.90.90: число байт=32 время=196мс TTL=64

Ответ от 10.90.90.90: число байт=32 время=7мс TTL=64

Ответ от 10.90.90.90: число байт=32 время=6мс TTL=64

Ответ от 10.90.90.90: число байт=32 время=416мс TTL=64

Ответ от 10.90.90.90: число байт=32 время=7мс TTL=64

Ответ от 10.90.90.90: число байт=32 время=32мс TTL=64

Ответ от 10.90.90.90: число байт=32 время=19мс TTL=64

Ответ от 10.90.90.90: число байт=32 время=10мс TTL=64

 

Однажды я тоже ужаснулся такой же картинке, поинтересовался в саппорте де-линков - на что ответили - "Это нормально"

Вы попробуйте пингануть железки(находящиеся в работе) которые включены транками через этот свичь(1210) - и увидете такиеже красивые пинги как на 3200.

Просто на web интерфейс этих смартов выделено слишком мало ресурсов ЦП это девайса.

Изменено пользователем Diman_xxxx

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И Вы всерьез утверждаете, что такой дохлый CPU способен полноценно динамически управлять системой коммутации пакетов?

Вы всерьез считаете, что нужно мгновенно "динамически упрвлять системой коммутации пакетов"? Пример хоть одного события, требующего мгновенного переконфигурирования свича? :)

И почему вы думаете, что дело в слабом проце, а не в низком приоритете службы, отвечающей за сетевое управление? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И Вы всерьез утверждаете, что такой дохлый CPU способен полноценно динамически управлять системой коммутации пакетов?

 

cpu управляет системой коммутации пакетов?

наверное при пинге на mgmt interface тоже происходит _динамическое_управление_системой_коммутации_пакетов? =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Капец, форум домохозяек.

Берите розовые со стразами!

 

DGS-1210-24

PING 172.16.0.250 (172.16.0.250): 56 data bytes
64 bytes from 172.16.0.250: icmp_seq=0 ttl=64 time=14.439 ms
64 bytes from 172.16.0.250: icmp_seq=1 ttl=64 time=9.923 ms
64 bytes from 172.16.0.250: icmp_seq=2 ttl=64 time=8.931 ms
64 bytes from 172.16.0.250: icmp_seq=3 ttl=64 time=7.101 ms
64 bytes from 172.16.0.250: icmp_seq=4 ttl=64 time=5.667 ms
64 bytes from 172.16.0.250: icmp_seq=5 ttl=64 time=5.058 ms
64 bytes from 172.16.0.250: icmp_seq=6 ttl=64 time=3.849 ms
64 bytes from 172.16.0.250: icmp_seq=7 ttl=64 time=12.839 ms
64 bytes from 172.16.0.250: icmp_seq=8 ttl=64 time=11.807 ms
64 bytes from 172.16.0.250: icmp_seq=9 ttl=64 time=10.805 ms
64 bytes from 172.16.0.250: icmp_seq=10 ttl=64 time=9.596 ms
64 bytes from 172.16.0.250: icmp_seq=11 ttl=64 time=8.592 ms
64 bytes from 172.16.0.250: icmp_seq=12 ttl=64 time=7.762 ms
64 bytes from 172.16.0.250: icmp_seq=13 ttl=64 time=6.735 ms
64 bytes from 172.16.0.250: icmp_seq=14 ttl=64 time=5.745 ms
64 bytes from 172.16.0.250: icmp_seq=15 ttl=64 time=4.729 ms
64 bytes from 172.16.0.250: icmp_seq=16 ttl=64 time=3.711 ms
64 bytes from 172.16.0.250: icmp_seq=17 ttl=64 time=12.487 ms
64 bytes from 172.16.0.250: icmp_seq=18 ttl=64 time=11.678 ms
64 bytes from 172.16.0.250: icmp_seq=19 ttl=64 time=10.673 ms
64 bytes from 172.16.0.250: icmp_seq=20 ttl=64 time=9.701 ms
64 bytes from 172.16.0.250: icmp_seq=21 ttl=64 time=8.701 ms
64 bytes from 172.16.0.250: icmp_seq=22 ttl=64 time=7.627 ms
64 bytes from 172.16.0.250: icmp_seq=23 ttl=64 time=6.625 ms
64 bytes from 172.16.0.250: icmp_seq=24 ttl=64 time=5.599 ms
64 bytes from 172.16.0.250: icmp_seq=25 ttl=64 time=4.585 ms
64 bytes from 172.16.0.250: icmp_seq=26 ttl=64 time=3.479 ms
64 bytes from 172.16.0.250: icmp_seq=27 ttl=64 time=12.567 ms
64 bytes from 172.16.0.250: icmp_seq=28 ttl=64 time=11.529 ms
64 bytes from 172.16.0.250: icmp_seq=29 ttl=64 time=10.533 ms
64 bytes from 172.16.0.250: icmp_seq=30 ttl=64 time=9.857 ms
64 bytes from 172.16.0.250: icmp_seq=31 ttl=64 time=8.516 ms

О чём это говорит нормальному человеку?

- Да ни о чём.

О чём это говорит админу?

- Что возможно что то не так.

О чём это говорит тому кто програмил всякие слабоумные непроцы?

- О том, что вероятно там низкий HZ и низкий приоритет у кода отвечающего на icmp, и его переодически вытесняют.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И Вы всерьез утверждаете, что такой дохлый CPU способен полноценно динамически управлять системой коммутации пакетов?[/size]

меня заинтересовало что автор имел ввиду под "полноценно динамически управлять системой коммутации пакетов"

можете растолковать ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Или у вас хобби - выдумывать свое нескучное ТЗ, а потом - убеждать ТСа в том, что именно это ему и нужно? Вы, случаем, не интегратором работаете? :)

 

При попадании молнии в объект - грозозащита обычно не спасает :)

 

Объяснюсь на доступном вам языке.

Человек приходит на форум врачей и говорит: Хочу жрать говно, подскажите какого говно лучше употреблять, жидкое или твердое, мягкое или с корочкой.

Вопрос, что ему повосетуют врачи?

 

Можно сделать правильно, а можно сделать абы как и "менять свичи раз в месяц". Повторюсь, каждый сам для себя выбирает как ему работать, головой или ногами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если уважаемые собеседники не возражают, я сгруппирую похожие вопросы вместе и прокомментирую их не в том порядке, в котором они задавались.

 

И почему вы думаете, что дело в слабом проце, а не в низком приоритете службы, отвечающей за сетевое управление? :)

О чём это говорит тому кто програмил всякие слабоумные непроцы?

- О том, что вероятно там низкий HZ и низкий приоритет у кода отвечающего на icmp, и его переодически вытесняют.

Про это многократно говорила техподдержка D-Link'a.

Если так, навскидку, то например здесь:

У WebSmart коммутаторов довольно слабый cpu - это неоднократно обсуждалось на форуме, отсюда и большой пинг до самого коммутатора и высокая загрузка cpu при работе с WebUI.

или здесь:

Пинг до интерфейса коммутатора не является показателем. CPU у WebSmart коммутаторов довольно слабый, и поэтому обработка icmp может идти с задержками.

или здесь:

У этой модели слабый процессор, а функционала много, поэтому он действительно медленно отвечает на пинги.

или еще в куче мест на форуме D-Link'a. Поиск в помощь.

 

Когда я в личной переписке спрашивал у D-Link'овцев, есть ли шансы, что в новых прошивках появится возможность увеличить приоритет обработки пингов, мне ответили, что шансов нет, так как ограничения там аппаратные и "он играет так, как может" (с)

 

Можно, конечно, усомниться в компетенции сотрудников представительства D-Link, но косвенно их слова подтверждаются тем фактом, что подобные задержки пингов у этих моделей есть даже тогда, когда на них отключено все, что только можно отключить, и нет никакой сетевой нагрузки. Что там может быть более приоритетным, когда свитч ничего не делает? Idle-циклы процессора?

 

-------------------------

 

Вы всерьез считаете, что нужно мгновенно "динамически упрвлять системой коммутации пакетов"? Пример хоть одного события, требующего мгновенного переконфигурирования свича? :)

меня заинтересовало что автор имел ввиду под "полноценно динамически управлять системой коммутации пакетов"

можете растолковать ?

Например у нас в сети по ряду причин не используется протокол STP. Вместо этого свитчи управляются по snmp с центрального узла. Как только где-то обрывается линк, включаются порты на резерв, как только линк восстанавливается - резервные порты отключается.

Нужно ли объяснять, насколько важна скорость реакции свитча при восстановлении основного линка (т.е. фактически - при возникновении петли, стандартные средства разрешения которой отключены)?

Это лишь один из примеров, важных конкретно для меня.

Изменено пользователем Ob-iVan

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Стоит ли брать DGS-1100-24 для небольшого офиса? От коммутатора кроме собственно коммутации пары серверов и двух десятков рабочих станций требуется возможность удаленно поглядеть жив порт или нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Стоит ли брать DGS-1100-24 для небольшого офиса? От коммутатора кроме собственно коммутации пары серверов и двух десятков рабочих станций требуется возможность удаленно поглядеть жив порт или нет.

Собственно на такой класс задач этот свитч и ориентирован. IMHO, вполне можно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можно сделать правильно

Ок, есть у вас одинкий объект высотой в 50 метров, который собирает молнии со всей округи. Какие у вас предложения по организации защиты от прямого попадания молнии? :) Может, предложите грозозащиту, способную погасить импульс током в несколько килоампер до приемлемого напряжения (чтобы порты не выжгло)? :)

 

 

Когда я в личной переписке спрашивал у D-Link'овцев, есть ли шансы, что в новых прошивках появится возможность увеличить приоритет обработки пингов

Никто вменяемый не будет делать приоритет пинга выше, чем приоритет действительно важных процессов. Ну, там, обработка мультикаст подписок к примеру. Или STP. Или опции 82. Иначе - какой-то идиот, запустивший ping -f на ваши свичи, положит сеть. И даже инженеры длинка не будут. Неужели это не очевидно?

 

Например у нас в сети по ряду причин не используется протокол STP. Вместо этого свитчи управляются по snmp с центрального узла. Как только где-то обрывается линк, включаются порты на резерв, как только линк восстанавливается - резервные порты отключается.

Нужно ли объяснять, насколько важна скорость реакции свитча при восстановлении основного линка (т.е. фактически - при возникновении петли, стандартные средства разрешения которой отключены)?

Итого - имеем костыль вместо стандартного решения (*STP), при этом - реализованный через анус (ибо отключать передачу данных на портах, на которых линк оборван - к примеру снимать с них вланы - вы почему-то не хотите, вместо этого предпочитаете определять возникшее внезапно кольцо). Из чего делается вывод о насущной необходимости быстрого проца для свича.

Я даже боюсь представить - сколько раз в секунду вы опрашиваете свичи???

К слову, вопрос на засыпку: а если в момент восстановления линка от какого-то абонента повалит пачка IGMP, или к примеру ARP request'ов - где гарантия, что мозг свичей не засрется сим флудом, многократно умноженным колечком, и что свич ответит на ваши снмп пакеты? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Никто вменяемый не будет делать приоритет пинга выше, чем приоритет действительно важных процессов. Ну, там, обработка мультикаст подписок к примеру. Или STP. Или опции 82. Иначе - какой-то идиот, запустивший ping -f на ваши свичи, положит сеть.

меня вобще терзают смутные сомнения, что в лоукосте проц способен хоть на какую-то маломальскую многозадачность, ибо как только возрастает нагрузка на тот же снупинг или stp, control-plane отваливается целиком и полностью, а не только для пинга. у китайцев вобще замечен был грешок, когда определенные snmp-get пакетики провоцировали моментальную смерть control-plane, а snmp v2c poll пакеты провоцировали утечку и без того печально малой памяти. и в итоге остается один лишь dataplane, без снупингов, без stp, чистые вланы, а редкие экземпляры и вовсе в хаб превращались.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Итого - имеем костыль вместо стандартного решения (*STP)

Вы попросили привести практический пример, при котором тормознутость web-smart свитчей может стать проблемой.

Я такой пример привел.

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

 

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

Удачи Вам во всех Ваших начинаниях!

 

К слову, вопрос на засыпку: а если в момент восстановления линка от какого-то абонента повалит пачка IGMP, или к примеру ARP request'ов - где гарантия, что мозг свичей не засрется сим флудом, многократно умноженным колечком, и что свич ответит на ваши снмп пакеты? :)

Я даже представить себе боюсь что будет, если на такую задачу я поставлю D-Link DGS-12XX.

 

меня вобще терзают смутные сомнения, что в лоукосте проц способен хоть на какую-то маломальскую многозадачность, ибо как только возрастает нагрузка на тот же снупинг или stp, control-plane отваливается целиком и полностью, а не только для пинга. у китайцев вобще замечен был грешок, когда определенные snmp-get пакетики провоцировали моментальную смерть control-plane, а snmp v2c poll пакеты провоцировали утечку и без того печально малой памяти. и в итоге остается один лишь dataplane, без снупингов, без stp, чистые вланы, а редкие экземпляры и вовсе в хаб превращались.

Прятно осознавать, что все-таки есть люди, понимающие разницу между свитчами разных классов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Когда я в личной переписке спрашивал у D-Link'овцев, есть ли шансы, что в новых прошивках появится возможность увеличить приоритет обработки пингов, мне ответили, что шансов нет, так как ограничения там аппаратные и "он играет так, как может" (с)

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

 

Стоит ли брать DGS-1100-24 для небольшого офиса? От коммутатора кроме собственно коммутации пары серверов и двух десятков рабочих станций требуется возможность удаленно поглядеть жив порт или нет.

Разница между 1210 в том, что у 1210 есть манагемент влан и ещё какие то приятные мелочи. У 1500 приятных мелочей ещё больше. У самого 1210 и ниже брать точно смысла не вижу.

 

Я даже представить себе боюсь что будет, если на такую задачу я поставлю D-Link DGS-12XX.

Оно для дома и офиса. И дома и в офисе оно прекрасно работает: поставил, настроил и забыл. Даже вентиляторов нет.

Для всяких исп другие модели.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Например у нас в сети по ряду причин не используется протокол STP. Вместо этого свитчи управляются по snmp с центрального узла. Как только где-то обрывается линк, включаются порты на резерв, как только линк восстанавливается - резервные порты отключается.

Нужно ли объяснять, насколько важна скорость реакции свитча при восстановлении основного линка (т.е. фактически - при возникновении петли, стандартные средства разрешения которой отключены)?

это просто полный извращённый пипец! Больше сказать просто нечего

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.