Исходное сообщение
"1 ISP 2  канала связи" Отправлено ShyLion, 26-Мрт-10 14:20
>[оверквотинг удален] >понять сохранить.....мне непонятно. > > >>Также не совсем понятно как IP телефония связана с каналами на провайдера >>- все диалпиры у тебя вовнутрь смотрят, либо ты чего-то не >>договариваешь. > >старый пул из 4 адресов 252 по нему телефония уходит в интернет >по дсл.....все договариваю, если что спросите конкретно.....даил пиры тут вообще не >приводил пока. Так в итоге надо чтобы оба пула были или один? Вообще раскидывать трафик в сторону провайдера - роутмапами на интерфейсах где ip nat inside стоит для трафика от клиентских сетей и ip local policy route-map для трафика, который генерит сама киса (только тут есть нюанс с тоннелями - тоннельный трафик, после инкапсуляции, под локальную политику не попадает. это известный баг и лечится только отдельным статическим маршрутом). Это source-based routing. Роутмапы можно еще оснастить ip sla + tracking. Провайдер в свою очередь должен будет прописать для разных пулов разные интерфейсы. В целом схема конечно получится громоздкая. Еще можно подумать насчет VRF - клиентов интернета и отдельный для них канал назначить на отдельный VRF и они будут жить вообще сами по себе.

Ваше сообщение
Имя*:
EMail:	Для отправки новых сообщений в текущей нити на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>[оверквотинг удален] >>понять сохранить.....мне непонятно. >> >> >>>Также не совсем понятно как IP телефония связана с каналами на провайдера >>>- все диалпиры у тебя вовнутрь смотрят, либо ты чего-то не >>>договариваешь. >> >>старый пул из 4 адресов 252 по нему телефония уходит в интернет >>по дсл.....все договариваю, если что спросите конкретно.....даил пиры тут вообще не >>приводил пока. > Так в итоге надо чтобы оба пула были или один? > Вообще раскидывать трафик в сторону провайдера - роутмапами на интерфейсах где ip > nat inside стоит для трафика от клиентских сетей и ip local > policy route-map для трафика, который генерит сама киса (только тут есть > нюанс с тоннелями - тоннельный трафик, после инкапсуляции, под локальную политику > не попадает. это известный баг и лечится только отдельным статическим маршрутом). > Это source-based routing. Роутмапы можно еще оснастить ip sla + tracking. > Провайдер в свою очередь должен будет прописать для разных пулов разные интерфейсы. > В целом схема конечно получится громоздкая. > Еще можно подумать насчет VRF - клиентов интернета и отдельный для них > канал назначить на отдельный VRF и они будут жить вообще сами > по себе.
	Введите код, изображенный на картинке: