раскрыть ветку (32)
раскрыть ветку (28)
раскрыть ветку (25)
раскрыть ветку (24)
раскрыть ветку (23)
раскрыть ветку (20)
А можно мне, просто для понимания, чего есть такого у циски чего нет у других?
Мне правда интересно т.к. работал на уровне SMB/indastrial и в этих сегментах циска сильно так себе.
раскрыть ветку (19)
Удобство использования цельной архитектуры под широкий спектр задач. Т.е. аналогов-то им хреновы горы, но вот начинаешь состыковывать эти аналоги, и начинается веселье, иногда не решаемое в принципе, но ты не можешь этого знать, пока уже не залезешь вглупь.
раскрыть ветку (14)
А можно более менее живой пример?
Ну то есть при решении какой задачи у циски проблем не будет а средненький конкурент практически наверняка будет проблемным?
Просто циска она разная. если в cisco ios были отличные логи и понятная логика - нестандартная но понятная. То берешь асу и в ней общего только кнопки в терминале, катались третья хрень,
раскрыть ветку (13)
ну вот мой кейс, один из - есть один большой пров, по всему питеру. мы заказали для себя там отдельную подсеть, настроили бгп на микротах по филиалах (и нет, я не про беленькие роутеры, я про большие и дорогие шлюзы), а на головном был джунипер. и вот мы уходим с астериска на циско, телефоны по головному офису работают шикарно, трафик по филиалам работает супер, а вот телефония стала говным говно. при этом на астериске всё было +- ок, но там свои неудобства. уже плюнули, по резервному каналу пустили, через маленький чёрный микрот, вместо джуна, чтоб хоть как-то. наняли цискосертифицированного, вдруг мы косорукие - ничего. в итоге пришлось менять джунипер на асу, тогда всё завертелось.
раскрыть ветку (12)
Ну не знаю, для начала это выглядит не как кейс сетевика, а как жалоба пользователя. То есть присутствует куча оборудования у которого вместе проблема и вы не изолируете проблему а меняете куски. Что у вас было - какой-то трафик не проходил? Или у вас NAT и джун неправильно правит sip? Или вам nat не нужен, но джун все равно правит sip без спроса? При этом насколько я понял в одновендорной схеме только на микротике все работает. А вся задача - тупо бордер с bgp.
раскрыть ветку (11)
ну так просили живой пример? ) там всё упиралось в то, что бродкастом телефоны должны были слать регистрацию на сервер. но овер 1к телефонов - это нехилый такой бродкаст, его ограничивали на нужные транки, и тут начиналось веселье с вланами, при смене номера джунипер то рвал бродкаст, то рвал сип, а фиксированные номера вланов провайдер выдать нам не мог, у них там было с районными узлами всякое странное, типа распределение нагрузки на арендованных сетях, и бла-бла-бла. я могу углубиться в эту историю, и рассказать подробней, но есть ли смысл? в общем вот живой пример.
раскрыть ветку (9)
Варить в одном бродкаст-домене тысячу устройств и пинять на оборудование/провайдера. Супер кейс.
раскрыть ветку (8)
раскрыть ветку (7)
В целом писанина которую Вы написали похожа на бессвязный набор слов. Регистрации "бродкастом" в sip не бывает, "рвать бродкаст" это вообще что и как? Что бы что-то рвать надо что-то соединять, бродкаст по своей сути не подразумевает соединения
раскрыть ветку (6)
Ну если из написанного читать только знакомые слова, то наборы всегда бессвязны. Телефоны при включении бродкастят для получения настроек с сервера по тфтп, при обрыве сип-соединения они снова бродкастят для получения новых настроек. Также они бродкастят по тайм-ауту.
раскрыть ветку (5)
Ну это уже больше похоже на правду. Только всетаки не сип-соединения а пропадании регистрации? Тогда возникает вопрос нахрена вы бродкастовые реквесты dhcp гоняете через провайдера с 1000 устройств. Растягивание L2 сегментов это всегда хреновая идея кроме вынужденных костылей например в CDN между дата-центрами
раскрыть ветку (4)
Вы читать вообще не хотите? Где я писал про DHCP? При чем там DHCP если я про другое вообще? Блять, ненавижу сетевиков - каждый первый с таким чсв, что все мудаки криворукие, одни они короли, но сами даже осмыслить написанное не могут. Лицензия на сервер телефонии одна. И там не DHCP реквесты, там телефон берет настройки самого сип соединения, ещё раз говорю, с сервера этой самой телефонии. Бродкастит tftp и забирает с него файл настроек сип по своему маку. И нет, всё валится именно в момент, когда бродкаст запрос подтверждения настроек идёт в момент сип передачи.
раскрыть ветку (3)
Бродкастит arp, броткастит dhcp в котором какраз и прилетает опция с указанием tftp сервера. Ненавижу дилетантов которым впадлу разобраться в проблеме и в механизме работы сервиса,а потом сидят и пиняют то на вендора то на провайдера. Рукожоп
раскрыть ветку (2)
Ой кусок... Ты с госами не работал никогда видимо? Кто тебе даст хоть что-то внести в DHCP, которым не ты заведует? Если б было так просто...
раскрыть ветку (1)
кстати, мне вот интересно - я ни разу не сетевик, факт. я тот, кто видит только последние мили, своё оборудование, и в принципе в основном по серверам. и порой для меня начинаются загадки, когда спрашиваю друга-сетевика, в чём проблема с тем-то, связанным с сетями, а он мне в ответ - это не проблемы с сетью, это юзеркейс. в моём понимании, если трафик идёт хер пойми как и какой - это проблемы сетевика, если проблемы начинаются на шлюзе - это юзеркейс. я прав, или градация другая?
экосистема готовых продуктов - все гарантированно будет работать, если настраивается знающими людьми без особых костылей.
как пример - надо запилить сеть внутри офисов, раскиданных в разных районах города\городах, внутри сети сделать IP-телефонию, бесшовный вайвай с авторизацией для гостей и ситемой доступа для своих. плюс аппаратные файрволлы\шлюзы\другие подобные железки.
дешевле купить все нужные продукты у одного вендора, чем у кучи разных и потом пытаться скрестить ужа с ежом.
раскрыть ветку (2)
раскрыть ветку (1)
ну они больше про soho, хотя на их беспроводных железках вполне себе строятся сети в пару тысяч абонентов
раскрыть ветку (1)
Ну как минимум всё зависящее от активной подписки(удалённо отключаемой в любой момент) начнёт переезжать пускай на менее удобные и более дорогие, но аналоги.
Условные FC-коммутаторы действительно вырядил будут менять.
IT-юмор
7.4K постов53.3K подписчика
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору