Смена ip адреса на CUCM, UCCX, CPLM 11 версии

Имеем: развернутую инфраструктуру Cisco unified communication manager, Cisco Unified Contact Center Express, Cisco Prime License manager 11 версии. Всё это добро развернуто на ESXi v6,5 с лицензией Enterprise +

Требуется перевести дествующую систему в новую подсеть. На CUCM и UCCX операцию будем проводить с помощью инструментария Cisco prime collaboration deployment (CPCD), который специально разработан для управления приложениями Unified Communications (UC). CPCD позворляет производить установку, миграцию на новую версию, смену ip адреса и имени (перед работами обязательно уточнить поддерживаемые операции для различных версий UC).

Для начала заходим на CPCD и заводим ESXi хост(ы), где располагаются требуемые UC приложения. Меню Inventory, затем нажимаем Add new ESXi host

Добавляем кластеры UC над которыми планируем проводить работы, Inventory-Clusters, затем Define new cluster.

*Имя ни на что не влияет, будет использоваться внутри CPCD

Нажимаем Далее, если в следующем окне ничего не покано, нажимаем Add node.

Заполняем поля в зависимости от типа продукта, над которым будут происходить мануляции.
Нажимаем Далее и делаем то что от нас требует CPCD.

На последнем этапе можно еще раз проверить все ваши настройки, также следует обратить внимание на цвет галочки напротив каждого пункта, если она зеленая, то все хорошо и смело жмем финиш. Итог будет выглядеть так

Приступаем к созданию требуемого задания для CPCD, меню Tasks-Readdress.

• В первом шаге выбираем кластер с UC приложениями
• Во втором указываем указываем новые ip адреса и т.д.
• В третьем выбираем время запуска задачи. Можно запланировать выполнения задачи на определенной время, а можно выбрать Start task manualy, задача успешно добавиться, но будет ждать пока ее не запустят вручную.
• Нажимаем Далее, в последнем шаге можно еще раз все проверить, так же обащаем внимание на цвет галочки.

Теперь для запуска процесса осталось перейти в Monitoring, выбрать нашу задачу и нажать Start. Итог выполнения тасков ниже.

Продолжеине следует......

Смена пароля через RDP

Как изменить пароль пользователя Windows?

1. Для локальной машине ctrl+alt+del
2. Для rdp сессии cntl+alt+end
3.1 Для двойной rdp сессии cntrl+shift+alt+end
3.2 Если предыдущая комбинация не сработала можно попробовать так:
Нажимаем Start -> пишем osk (вызов виртуальной клавиатуры). После того, как виртуальная клавиатура откроется, нажимаем ctrl+alt на физической клавиатуре и del на виртуальной.
И нажимаем Change password.

Loopback interface and Policy Base Routing

Дано: есть две локации соединенных независимыми l2vpn линками, маршрутизация осуществляетсяна основе OSPF. Как настроена маршрутизация через балансинг или приоритет одному из каналов - не важно.
Необходимо:Что бы трафик от одного Loopback адреса гарантировано шел через одного провайдера, а трафик с другого Loopback адреса - шел через другого провайдера. Нужно в целях мониторинга каналов, что бы исключить ложные срабатывания (хотя вероятность этого весьма мала) при нестабильности одного из провайдеров.

Маршрутизация на основе адреса источника достаточно широко освещена в интернете и делается через Policy-based routing и Route-map.
Policy-based routing представляет собой инструмент для передачи и маршрутизации трафика основываясь на заданных политиках. PBR позволяет строить политики основываясь на ACL, размере пакета и т.д.
Route-map это объект в конфигурационном файле с помощью которого можно настраивать различный функционал PBR, BGP апдейты и т.д. Route-map всегда используется на входящем интерфейсе и не имеет никакого влияния на трафик на исходящем интерфесе.

Ниже незамысловатая схема и настройки для требуемой задачи, без маршрутизации и прочего.

Тестовый стенд

R1

R3

interface Loopback0 ip address 10.1.1.1 255.255.255.255 ip policy route-map PBRtest ! interface Loopback1 ip address 10.1.1.2 255.255.255.255 ip policy route-map PBRtest ! interface FastEthernet0/0 ip address 1.1.1.1 255.255.255.0 ! interface FastEthernet0/1 ip address 6.6.6.1 255.255.255.0 secondary ip address 5.5.5.1 255.255.255.0 ! access-list 10 permit 10.1.1.1 access-list 20 permit 10.1.1.2 ! route-map PBRtest permit 10 match ip address 10 set ip next-hop 5.5.5.2 ! route-map PBRtest permit 20 match ip address 20 set ip next-hop 1.1.1.2 ! ip local policy route-map PBRtest !

interface Loopback0 ip address 7.7.7.7 255.255.255.255 ! interface FastEthernet0/1 ip address 2.2.2.3 255.255.255.0

Route-map по логике работы чем-то напоминает ACL. Как и ACL имеют порядковые номера (для удобства использования); производят оценку по списку до тех пор, пока не найдено совпадение первого оператора и затем выполняется соответствующее действие.

route-map PBRtest permit 10	название карты действие порядковый номер
match ip address 20	правило сравнения: соответствует всем ip адресам из ACL 20
set ip next-hop 1.1.1.2	устанавливает действия: следующий хоп для пакетов из ACL 20
ip policy route-map PBRtest	применяем нашу карту на требуемых интерфейсах

Route-map работает только с входящим трафиком, и трафик от Loopback интерфеса не будет обрабатываться route-map'ом, так как является локально сгенерированным.
Чтобы заставить route-map работать с локально сгенерированным трафиком (loopback interface, gre и т.д.) требуется глобально включить ip local policy route-map PBRtest. ip local policy позволяет указать только одну карту маршрутизации, поэтому правила соответствия Loopback интерфейсов записаны в одну route-map, с разными порядковыми номерами.

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

R1#debug ip policy
Policy routing debugging is one

*Mar  1 00:16:32.275: IP: s=10.1.1.1 (local), d=2.2.2.3, len 100, policy match
*Mar  1 00:16:32.275: IP: route map PBRtest, item 10, permit
*Mar  1 00:16:32.275: IP: s=10.1.1.1 (local), d=2.2.2.3 (FastEthernet0/1), len 100, policy routed
*Mar  1 00:16:32.279: IP: local to FastEthernet0/1 5.5.5.2
*Mar  1 00:16:32.307: IP: s=10.1.1.1 (local), d=2.2.2.3, len 100, policy match
*Mar  1 00:16:32.307: IP: route map PBRtest, item 10, permit

*Mar  1 00:16:36.647: IP: s=10.1.1.2 (local), d=2.2.2.3, len 100, policy match
*Mar  1 00:16:36.647: IP: route map PBRtest, item 20, permit
*Mar  1 00:16:36.647: IP: s=10.1.1.2 (local), d=2.2.2.3 (FastEthernet0/0), len 100, policy routed
*Mar  1 00:16:36.651: IP: local to FastEthernet0/0 1.1.1.2
*Mar  1 00:16:36.835: IP: s=10.1.1.2 (local), d=2.2.2.3, len 100, policy match
*Mar  1 00:16:36.835: IP: route map PBRtest, item 20, permit

policy routed значит что пакет ушел согласно нашей карты, policy rejected — normal forwarding значит, что пакет пошел согласно глобальной таблицы, т.е. наше правило не работает.
Можно проверить классически через команду show.

R1#sh route-map PBRtest
route-map PBRtest, permit, sequence 10
  Match clauses:
    ip address (access-lists): 10
  Set clauses:
    ip next-hop 5.5.5.2
  Policy routing matches: 5 packets, 570 bytes
route-map PBRtest, permit, sequence 20
  Match clauses:
    ip address (access-lists): 20
  Set clauses:
    ip next-hop 1.1.1.2
  Policy routing matches: 5 packets, 570 bytes

И в том и в другом случае видно, что пакеты идут как нам нужно, карта работает.

Для лучшего понимания мехнизма работы PBR и Route-map, следует ознакомиться с документацией: Understanding Policy Routing Route-Maps for IP Routing Protocol Redistribution Configuration

P.S. для правильной работы сети и понимания работы применяемых механизмов, лучше всего подходят официальные документы.