По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой заключительной статье о перераспределении маршрутов мы проверим работу Route redistribution с помощью IPv6 и увидим небольшое отличие в настройке routes redistributed IPv6 от routes redistributed IPv4.
Предыдущие статьи из цикла:
Часть 1. Перераспределение маршрутов (Route redistribution)
Часть 2. Фильтрация маршрутов с помощью карт маршрутов
Часть 3. Перераспределение маршрутов между автономными системами (AS)
Перераспределение подключенных сетей
Во-первых, рассмотрим маршрутизатор, выполняющий маршрутизацию, предположим, что используется протокол OSPF. Кроме того, предположим, что маршрутизатор имеет несколько интерфейсов, которые участвуют в маршрутизации OSPF. Представьте, что на этом же маршрутизаторе мы запускаем другой протокол маршрутизации (скажем, EIGRP), и мы делаем взаимное перераспределение маршрутов.
Вот что удивительно. Если мы делаем перераспределение маршрута на этом маршрутизаторе, сети IPv4, связанные с интерфейсами этого маршрутизатора, участвующими в OSPF в нашем примере, будут перераспределены в EIGRP. Однако сети IPv6, будут вести себя по-другому. В частности, в сетях IPv6 мы должны ввести дополнительный параметр в нашу конфигурацию перераспределения маршрутов, явно указывая, что мы хотим перераспределить подключенные сети. В противном случае эти маршруты IPv6, связанные с непосредственно с подключенными интерфейсами, не перераспределяются.
Логика такого поведения вытекает из понимания того, что для перераспределения маршрута данный маршрут должен появиться в таблице IP-маршрутизации маршрутизатора. Конечно, когда посмотрим таблицу IP-маршрутизации маршрутизатора и увидим непосредственно подключенные сети, эти сети отображаются как подключенные сети, а не сети, которые были изучены с помощью определенного протокола маршрутизации.
В то время как route redistribution для IPv4 понимает, что сеть напрямую подключена, но участвует в процессе маршрутизации и поэтому будет перераспределена, route redistribution для IPv6 не делает такого предположения. В частности, если мы перераспределяем сети IPv6 из одного протокола маршрутизации в другой, эти сети должны отображаться в таблице маршрутизации IPv6 маршрутизатора вместе с указанием, что они были изучены с помощью перераспределяемого протокола маршрутизации. Конечно, мы можем добавить дополнительный параметр к нашей команде redistribute, чтобы заставить эти непосредственно подключенные сети IPv6 (участвующие в распространяемом протоколе) также быть перераспределенными. Эта настройка будет продемонстрирована немного позже.
Перераспределение в OSPF
В прошлой статье мы обсуждали потенциальную проблему, с которой вы можете столкнуться при распространении в OSPF (в зависимости от вашей версии Cisco IOS). Проблема была связана с подсетями. В частности, по умолчанию в более старых версиях Cisco IOS OSPF только перераспределяет классовые сети в OSPF, если мы не добавим параметр subnets к команде redistribute. Добавление этого параметра позволило перераспределить сети в OSPF, даже если у них не было классовой маски. Пожалуйста, имейте в виду, что последние версии Cisco IOS автоматически добавляют параметр подсети, не требуя от вас ручного ввода.
Однако параметр подсети в IPv6 route redistribution отсутствует. Причина в том, что IPv6 не имеет понятия о подсетях.
Пример route redistribution IPv6
Чтобы продемонстрировать перераспределение маршрутов IPv6, рассмотрим следующую топологию:
Протоколы маршрутизации OSPFv3 и EIGRP для IPv6 уже были настроены на всех маршрутизаторах. Теперь давайте перейдем к маршрутизатору CENTR и настроим взаимное route redistribution между этими двумя автономными системами. Убедимся в этом, проверив таблицу маршрутизации IPv6 маршрутизатора CENTR.
Приведенные выше выходные данные показывают, что мы изучили две сети IPv6 через OSPF, две сети IPv6 через EIGRP, а CENTR напрямую подключен к двум сетям IPv6. Далее, давайте настроим взаимное перераспределение маршрутов между OSPFv3 и EIGRP для IPv6.
CENTR # conf term
Enter configuration commands, one per line. End with CNTL/Z.
CENTR (config)# ipv6 router eigrp 1
CENTR (config-rtr) # redistribute ospf 1 metric 1000000 2 255 1 1500?
include-connected Include connected
match Redistribution of OSPF routes
route-map Route map reference
cr
CENTR (config-rtr) #redistribute ospf 1 metric 1000000 2 255 1 1500 include-connected
CENTR (config-rtr) #exit
CENTR (config) # ipv6 router ospf 1
CENTR (config-rtr) #redistribute eigrp 1?
include-connected Include connected
metric Metric f or redistributed routes
metric-type OSPF/IS-IS exterior metric type for redistributed routes
nssa-only Limit redistributed routes to NSSA areas
route-map Route map reference
tag Set tag for routes redistributed into OSPF
cr
CENTR (config-rtr) #redistribute eigrp 1 include-connected
CENTR (config-rtr) #end
CENTR#
Обратите внимание, что конфигурация взаимного перераспределения маршрутов, используемая для маршрутов IPv6, почти идентична нашей предыдущей конфигурации для перераспределения маршрутов IPv4. Однако для обеих команд перераспределения был указан параметр include-connected. Это позволило маршрутизатору CENTR перераспределить сеть 2003::/64 (непосредственно подключенную к интерфейсу Gig0/1 маршрутизатора CENTR и участвующую в OSPF) в EIGRP. Это также позволило маршрутизатору CENTR перераспределить сеть 2004::/64 (непосредственно подключенную к интерфейсу Gig0/2 маршрутизатора CENTR и участвующую в EIGRP) в OSPF.
Чтобы убедиться, что наша конфигурация рабочая, давайте перейдем на оба маршрутизатора OFF1 и OFF2, убедившись, что каждый из них знает, как достичь всех шести сетей IPv6 в нашей топологии.
Вышеприведенные выходные данные подтверждают, что маршрутизаторы OFF1 и OFF2 знают о своих трех непосредственно связанных маршрутах и трех маршрутах, перераспределенных в процессе маршрутизации. Итак, как мы видим, что когда речь заходит о routes redistributed IPv6, то не так уж много нового нужно узнать по сравнению с routes redistributed IPv4.
Мы уже рассказывали про функцию перехвата вызова Call Pickup в CUCM, и сегодня рассмотрим, как ее настроить в CME (CUCME) .
Функция Call Pickup позволяет вам отвечать на звонок, который приходит на другой телефон. Это выполняется при помощи нажатии клавиши (softkey) PickUp на телефоне, в то время пока звонит другой. Звонок автоматически переведется на ваш телефон, и вы сможете на него ответить. В больших организациях одновременно может быть очень много звонков, поэтому Call Pickup дает возможность разделять телефоны на группы, например по отделам. В зависимости от используемой клавиши вы сможете перехватывать звонки либо вызовы из своей группы перехвата, либо звонки из других групп.
Настройка
Настройка групп перехвата предельно проста – нужно распределить ephone-dn по группам перехвата.
CME# conf t
CME(config)# ephone-dn 1
CME(config-ephone-dn)# pickup-group 1111
CME(config-ephone-dn)# ephone-dn 2
CME(config-ephone-dn)# pickup-group 1111
CME(config-ephone-dn)# ephone-dn 3
CME(config-ephone-dn)# pickup-group 2222
CME(config-ephone-dn)# ephone-dn 4
CME(config-ephone-dn)# pickup-group 2222
После присвоения ephone-dn к группе перехвата, CME автоматически ее создает, поэтому нет необходимости вводить дополнительные команды. CME предоставляет три метода перехвата вызова:
Directed pickup: Вы можете перехватывать другой звонящий телефон, нажав на клавишу PickUp и набрав номер (DN) звонящего телефона. CME перенаправляет вызов и сразу отвечает на него уже на вашем телефоне;
Local group pickup: Вы можете перехватывать другой звонящий телефон в той же группе перехвата, что и ваш телефон. Для этого нужно нажать клавишу GPickUp и набрать *, когда услышите второй гудок;
Other group pickup: Вы можете перехватывать другой звонящий телефон в другой группе перехвата, нажав на клавишу GPickUp и введя номер другой группы, когда услышите второй гудок;
Если одновременно звонит несколько телефонов в группе перехвата, то при инициации перехвата CME отвечает на тот, который звонит дольше всего.
Функции клавиши GPickUp зависят от конфигурации групп перехвата. Если в CME настроена только одна группа перехвата, то при нажатии на клавишу GPickUp происходит автоматический ответ на выходящий звонок , без необходимости нажатия *.
По-умолчанию пользователи могут перехватывать звонки, используя метод directed pickup , вне зависимости присвоено ли устройство назначения группе перехвата. Чтобы отключить эту функцию нужно ввести команду no service directed-pickup из меню telephony-service configuration. После ввода этой команды, клавиша PickUp будет отвечать за перехват внутри локальной группы, и при нажатии на нее сразу будет происходить перехват.
Чтобы создать группы перехвата, используя CCP(Cisco Configuration Professional) , нужно перейти во вкладку Unified Communications – Telephony Features – Call Pickup Groups и нажать Create. Здесь также указываем номера групп, и какие телефоны будут в них включены. После создания группы нажимаем ОК и Deliver.
В сегодняшней статье речь пойдет о способах организации виртуальных частных сетей VPN (Virtual Private Network). VPN – это набор криптографических механизмов, обеспечивающих защищенный, двухсторонний канал для безопасной передачи данных через незащищенную сеть, такую как Интернет. Благодаря VPN пользователь может получить доступ к удаленной сети и работать с её ресурсами так, как если бы он находился внутри нее. Поэтому VPN получил широкое распространение у компаний, имеющих в своем штабе дистанционных сотрудников.
Терминология
VPN представляет собой соединение типа Point to point (точка-точка), которое принято называть “туннелем” (tunnel), а участников данного соединения – “пирами” (peer). Каждый пир шифрует данные, подлежащие передаче через туннель и дешифрует данные, которые получает из туннеля.
Если к одному пиру устанавливается несколько туннелей, то такой пир называется VPN – шлюзом, а сеть, находящаяся за ним – “доменом шифрования” (encryption domain). Несмотря на название, трафик внутри домена шифрования не шифруется, так как считается защищенным от попадания во внешнюю сеть. Кроме того, VPN – туннель может быть установлен между сетями.
Удаленный сотрудник, желающий настроить VPN - туннель с доменом шифрования своего офиса, должен установить на своей рабочей станции специальное ПО – VPN-клиент, например: OpenVPN, VyprVPN, TunnelBear и др.
Для большего понимания, на рисунке ниже отмечены все элементы, рассмотренные ранее:
Разберем основные принципы, по которым устанавливается VPN – соединение.
Перед установлением соединения пиры идентифицируют друг друга, чтобы удостовериться, что шифрованный трафик будет отправлен правильному получателю.
Пиры договариваются, по каким протоколам будет устанавливаться соединение для сохранения целостности и конфиденциальности данныхю
Создается ключ, который будет использоваться для шифрования и дешифрования данных
Существует множество механизмов, способных обеспечить выполнение данных функций, но мы рассмотрим самый распространенный - IPsec(IP Security).
IPsec – это целый набор протоколов, обеспечивающих сервисы приватности и аутентификации. Обычно в IPsec выделяют три основных протокола:
AH (Authentication Header) – протокол идентификации заголовка. Данный протокол обеспечивает защиту передаваемых данных от изменения, путем проверки каждого бита пакета после передачи. То есть обеспечивает функции целостности.
ESP (Encapsulating Security Protocol) Данный протокол обеспечивает не только функции целостности, но и конфиденциальности, путем добавления своего заголовка в пакет, подлежащий защите.
IKE (Internet Key Exchange protocol) – протокол обмена ключами. Данный протокол предназначен для автоматического генерирования, обновления и обмена ключами между участниками VPN – соединения.
В IPsec есть еще один важный термин – SA (Security Association). SA это непосредственно VPN – соединение в контексте IPsec. SA устанавливается сразу после того, как IPsec – узлы договорились и согласовали все параметры, по которым будет организован VPN – туннель.
Итак, VPN – соединение с использованием IPsec устанавливается в два этапа:
На первом этапе VPN – узлы идентифицируют друг друга и согласовывают алгоритмы шифрования, хэширования и аутентификации, после чего создается первый SA.
Второй этап возможен только после завершения первого. На втором этапе генерируются данные ключей и происходит согласование используемой политики. После завершения второй фазы формируется второй SA и все данные, подлежащие передаче, шифруются. Именно после второго этапа формируется VPN – туннель и установка считается завершенной.