PIX/ASA 7.x Пример конфигурации резервирования канала до провайдера : Программирование для всех. Языки программирования, программирование баз данных, технологии. Статьи для програмиста скачать бесплатно учебники книги документация форум : Статьи

Источник: www.ciscolab.ru

Проблема статической маршрутизации в том, что не существует наследованного механизма, позволяющего определить живой ли маршрут на сеть или нет. Маршрут остается в таблице маршрутизации даже если шлюз следующего хопа стал недоступен. Статический маршрут удаляется из таблицы роутинга только если соответствующий интерфейс упал на PIXе. Для того, чтобы решить данную проблему, используется функция слежения статических маршрутов, чтобы отслеживать доступность статического роута, и если маршрут не адекватен, удалить его из таблицы маршрутизации и заменить резервным.

Данный документ показывает пример того, как использовать функцию слежения для статических маршрутов на PIX или ASA для того, чтобы позволить оборудованию использовать резервное интернет соединение. В данном примере, слежение за статическим маршрутом позволяет оборудованию использовать недорогой канал связи к провайдеру, в случае, когда основной канал стал недоступен.

Для того, чтобы достичь такого резервирования, оборудование статический маршрут с целью мониторинга, определяемой заранее. Операции SLA (Соглашение об Уровне Услуг) мониторят цель периодическими ICMP Echo запросами, проще говоря, пингуют. Если не принят ICMP Echo ответ, объект рассматривается как “упавший” и соответствующий маршрут удаляется из таблицы роутинга. А вместо удаленного маршрута будет использоваться ранее сконфигурированный резервный маршрут. Во время использования резервного маршрута, SLA продолжает операцию мониторинга, пытаясь достичь цели. Как только цель снова стала доступной, резервный маршрут удаляется, а первоначальный маршрут вставляется обратно в таблицу маршрутизации.
Заметьте, конфигурация описанная в данном документе не может использоваться для балансирования нагрузки. Используйте данную конфигурацию только в целях резервирования. Исходящий трафик использует основного ISP, а затем вторичного ISP, если основной стал недоступен. Недоступность основного ISP приводит к временному прерыванию трафика.
Выберайте цель мониторинга которая может отвечать на ICMP Echo запросы. Это может быть удаленный хост, роутер или любой объект, но рекомендуется использовать цель по ближе к вашему ISP.

В данном примере, PIX обслуживает два соединения в Интернет. Первое соединение это высокоскоростная выделенная линия, которая доступна через роутер основного ISP. Второе соединение – это низкоскоростное DSL соединение, доступное через DSL модем второго ISP. В данной схеме не происходит балансировка нагрузки.

PIX/ASA 7.x Пример конфигурации резервирования канала до провайдера

DSL соединение свободно до тех пока, выделенная линия активна и доступен шлюз основного ISP. Однако, если соединение к основному ISP станет недоступным, оборудование изменит таблицу маршрутизации, чтобы направить трафик через DSL соединение. Для достижения такого резервирования используется слежение для статических маршрутов.

PIX конфигурируется со статическим маршрутом, который направляет весь Интернет трафик к основному ISP. Каждые 10 секунд SLA монитор проводит проверку того, что основной ISP шлюз достижим. Если SLA монитор определит, что основной шлюз стал недоступен, статический маршрут, направляющий трафик на этот интерфейс удаляется из таблицы. Для замены этого маршрута, в роутинговую таблицу инсталлируется альтернативный статический маршрут, направляющий трафик на второго провайдера. Альтернативный маршрут будет направлять трафик на второго ISP через DSL модем до тех пор, пока основной ISP снова не станет доступен.

Конфигурация PIX

!--- Этот интерфейс  подсоединен к основному ISP.
!
interface Ethernet0
nameif outside
security-level 0
ip address 10.200.159.2 255.255.255.248
!
!--- Этот интерфейс  подсоединен к второму ISP.
!
interface Ethernet1
nameif backup
security-level 0
ip address 10.250.250.2 255.255.255.248
!
interface Ethernet2
nameif inside
security-level 100
ip address 172.22.1.163 255.255.255.0
!
!--- NAT Конфигурации для  Outside и Backup
!
global (outside) 1 interface
global (backup) 1 interface
nat (inside) 1 172.16.1.0 255.255.255.0

!--- Введите следующую команду чтобы отслеживать статический маршрут.
!--- Это статический маршрут, инсталлируемый в таблицу маршрутизации пока отслеживаемый объект доступен
!--- Величина после слова  "track" это идентификатор слежения.

route outside 0.0.0.0 0.0.0.0 10.200.159.1 1 track 1

!--- Определяем резервный маршрут используемый когда отслеживаемый объект недоступен.
!--- Административная дистанция резевного маршрута должна быть больше чем административная дистанция
!--- отслеживаемого маршрута.

route backup 0.0.0.0 0.0.0.0 10.250.250.1 254

!--- Конфигурируем новый процесс мониторинга с  ID 123.
!--- Указываем протокол мониторинга и отслеживаемый сетевой объект чью доступность отслеживает процесс мониторинга.
!--- Указываем число пакетов высылаемых в каждом опросе и скорость с которой процесс повторяется

sla monitor 123
type echo protocol ipIcmpEcho 10.0.0.1 interface outside
num-packets 3
frequency 10

!--- Планирование процесса мониторинга
!--- В этом случае время жизни бесконечное. Мониторинг начинается  сразу как только введена команда

sla monitor schedule 123 life forever start-time now

!
!--- Связываем отслеживаемый статический маршрут с процессом SLA.
!--- track ID должен соответствовать  track ID у статического маршрута, а 123 - это ID процесса SLA

track 1 rtr 123 reachability

По материалам: www.cisco.com

При разработке CMS S.Builder наша команда активно использовала AJAX. Теперь вот решили поделиться накопленным опытом. Начнем с этого хабратопика. Не буду здесь затрагивать различные фреймворки и библиотеки. Свой код всегда роднее. Для работы с AJAX-ом в S.Builder написана библиотека sbAJAX. Можете качать и пользоваться :). В этом файле есть функция sbEvalJS. Для тех, кто не знает, объясню. При подгрузке через AJAX и вставке на страницу HTML-кода, содержащего JavaScript, JavaScript выполняться не будет или полезут баги. Эта функция как раз решает поставленную задачу.

Обзор нового релиза самой мощной Ajax библ....

Хотя наш обзор немного запоздал, оригинальный Dojo 1.2 вышел в релизной версии ещё 6-го октября, но сейчас мы наверстаем упущенное. И так, Dojo Toolkit — это самая мощная и гибкая ajax-библиотека из всех, что есть на рынке, она активно развивается и имеет большое комьюнити. Кстати, это самое комьюнити, совместно с компанией Sitepen, имеет ещё несколько проектов, среди которых и Cometd и некоторые другие, не менее интересные, о которых мы скоро вам расскажем. Сегодня же все внимание на флагманский продукт — Dojo 1.2.

Если вы профессиональный веб-разработчик и постоянно имеете дело с разработкой и отладкой сложных AJAX приложений, то наверняка знаете и используете Firebug — плагин для браузера Firefox, предназначенный для отладки и исследования веб-приложений. Текущая его версия, 1.2х достаточно стабильная и функциональна, чтобы помочь в 99% проблем, которые могут возникнуть при разработке. Но и этот инструмент не лишён если не недостатков, то некоторых фич, которые могли бы облегчить работу. И даже идеальный инструмент можно сделать ещё более идеальным, как бы это не звучало.