wiSLA

[Smoke]

Нам тут давеча продукт показывали с позиционированием как клиентский SLA для операторов. В том числе упоминали успешное развертывание на сети Комстара. Может есть здесь люди его пробывавшие? Интересуют больше не технические подробности (тут более/менее понятно), а интеграция в системы ведения trouble/ticket и плановых работ и их взаимоувязка. Ну то есть хочется иметь возможность накатить на существующие систему, так как альтернатива держать 2 аналогичные системы совсем не улыбает..

 

Вот тут прес релиз комстара

Пресс-релиз Комстар

[visir]

Интересуют больше не технические подробности (тут более/менее понятно)

Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;)

[Smoke]

Интересуют больше не технические подробности (тут более/менее понятно)

Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;)

Спрошу. пасиб.

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

[visir]

Спрошу. пасиб.

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

Подскажу ответ: никак, они даже не понимают о чем речь. И когда вы их спросите, они будут увиливать от ответа, мол давайте лучше поговорим о коммерческой стороне вопроса.

Если последняя миля ваша и вы точно знаете, что там нет EtherChannel-ов и не появится в будущем -- может быть и не интересно. Если чужая, то...

Конторка эта мутная. Менеджерки много обещают, но по факту нифига сделать не могут. Тестирование они провалили :-)

 

PS: а в комстаре наверно бюджет освоили, не более

[Smoke]

Спрошу. пасиб.

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

Подскажу ответ: никак, они даже не понимают о чем речь. И когда вы их спросите, они будут увиливать от ответа, мол давайте лучше поговорим о коммерческой стороне вопроса.

Если последняя миля ваша и вы точно знаете, что там нет EtherChannel-ов и не появится в будущем -- может быть и не интересно. Если чужая, то...

Конторка эта мутная. Менеджерки много обещают, но по факту нифига сделать не могут. Тестирование они провалили :-)

 

PS: а в комстаре наверно бюджет освоили, не более

Ну на чужой миле SLA давать незачем. А вот если миля покупается для клиента то схема этой мили у нас должна быть всегда. Более того по хорошему нужно транслировать условия SLA на оператора последней мили. Сразу оговорюсь в практическую реализацию подписания SLA с оператором последней мили на просторах России верится с большим трудом.

 

Бюджет освоили - ну скорей всего. Обычно это сопровождается каким-либо выхлопом с полезной инфой. вот на него я и рассчитывал.

Вы его на MPLS натягивали или в плоской сети тестировали? агенты ставили в ядро или на доступ ?

 

 

 

 

[visir]

А вот если миля покупается для клиента то схема этой мили у нас должна быть всегда.

Ну будет на схеме облако "сеть оператора XXX" - толку-то от него...

 

Вы его на MPLS натягивали или в плоской сети тестировали? агенты ставили в ядро или на доступ ?

Не вижу принципиальной разницы...

[Smoke]

Ну будет на схеме облако "сеть оператора XXX" - толку-то от него...

Облако неприменимо. Миля с облаком не будет предложена клиенту. По крайней мере я в эксплуатацию такой SLA не приму.

 

Не вижу принципиальной разницы...

 

Разница в агрегировании. если на PE включены 2 и более клиентов с клиентским SLA и кроме end-to-end нам нужно понимать где проблема на участке CE-PE или в ядре, возникает необходимость сводить несколько клиентских агентов на один около PE. MPLS агенты не понимают напрочь, то есть раздельной таблицы форвардинга там нет и в помине и общее ограничение в 100 VLAN тоже смущает.

 

Есть подозрение, что изобретаю велосипед. Но подход такой. Одно решение - на всех. Зоопарк рождать я точно не хочу, если канеш за нас его не родят выше.

 

P.S мы параллельно написали свой но там тоже есть проблемы.

[visir]

Ну будет на схеме облако "сеть оператора 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: железка эта ОЕМ-ная, другие предлагают такуюже под своим брендом. различаются ли у них прошивки - не знаю, самому интересно.

[Smoke]

Я так понял что народу это не интересно. поэтому предлагаю уйти в приват.

 

По первому вопросу - тут задача продуктологов и маркетинга, но она разрешима. Слава богу у нас есть инструмент "запрос о техничекой возможности"

По второму - принцип не влезать в адресное пространство клиента должен работать дальше. Иначе наши VPN-щики повесятся.

end-to-end вопрос позиционирования услуги. SLA должен работать.

 

может правда выпить кружку пива вместе ?

[Kirya]

Давай Smoke, вытаскивай visir-я "на пиво".

Хоть расскажешь, это реальный человек или корпоративный бот. :)

[Smoke]

Кирилл, не тупи, технический бэкграунд не шарится :)

Edited March 19, 2010 by Smoke

[bitbucket]

Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;)

Получается что при наличии EtherChannel про выполнение SLA можно забыть ? Забавно...

[Smoke]

Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;)

Получается что при наличии EtherChannel про выполнение SLA можно забыть ? Забавно...

Нет.

[visir]

По первому вопросу - тут задача продуктологов и маркетинга

Ну то есть перекладываем ответственность за заранее известный провал на неспециалистов :-)

 

По второму - принцип не влезать в адресное пространство клиента должен работать дальше.

Тогда и железку свою нужно ставить в отдельный VLAN, идущий параллельно с клиентским.

Но тут мониторинг становится еще менее реальным - а вдруг у оператора последней мили MSTP, или ECMP на пути l2circuit, и вланы пойдут по разным трассам ? :-)

Не проще ли изыскать сеточку, которая ни одним VPN-щиком не используется...

 

может правда выпить кружку пива вместе ?

эт вы опоздали на пару часов с предложением :-)

 

Кирилл, не тупи

Тупи Киря, тупи! ща вас затроллим :P

 

Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;)

Получается что при наличии EtherChannel про выполнение SLA можно забыть ? Забавно...

Не выполнение, а мониторинг наипримитивнейшей системой. Разработчикам нужно поднапрячь извилины - все это реализуемо, но они, насмотревшись на ынтеграторов, этого делать не хотят - хотят только бабки рубить, не напрягаясь :-). Edited March 20, 2010 by visir

[Sonne]

Я так понял что народу это не интересно. поэтому предлагаю уйти в приват.

Я не понимаю, но интересно.

[AlexBT]

Не надо уходить в приват.

Тоже не понятно, почему нельзя мониторить Ethernet Chanel по SLA.

А посему интересно.

Потому что на последней миле уже регулярно имеем место объединение двух 1GE в Ethernet Chanel.

[visir]

Тоже не понятно, почему нельзя мониторить Ethernet Chanel по SLA.

А посему интересно.

Балансировка нынче только per-session. В простейшем случае (Cisco) номер линка в который попадет конкретный пакет определяется формулой N = (src_ip ^ dst_ip ) % num_of_links_in_bundle. ('^' - xor, '%' - остаток от деления). В не простейшем в полином могуть попасть tcp/udp-порты, и подобное. У каждого вендора полином свой, секретный, делиться он им не хочет.

Как при этом пойдут "пинги" между двумя SLA-пробниками с IP-ами X и Y ? - с большой вероятностью они всегда будут идти только по одному из линков каждого EtherChannel-а на пути. А трафик пользователя пойдет по всем. Получается не мониторинг, а эдакая профанация мониторинга.

Edited March 21, 2010 by visir

[Картуччо]

Может я ошибаюсь, но что если попробовать на каждом физическом линке езерченнела сделать по одному уникальному влану ?

Edited March 21, 2010 by Картуччо

[visir]

Картуччо, яж уже написал про это:

Разработчикам нужно поднапрячь извилины - все это реализуемо, но они, насмотревшись на ынтеграторов, этого делать не хотят - хотят только бабки рубить, не напрягаясь :-).

PS: а на линках EtherChannel-а список виланов должен совпадать. Edited March 21, 2010 by visir

[AlexBT]

Тогда остается один универсальный выход из положения.

На критичных для SLA линков не должно быть никаких езернет чанелов.

Представляющий последнюю милю должен это понимать и обеспечивать в рамках заключенного договора.

 

Опять же, здесь должен быть двусторонний процесс движения обеих сторон.

[CityFox]

 

Кто-нибудь тестировал ,или уже использует на своей сети,

связку IXIA IxChariot + GeNiEnd2End или решение от

Symmetricom - Q-Advisor ?

Хотелось бы услышать мнения работавших с этими системами людей.

[dvolodin]

Балансировка нынче только 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, то их все-таки размажет по разным линкам.

[visir]

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

Тссс!

Вдруг пида ой, гении продающие эту чудо-систему прочитают.

 

[cae]

Нам тут давеча продукт показывали с позиционированием как клиентский SLA для операторов.

...

так как альтернатива держать 2 аналогичные системы совсем не улыбает..

Видел вживую в одном банке российскую разработку - IQM. Интеграцию в zabbix, как сообщают разработчики, уже сделали. По остальным системам состояние интеграции надо уточнить.

Замеряет задержки, джиттер, потери, полосу пропускания. Выполняет тесты по расписанию и по требованию. Что с EtherChannel и MLPPP - не знаю. Уточните, если есть интерес.

[Картуччо]

А если по пути вдруг езерченел с Layer 2 address only ?