Как стать автором
Обновить
0
0

Пользователь

Отправить сообщение
Самый большое недостаток всех этих IOU — это то, что тратится огромное время на troubleshooting вещей, которые в результате оказываются багами. В итоге вместо образовательный процесс получается рваный. К сожалению, альтернатив пока этому нет для тех кто не может себе позволить полноценную лабу.
Хотя есть один человек, Jeremy, который на благотворительных началах занимается разработкой «лабы для народа». Пока это еще в зачаточном состоянии правда, но идея очень привлекательная и можо поучаствовать в разработке, если кому интересно.
i86bi_linux-adventerprisek9-ms.152-4.M1 последний.
обычно если кто-то жалуется что не может найти файл, а он там есть — проблема в user/file permissions.
Самый свежий L2 image — i86bi_linux_l2-ipbasek9-ms.may8-2013-team_track
Еще есть интересный corner case в случае когда маршрут бывает 'connected' и с AD=1. Вроде в статье была оговорка про это. Но на всякий случай если будет интересно статья от конкурентов INE:
blog.ipexpert.com/2012/07/09/old-ccie-myths-static-route-to-the-interface/
1. не спорю что мультикаст пингуется. в случае ipmp сервер шлет пакет на 224.0.0.1, фиксирует первые пять, по-моему, хостов, кто ответил на него, заносит в список target host и потом каждого отдельно с помощью unicast ping проверяет.
2. вы написали что ipmp может работать в двух режимах. я написал, что это не совсем точно и что два режима, в которых ipmp может работать это link-based и llink+probe mode
ipmp со стороны маршрутизатора видится только как all-host multicast, на который он ( маршрутизатор) не должен отвечать, так как это не all-router multicast, а даже если ответит, то просто будет потом получать icmp ping и отвечать на них

и ipmp это скорее next-hop redundancy protocol, а не link aggregation, хотя и поддерживает агрегацию.
У вас несколько неточностей:
1. multicast адрес не пингуется, а используется для определения хостов в подести, которые потом в свою очередь пингуются.
2. link-based mode настроен всегда, когда настроен ipmp. то есть точнее два режима это link-based & link-based+probe-based.
3. последний `+` в строке с addif — лишний.
Но в таком случае для сбора QoS вы полагаетесь на то, что конечные устройства будут использовать RTCP, правильно? а на практике далеко не все устройства испольуют rtcp, соответственно qos метрик может не оказаться в CDR при необходимости.
И вам не кажется, что логичнее было бы рассматривать для истории прогнозирования не трое предыдущих суток, а один и тот же день недели за предыдущие недели. все таки профиль трафика ( даже аггрегированного) за разные рабочие дни сильно отличается и вторник будет больше похож на вторник прошлой недели, чем на понедельник.

А скажите почему вы не обсоновав забраковали IP SLA? чем он не подходит для транзитного оператора?
проблема в том, что mOTP нет на paypal, ebay, etc… решение на motp подойдет для личного или корпоративного ресурса
а по какому критерию? отсутствию RTP proxy? ну sipxecs же рассматривали…
интересно было бы еще в обзор openSER (KAMAILIO) включить.
Не надо путать два разных рынка. Я говорил про рынок ентерпрайз телефонии — там как раз, где связка asterisk-skype работает.
Судьба рынка конечных пользователей — большой вопрос. Если мелкософт прекратит поддержку для конкурентных ОС — то они потеряют большую долю этих самых пользователей, а это было бы очень глупо с их стороны, учитывая сколько денег они на это потратили.
По-моему, пока нет причин для паники. Это вполне ожидаемое событие. Lync и Asterisk являются прямыми конкурентами на рынке UC, поэтому решение мелкософта о прекращении сотрудничества с digium волне объяснимо и оправдано.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность