Jump to content
Калькуляторы

wiSLA клиентский SLA в сети оператора

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Интересуют больше не технические подробности (тут более/менее понятно)
Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;)

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

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

Share this post


Link to post
Share on other sites
Спрошу. пасиб.

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

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

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

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

 

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

Share this post


Link to post
Share on other sites
Спрошу. пасиб.

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

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

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

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

 

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

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

 

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

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

 

 

 

 

Share this post


Link to post
Share on other sites
А вот если миля покупается для клиента то схема этой мили у нас должна быть всегда.
Ну будет на схеме облако "сеть оператора XXX" - толку-то от него...

 

Вы его на MPLS натягивали или в плоской сети тестировали? агенты ставили в ядро или на доступ ?
Не вижу принципиальной разницы...

Share this post


Link to post
Share on other sites
Ну будет на схеме облако "сеть оператора XXX" - толку-то от него...

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

 

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

 

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

 

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

 

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

Share this post


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

Share this post


Link to post
Share on other sites

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

 

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Edited by Smoke

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;)
Получается что при наличии EtherChannel про выполнение SLA можно забыть ? Забавно...

Нет.

Share this post


Link to post
Share on other sites
По первому вопросу - тут задача продуктологов и маркетинга
Ну то есть перекладываем ответственность за заранее известный провал на неспециалистов :-)

 

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

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

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

 

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

 

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

 

Напрасно. Спросите у них, как они будут мониторить SLA через EtherChannel ;)
Получается что при наличии EtherChannel про выполнение SLA можно забыть ? Забавно...

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

Share this post


Link to post
Share on other sites
Я так понял что народу это не интересно. поэтому предлагаю уйти в приват.

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites
Тоже не понятно, почему нельзя мониторить 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 by visir

Share this post


Link to post
Share on other sites

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

Edited by Картуччо

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

 

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

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

Symmetricom - Q-Advisor ?

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

Share this post


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

Share this post


Link to post
Share on other sites
Если взять несколько подряд идущих адресов и использовать icmp, то их все-таки размажет по разным линкам.
Тссс!

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

 

Share this post


Link to post
Share on other sites
Нам тут давеча продукт показывали с позиционированием как клиентский SLA для операторов.

...

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this