Сообщений в теме: 5

[Sergiy Lapin]

Вот есть такая грусть.
С ростом количества узлов возникает проблема управления номерным планом и планирование межузлового трафика.

Пока узлов было менее 10, простая диаграма в MS Visio была достаточна.
Потом узлов стало 20 и диаграма стала не читабельная. Перешли на табличный способ описания в MS Excell.
А когда узлов стало больше 20, во всех этих таблицах стало практически невозможно разобраться.
Проблема осложняется необходимостью учета IP trunks с оглядкой на QoS.

Если у кого-то есть секретная методика, прошу поделиться опытом.

[Лушин Ролан]

напиши Олегу, может он чего подскажет. адрес дам если нет

[Andrew Zhukov]

Sergiy Lapin, on 17.9.2008, 20:07, said:

Вот есть такая грусть.
С ростом количества узлов возникает проблема управления номерным планом и планирование межузлового трафика.

Пока узлов было менее 10, простая диаграма в MS Visio была достаточна.
Потом узлов стало 20 и диаграма стала не читабельная. Перешли на табличный способ описания в MS Excell.
А когда узлов стало больше 20, во всех этих таблицах стало практически невозможно разобраться.
Проблема осложняется необходимостью учета IP trunks с оглядкой на QoS.

Если у кого-то есть секретная методика, прошу поделиться опытом.

Я не понимаю последнюю часть. При больших объемах таблицы или квадратики в VISIO уже не имеют смысла. Я просто мониторю RTP потоки, строю графики в обычном MRTG (для понтов можно RRD или чем то платном) и исходя из этого планирую транковые емкости.
Это ты хотел услышать?

[Sergiy Lapin]

Andrew Zhukov, on 24.9.2008, 12:33, said:

Я не понимаю последнюю часть. При больших объемах таблицы или квадратики в VISIO уже не имеют смысла. Я просто мониторю RTP потоки, строю графики в обычном MRTG (для понтов можно RRD или чем то платном) и исходя из этого планирую транковые емкости.
Это ты хотел услышать?

Не, мне так не подходит. У меня каналы бывают загружены по самые "помидоры" почтовым, web, SMB и прочим трафиком. Под голос отведено определенное количество полосы которое не должно превышаться ни при каком раскладе. Количество RTP потоков через каждый линк контролируется через Admission Control механизмы, частью которых являются виртуальные IP транки. Каждый отказ соединения по причине перегрузки регистрируется, так что вопрос планирования и мониторинга не представляет проблемы. Проблема как в удобоваримом виде документировать все эти транки и соединения. Мне нужно иметь возможность в любое время дня и ночи легко определить через какие узлы пройдет вызов из точки A в точку Z и какие ресурсы будут задействованы. Неужели во "взрослых" сетях нету методики? Я тут начал лепить базу в MS Access со скриптами реализуюшими решение стандартной транспортной задачи в целях изучения вопроса. Но просто не хочется изобретать велосипед.

[Andrew Zhukov]

Sergiy Lapin, on 25.9.2008, 0:34, said:

Не, мне так не подходит. У меня каналы бывают загружены по самые "помидоры" почтовым, web, SMB и прочим трафиком. Под голос отведено определенное количество полосы которое не должно превышаться ни при каком раскладе. Количество RTP потоков через каждый линк контролируется через Admission Control механизмы, частью которых являются виртуальные IP транки. Каждый отказ соединения по причине перегрузки регистрируется, так что вопрос планирования и мониторинга не представляет проблемы. Проблема как в удобоваримом виде документировать все эти транки и соединения. Мне нужно иметь возможность в любое время дня и ночи легко определить через какие узлы пройдет вызов из точки A в точку Z и какие ресурсы будут задействованы. Неужели во "взрослых" сетях нету методики? Я тут начал лепить базу в MS Access со скриптами реализуюшими решение стандартной транспортной задачи в целях изучения вопроса. Но просто не хочется изобретать велосипед.

Я вообще тяжко это воспринимаю. То есть, идет планирование NGN по TDM методике. Вырубаются все вкусности типа VAD, и компрессии голоса. Нет возможности придавить не real-time траффик. Круто. Дайте мне этому архитектору в глаза посмотреть.

Тут наверное люди с междугородок читали. Похоже точно нет.

Сообщение отредактировал Andrew Zhukov: 02 October 2008 - 12:12 PM

[Sergiy Lapin]

Andrew Zhukov, on 2.10.2008, 6:11, said:

Я вообще тяжко это воспринимаю. То есть, идет планирование NGN по TDM методике. Вырубаются все вкусности типа VAD, и компрессии голоса. Нет возможности придавить не real-time траффик. Круто. Дайте мне этому архитектору в глаза посмотреть.

Тут наверное люди с междугородок читали. Похоже точно нет.

Ну VAD имеет нехорошую привычку рубить начало фраз и с Music-on-Hold плохо дружит. Компрессия включена на медленных линках типа T1 и G.711u в LAN окружении. Компрессия активируется на основе принципа наименьшего деноминатора, если канал разговора пересекает медленный линк, то договариваемся на G.729A, если на всем пути между end-points нет медленных линков то используем G.711u.