alibek Опубликовано 3 февраля, 2014 · Жалоба Навряд-ли можно выбрать лучший биллинг. Я бы предложил выбирать худшие, а затем выбрать из оставшегося списка. Например, я могу сказать, что плохого в Билл-Мастер от Inline. * У него нет внешнего API. * БД нормализована. Для БД это хорошо, но миграцию это усложняет. * Он заточен под ISG, на платформе Redback не все фичи будут работать из коробки. * Массовые операции возможны только по считанным сценариям. Если нужно добавить два десятка однотипных тарифов или запланировать массовую смену реквизитов абонентов — либо вводить вручную, либо лезть в БД. А ввод тарифов в этом биллинге сложный и долгий. * Саппорт мне не понравился. С типовыми задачами помогают хорошо, но когда стоит нестандартная задача (например управление скоростью в зависимости от двух или трех факторов, а не от одного), толку от саппорта мало. Все нестандартные решения приходилось придумывать самому, а саппорт только давал по ним заключения (не сломает ли это биллинг) и подсказывал с деталями. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
redds537 Опубликовано 3 февраля, 2014 · Жалоба О, спасибо, вот что-то типа таких отзывов реальных - это то, что нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
redds537 Опубликовано 3 февраля, 2014 · Жалоба Кто-нить что-нить по гидре плохого/хорошего скажите ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
redds537 Опубликовано 13 марта, 2014 · Жалоба Как я и предполагал - все "немножко" затянулось, ибо к-во интригаторов и предложений уже несколько больше, чем один штука ))) И лоббистов тоже больше одного. Поэтому выбор не так очевиден. Вроде как загорелось руководство цысками. Потому что они самые лучшие в мире. (может бюджет и остудит пыл в будущем...) Интригатор предложил вот такой свич: Nexus 3172P 48 X SFP+ and 6QSFP. Мне кажется, это как на рыбалку на БелАЗЕ ездить. Не ? ) Этот свич позиционируется для датацентров. Поэтому нужно доп.мнение не от интригаторов, а от независимых технарей, которые сами реально юзают цыски. Посоветуйте, плиз, какую цыску в так называемое "ядро", но не б/у. Напомню: 17 000 кастомеров Внешний трафик сейчас в ЧНН - 4Гбит/с (760 kpps) (ессно нужен запас - через год/два переплюнем 10G) Нужно 48 гигабитных портов SFP - собрать линки с районов. Нужно порт 10G - в брас подключить (желательно иметь 4 x 10G порта на будущее, хотя 2шт тоже пойдет). MAC Table 32K or higher. Роутить не предполагается на этом свиче. Но если надежно умеет роутить - это будет большим плюсом на всякий случай (особенно хорошо, если доп лицензией включается ) Больше от него ничего не нужно. Бюджет в данном случае не важен, всмысле - нужно подогнать технику под задачу, а не под бюджет. А дальше уже пусть боссы думают по деньгам - брать цыску, или экстримы или .... еще что-либо.... P.S. C брасом тоже весело - SE600 vs "цыско брас - пока вообще не ясно какой" Продолжение следует. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 13 марта, 2014 · Жалоба Если нужен только L2 функционал - я бы собирал транки с районов на длинках. А дальше либо 10G либо несколькими портами наверх. Плюсы следующие. Если ваша дорогая железка умрет -умрет все и сразу. Значит их нужно иметь две. Умрет длинк - умрет только часть сети. Снимаем с полки запасной длинк - через максимум полчаса - все ок. А если на районный свичи по несколькку линков идет - можно и кольца собрать какие либо. То же самое касается и каких либо проблем на сети (а они бывают) - все проблемы затронут только часть сети. Длинки нормально работают на L2. 3 штуки на 24 порта достаточно для ваших 48 линков на районы даже с запасом. 3-4 гигабита они успешно откоммутируют. Ну и цена конечно же. Хотите лучше - экстримы. Но они заметно дороже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
redds537 Опубликовано 13 марта, 2014 · Жалоба Эта позиция ясна. Но сейчас стадия такая, что нужно тупо выбрать цыску под задачу. И дальше будет видно, как отреагируют на бюджет, на сроки поставки, на сертификаты и т.д. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 13 марта, 2014 · Жалоба да есть: http://www.allot.com...way_SigmaE.html стоят в бою и уже давно, начинали с NetEnforcer'ов Жалко уведомления не приходят, я уж и забыл что спрашивал. Но странно видеть производителя у которого даташиты доступны после регистрации. Это как-то настораживает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EShirokiy Опубликовано 13 марта, 2014 · Жалоба тупо выбрать цыску а чем обусловлена хотелка циски? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsparill Опубликовано 14 марта, 2014 · Жалоба Кто-нить что-нить по гидре плохого/хорошего скажите ) Из хорошего: - после понимания работы, становится довольно удобной системой. - все то, что требовалось для работы (se100 + dhcp82 + всякие акции и т.д.) работает без проблем. - удобный интерфейс для работы, модульная система (правда кому-то модульность наверное не нравиться). - очень хорошая тех.по (нет отмазок как у LB) Плохое: - долго придется "вписываться" в понимание работы. - некоторые вещи (телефония) пока явно не сильно интегрированы в систему. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
papandopala Опубликовано 14 марта, 2014 (изменено) · Жалоба Уважаемые гуру! Прошу прощения если не в той теме. Подскажите пожалуйста или пните в нужном направлении... Имеется ядро сети нашего пионерНЭТа http://pixs.ru/showimage/2jpg_2798930_11216024.jpg Все сервера (billing,www, dns и т.д.) имеют default gw ip, поднятый на интерфейсе первого микротика. В случае землетрясения, пожара или выхода из строя Mik1 абоненты других микротиков останутся без связи. Как грамотно разрулить этот вопрос? Смотрел в сторону динамической маршрутизации BGP, OSPF, RIP. Динамические маршруты соседей анонсируются, но в случае отключения Mik1 пропадают - сервера вновь недоступны. Куда копать? Изменено 14 марта, 2014 пользователем papandopala Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
itmurom Опубликовано 14 марта, 2014 · Жалоба ... На картинке ничего не видно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
redds537 Опубликовано 14 марта, 2014 · Жалоба Кто-нить что-нить по гидре плохого/хорошего скажите ) Из хорошего: - после понимания работы, становится довольно удобной системой. - все то, что требовалось для работы (se100 + dhcp82 + всякие акции и т.д.) работает без проблем. - удобный интерфейс для работы, модульная система (правда кому-то модульность наверное не нравиться). - очень хорошая тех.по (нет отмазок как у LB) Плохое: - долго придется "вписываться" в понимание работы. - некоторые вещи (телефония) пока явно не сильно интегрированы в систему. спс Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
redds537 Опубликовано 14 марта, 2014 (изменено) · Жалоба тупо выбрать цыску а чем обусловлена хотелка циски? IMHO: Cisco - законадатель мод в различных нишах сетевого/телекоммуникационного оборудовании, огромный опыт у компании, отличные доки, отличный CLI, отличное качество продукции - первый эшелон, большое комьюнити. В конце концов CISCO - это уже религия с большой армией адептов/последователей. Ценник, соответственно, лупит в небо. Изменено 14 марта, 2014 пользователем redds537 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
papandopala Опубликовано 14 марта, 2014 · Жалоба На картинке ничего не видно. Прошу прощения, поправил Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EShirokiy Опубликовано 14 марта, 2014 · Жалоба redds537, чем L2 циска дучше L2 решений от Dlink? я так понимаю, что вам надо собирать все vlan и отправлять их на BRAS. Функционал нужен минимальный и как уже заметили выше, nexus в зипе выйдет очень накладно. За один такой ***с можно целый квартал застроить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 14 марта, 2014 · Жалоба Все сервера (billing,www, dns и т.д.) имеют default gw ip, поднятый на интерфейсе первого микротика. В случае землетрясения, пожара или выхода из строя Mik1 абоненты других микротиков останутся без связи. Как грамотно разрулить этот вопрос? Смотрел в сторону динамической маршрутизации BGP, OSPF, RIP. Динамические маршруты соседей анонсируются, но в случае отключения Mik1 пропадают - сервера вновь недоступны. Куда копать? Попробуйте подключить все сервера по VPN. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
redds537 Опубликовано 14 марта, 2014 · Жалоба redds537, чем L2 циска дучше L2 решений от Dlink? я так понимаю, что вам надо собирать все vlan и отправлять их на BRAS. Функционал нужен минимальный и как уже заметили выше, nexus в зипе выйдет очень накладно. За один такой ***с можно целый квартал застроить. Я не спорю. Абстрагируйтесь. Есть вопрос. Нужен ответ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 15 марта, 2014 · Жалоба Был случай, что пролезал броадкаст, но при каких-то условиях, воспроизвести не удалось. Бал случай, разобрались в причине. Причина - всплеск трафика на всех портах коммутатора агрегации, в сторону абонентов. Как будто кто-то штормит, наплевав на порт-сегментейшн. Это воспроизводится так: [ядро] -> [коммутатор агрегаци] -> [доступ] -> [абонент] Этот абонент, был знатным торрентодрочером, который по DHT был "знаком" многим абонентам сети. Так вот, абоненты вне этого коммутатора агрегации (выше), начинают посылать ему (торрентодрочеру) пакеты. Ядро (L3) по своей ARP-DB находит его, и отправляет пакеты на коммутатор агрегации (L2), но у него (комм. агр.) нет в FDB информации об маке торрентодрочера. Потому что последний никому отвечает! Соответственно он и не попадает в FDB коммутатора агрегации (а у комм. аггр. сегментация трафика на портах). Коммутатору приходится "широковещательно срать" во все порты, в поисках этого абонента, и не находить его, т.к. тот молчит. Возможно проблема в разном времени жизни записей в ARP-DB в ядре и в FDBна агрегации. Может этот торрентодрочер, раз в 5 минут отвечал, потом "затаивался". Фиг его знает. Мы забили. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 16 марта, 2014 · Жалоба Так вот, абоненты вне этого коммутатора агрегации (выше), начинают посылать ему (торрентодрочеру) пакеты. Ядро (L3) по своей ARP-DB находит его, и отправляет пакеты на коммутатор агрегации (L2), но у него (комм. агр.) нет в FDB информации об маке торрентодрочера. Потому что последний никому отвечает! Соответственно он и не попадает в FDB коммутатора агрегации (а у комм. аггр. сегментация трафика на портах). Коммутатору приходится "широковещательно срать" во все порты, в поисках этого абонента, и не находить его, т.к. тот молчит. Интересный поворот, спасибо. Правда у меня скорее всего не так, у меня PPPoE, но направление проверю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 16 марта, 2014 · Жалоба alibek, т.е. если в ядре статикой запить в ARP-DB IP+MAC, там же статикой добавить в FDB MAC+Port, и направить на комм. агрегации - то вот тебе вся модель. Остаётся из вне начать атаковать этот IP - получится флуд на все порты комм. агрегации, независимо от сегментации портов (но видимо VLAN должен быть на всех портах). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 16 марта, 2014 · Жалоба от, абоненты вне этого коммутатора агрегации (выше), начинают посылать ему (торрентодрочеру) пакеты. Ядро (L3) по своей ARP-DB находит его, и отправля Да это самая стандартная проблема несессионных моделей доступа. Просто люди привыкли строить локалки, а не операторские сети. Создал interface vlan, повесил сетку и понеслось! А потом жалуются на каких-то дрочеров. С PPPoE у вас такой проблемы не будет за счёт постоянного обновления fdb из-за ppp lcp keepalive Для IPoE тоже есть решения типа arp keepalive (периодический arp-ping). Но главное, что должно быть, нет сессии - нет трафика(любого, даже arp) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 16 марта, 2014 · Жалоба s.lobanov, не надумывайте проблем, их нет. Есть проблемы в проектировании, но они решаются при росте/апгрейде сети. Оверхеды от инкапсуляции тоннелей видимо не проблема :) Вам сессионность для чего? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дятел Опубликовано 16 марта, 2014 · Жалоба Для религиозный войн. И оправданий использования РРР, созданного для диалаповских скоростей... )) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 16 марта, 2014 · Жалоба В данном случае я не призываю использовать pppoe, а говорю о сессиях и их механизмах отслеживания абонентов. Ipoe сессии тоже сессии Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 16 марта, 2014 · Жалоба s.lobanov, прям ОРМ какие-то. Кипалайвы приходят к абоненту и отслеживают его :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...