Smoke Опубликовано 19 марта, 2010 · Жалоба Нам тут давеча продукт показывали с позиционированием как клиентский SLA для операторов. В том числе упоминали успешное развертывание на сети Комстара. Может есть здесь люди его пробывавшие? Интересуют больше не технические подробности (тут более/менее понятно), а интеграция в системы ведения trouble/ticket и плановых работ и их взаимоувязка. Ну то есть хочется иметь возможность накатить на существующие систему, так как альтернатива держать 2 аналогичные системы совсем не улыбает.. Вот тут прес релиз комстара Пресс-релиз Комстар Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 19 марта, 2010 · Жалоба Интересуют больше не технические подробности (тут более/менее понятно) Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Smoke Опубликовано 19 марта, 2010 · Жалоба Интересуют больше не технические подробности (тут более/менее понятно)Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;) Спрошу. пасиб. Тока на окончании енто не особо интересно, а вот в ядре надо проверять. Тем более что алгоритмы тестов скрыты в железе и оглашать их производитель не хочет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 19 марта, 2010 · Жалоба Спрошу. пасиб.Тока на окончании енто не особо интересно, а вот в ядре надо проверять. Тем более что алгоритмы тестов скрыты в железе и оглашать их производитель не хочет. Подскажу ответ: никак, они даже не понимают о чем речь. И когда вы их спросите, они будут увиливать от ответа, мол давайте лучше поговорим о коммерческой стороне вопроса.Если последняя миля ваша и вы точно знаете, что там нет EtherChannel-ов и не появится в будущем -- может быть и не интересно. Если чужая, то... Конторка эта мутная. Менеджерки много обещают, но по факту нифига сделать не могут. Тестирование они провалили :-) PS: а в комстаре наверно бюджет освоили, не более Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Smoke Опубликовано 19 марта, 2010 · Жалоба Спрошу. пасиб.Тока на окончании енто не особо интересно, а вот в ядре надо проверять. Тем более что алгоритмы тестов скрыты в железе и оглашать их производитель не хочет. Подскажу ответ: никак, они даже не понимают о чем речь. И когда вы их спросите, они будут увиливать от ответа, мол давайте лучше поговорим о коммерческой стороне вопроса.Если последняя миля ваша и вы точно знаете, что там нет EtherChannel-ов и не появится в будущем -- может быть и не интересно. Если чужая, то... Конторка эта мутная. Менеджерки много обещают, но по факту нифига сделать не могут. Тестирование они провалили :-) PS: а в комстаре наверно бюджет освоили, не более Ну на чужой миле SLA давать незачем. А вот если миля покупается для клиента то схема этой мили у нас должна быть всегда. Более того по хорошему нужно транслировать условия SLA на оператора последней мили. Сразу оговорюсь в практическую реализацию подписания SLA с оператором последней мили на просторах России верится с большим трудом. Бюджет освоили - ну скорей всего. Обычно это сопровождается каким-либо выхлопом с полезной инфой. вот на него я и рассчитывал. Вы его на MPLS натягивали или в плоской сети тестировали? агенты ставили в ядро или на доступ ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 19 марта, 2010 · Жалоба А вот если миля покупается для клиента то схема этой мили у нас должна быть всегда.Ну будет на схеме облако "сеть оператора XXX" - толку-то от него... Вы его на MPLS натягивали или в плоской сети тестировали? агенты ставили в ядро или на доступ ?Не вижу принципиальной разницы... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Smoke Опубликовано 19 марта, 2010 · Жалоба Ну будет на схеме облако "сеть оператора XXX" - толку-то от него... Облако неприменимо. Миля с облаком не будет предложена клиенту. По крайней мере я в эксплуатацию такой SLA не приму. Не вижу принципиальной разницы... Разница в агрегировании. если на PE включены 2 и более клиентов с клиентским SLA и кроме end-to-end нам нужно понимать где проблема на участке CE-PE или в ядре, возникает необходимость сводить несколько клиентских агентов на один около PE. MPLS агенты не понимают напрочь, то есть раздельной таблицы форвардинга там нет и в помине и общее ограничение в 100 VLAN тоже смущает. Есть подозрение, что изобретаю велосипед. Но подход такой. Одно решение - на всех. Зоопарк рождать я точно не хочу, если канеш за нас его не родят выше. P.S мы параллельно написали свой но там тоже есть проблемы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 19 марта, 2010 · Жалоба Ну будет на схеме облако "сеть оператора XXX" - толку-то от него...Облако неприменимо. Миля с облаком не будет предложена клиенту. По крайней мере я в эксплуатацию такой SLA не приму. Ок, пусть на схеме у оператора не облако, а два коммутатора. И один линк между ними, на момент рисования схемы. Но время-то не стоит на месте, когда-нибудь емкость этого линка закончится и оператор последней мили добавит второй линк, объединив их в etherchannel. А на схеме эти изменения отражены не будут.Поэтому лучше сразу рассматривать чужую сеть как облако, предполагая, что там может быть все что угодно. Не вижу принципиальной разницы...Разница в агрегировании. если на PE включены 2 и более клиентов с клиентским SLA и кроме end-to-end нам нужно понимать где проблема на участке CE-PE или в ядре, возникает необходимость сводить несколько клиентских агентов на один около PE. MPLS агенты не понимают напрочь, то есть раздельной таблицы форвардинга там нет и в помине и общее ограничение в 100 VLAN тоже смущает. Есть подозрение, что изобретаю велосипед. Но подход такой. Одно решение - на всех. Зоопарк рождать я точно не хочу, если канеш за нас его не родят выше. Кхм. Сделать экстранет с агентом у PE, заинджектить адрес агента в клиентские VPN. Агентам на сайтах выдавать специальные не пересекающиеся адреса и только их инджектить в этот экстранет. Как-то так. Итого один VLAN на всех. PS: end-to-end мне кажется перебором, кусочного мониторинга + сложения кусков в соответствии с Y.1541 (8.2.2/8.2.4) достаточно PPS: железка эта ОЕМ-ная, другие предлагают такуюже под своим брендом. различаются ли у них прошивки - не знаю, самому интересно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Smoke Опубликовано 19 марта, 2010 · Жалоба Я так понял что народу это не интересно. поэтому предлагаю уйти в приват. По первому вопросу - тут задача продуктологов и маркетинга, но она разрешима. Слава богу у нас есть инструмент "запрос о техничекой возможности" По второму - принцип не влезать в адресное пространство клиента должен работать дальше. Иначе наши VPN-щики повесятся. end-to-end вопрос позиционирования услуги. SLA должен работать. может правда выпить кружку пива вместе ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirya Опубликовано 19 марта, 2010 · Жалоба Давай Smoke, вытаскивай visir-я "на пиво". Хоть расскажешь, это реальный человек или корпоративный бот. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Smoke Опубликовано 19 марта, 2010 (изменено) · Жалоба Кирилл, не тупи, технический бэкграунд не шарится :) Изменено 19 марта, 2010 пользователем Smoke Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bitbucket Опубликовано 19 марта, 2010 · Жалоба Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;) Получается что при наличии EtherChannel про выполнение SLA можно забыть ? Забавно... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Smoke Опубликовано 19 марта, 2010 · Жалоба Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;)Получается что при наличии EtherChannel про выполнение SLA можно забыть ? Забавно... Нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 20 марта, 2010 (изменено) · Жалоба По первому вопросу - тут задача продуктологов и маркетингаНу то есть перекладываем ответственность за заранее известный провал на неспециалистов :-) По второму - принцип не влезать в адресное пространство клиента должен работать дальше.Тогда и железку свою нужно ставить в отдельный VLAN, идущий параллельно с клиентским.Но тут мониторинг становится еще менее реальным - а вдруг у оператора последней мили MSTP, или ECMP на пути l2circuit, и вланы пойдут по разным трассам ? :-) Не проще ли изыскать сеточку, которая ни одним VPN-щиком не используется... может правда выпить кружку пива вместе ?эт вы опоздали на пару часов с предложением :-) Кирилл, не тупиТупи Киря, тупи! ща вас затроллим :P Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;)Получается что при наличии EtherChannel про выполнение SLA можно забыть ? Забавно... Не выполнение, а мониторинг наипримитивнейшей системой. Разработчикам нужно поднапрячь извилины - все это реализуемо, но они, насмотревшись на ынтеграторов, этого делать не хотят - хотят только бабки рубить, не напрягаясь :-). Изменено 20 марта, 2010 пользователем visir Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 20 марта, 2010 · Жалоба Я так понял что народу это не интересно. поэтому предлагаю уйти в приват. Я не понимаю, но интересно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlexBT Опубликовано 21 марта, 2010 · Жалоба Не надо уходить в приват. Тоже не понятно, почему нельзя мониторить Ethernet Chanel по SLA. А посему интересно. Потому что на последней миле уже регулярно имеем место объединение двух 1GE в Ethernet Chanel. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 21 марта, 2010 (изменено) · Жалоба Тоже не понятно, почему нельзя мониторить Ethernet Chanel по SLA.А посему интересно. Балансировка нынче только per-session. В простейшем случае (Cisco) номер линка в который попадет конкретный пакет определяется формулой N = (src_ip ^ dst_ip ) % num_of_links_in_bundle. ('^' - xor, '%' - остаток от деления). В не простейшем в полином могуть попасть tcp/udp-порты, и подобное. У каждого вендора полином свой, секретный, делиться он им не хочет.Как при этом пойдут "пинги" между двумя SLA-пробниками с IP-ами X и Y ? - с большой вероятностью они всегда будут идти только по одному из линков каждого EtherChannel-а на пути. А трафик пользователя пойдет по всем. Получается не мониторинг, а эдакая профанация мониторинга. Изменено 21 марта, 2010 пользователем visir Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 21 марта, 2010 (изменено) · Жалоба Может я ошибаюсь, но что если попробовать на каждом физическом линке езерченнела сделать по одному уникальному влану ? Изменено 21 марта, 2010 пользователем Картуччо Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 21 марта, 2010 (изменено) · Жалоба Картуччо, яж уже написал про это: Разработчикам нужно поднапрячь извилины - все это реализуемо, но они, насмотревшись на ынтеграторов, этого делать не хотят - хотят только бабки рубить, не напрягаясь :-).PS: а на линках EtherChannel-а список виланов должен совпадать. Изменено 21 марта, 2010 пользователем visir Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlexBT Опубликовано 21 марта, 2010 · Жалоба Тогда остается один универсальный выход из положения. На критичных для SLA линков не должно быть никаких езернет чанелов. Представляющий последнюю милю должен это понимать и обеспечивать в рамках заключенного договора. Опять же, здесь должен быть двусторонний процесс движения обеих сторон. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CityFox Опубликовано 22 марта, 2010 · Жалоба Кто-нибудь тестировал ,или уже использует на своей сети, связку IXIA IxChariot + GeNiEnd2End или решение от Symmetricom - Q-Advisor ? Хотелось бы услышать мнения работавших с этими системами людей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 22 марта, 2010 · Жалоба Балансировка нынче только per-session. В простейшем случае (Cisco) номер линка в который попадет конкретный пакет определяется формулой N = (src_ip ^ dst_ip ) % num_of_links_in_bundle. ('^' - xor, '%' - остаток от деления). В не простейшем в полином могуть попасть tcp/udp-порты, и подобное. У каждого вендора полином свой, секретный, делиться он им не хочет.Как при этом пойдут "пинги" между двумя SLA-пробниками с IP-ами X и Y ? - с большой вероятностью они всегда будут идти только по одному из линков каждого EtherChannel-а на пути. А трафик пользователя пойдет по всем. Получается не мониторинг, а эдакая профанация мониторинга. Насколько я помню, обычно считается функция ip proto, src_ip, dst_ip или от ip proto, src_ip, dst_ip, src_port, dst_port. Причем для icmp порты не используются.Если взять несколько подряд идущих адресов и использовать icmp, то их все-таки размажет по разным линкам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 22 марта, 2010 · Жалоба Если взять несколько подряд идущих адресов и использовать icmp, то их все-таки размажет по разным линкам.Тссс!Вдруг пида ой, гении продающие эту чудо-систему прочитают. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cae Опубликовано 22 марта, 2010 · Жалоба Нам тут давеча продукт показывали с позиционированием как клиентский SLA для операторов.... так как альтернатива держать 2 аналогичные системы совсем не улыбает.. Видел вживую в одном банке российскую разработку - IQM. Интеграцию в zabbix, как сообщают разработчики, уже сделали. По остальным системам состояние интеграции надо уточнить.Замеряет задержки, джиттер, потери, полосу пропускания. Выполняет тесты по расписанию и по требованию. Что с EtherChannel и MLPPP - не знаю. Уточните, если есть интерес. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 22 марта, 2010 · Жалоба А если по пути вдруг езерченел с Layer 2 address only ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...