По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Хотим рассказать о простом и быстром способе восстановить пароль администратора в графическом интерфейсе FreePBX 13. Для этого вам потребуется доступ к консоли сервера по протоколу SSH. Если вы так же не помните пароль на SSH доступ, то тогда вам необходимо подключиться к серверу путем консольного доступа (подключить монитор и клавиатуру), или открыть KVM окно в случае, если это виртуальная машина. Итак, если вы забыли пароль от FreePBX и спешите восстановить его – мы расскажем как это сделать.
Получаем ID PHP сессии
Восстанавливать доступ к FreePBX с помощью процесса amportal, который отвечает за управление FreePBX из под командной строки Linux
amportal a u xxxxxxxxxxxxxxxx
Команда выполняется с ключом ”u”, который означает unlock – разблокировку, а xxxxxxxxxxxxxxx – это ID PHP сессии. Чтобы его узнать, переходим на страницу входа в FreePBX по адресу http://IP_адрес_FreePBX/admin:
Теперь нажмите сочетание клавиш Ctrl + A, тем самым выделив всю рабочую область в окне браузера. В нижней части экрана вы увидите скрытые символы – это и есть ID вашей PHP сессии (на скриншоте ниже выделено красным). Скопируйте это значение:
Переходим в консоль сервера и даем команду вместе с полученным ID сессии:
[root@localhost ~]# amportal a u hrotp4v1qu87t7dhiu887jk9g7
Please wait...
!!!!amportal is depreciated. Please use fwconsole!!!!
forwarding all commands to 'fwconsole'
Unlocking: hrotp4v1qu87t7dhiu887jk9g7
Session Should be unlocked now
[root@localhost ~]# [root@localhost ~]#
Готово. Теперь возвращаем вкладку с FreePBX, где мы получили ID сессии, и обновляем страницу (нажмите F5). После обновления мы попадаем в административный интерфейс FreePBX. Теперь вы можете перейти во вкладку Admin -> Administrators, и создать там новые реквизиты администратора:
Третья статья будет посвящена поиску и устранению неисправностей EtherChannels. Большинство проблем с EtherChannels происходит из-за неправильной конфигурации.
Предыдущие статьи этого цикла:
Устранение неполадок коммутации Cisco
Траблшутинг STP (Spanning tree protocol)
Case #1
В этом сценарии есть только два коммутатора и два интерфейса. Идея состоит в том, чтобы сформировать etherchannel путем объединения интерфейсов FastEthernet 0/13 и 0/14, но это не работает
Сначала мы проверим, все ли интерфейсы работают. Да они все работают.
Мы можем проверить, что port-channel interface был создан, но он не работает.
Вот хорошая команда для проверки EtherChannel. Используйте суммарную информацию от команды show etherchannel summary, чтобы увидеть ваши port-channels. Мы видим, что коммутатор A настроен для LACP и коммутатор B для PAgP, а это никогда не будет работать.
Лучшая команда для использования это show etherchannel detail. Это дает вам много информации, но нам особенно интересно узнать, настроен ли LACP для пассивного или активного режима. Интерфейсы в активном режиме будут "активно" пытаться сформировать EtherChannel. Интерфейсы в пассивном режиме будут отвечать только на запросы LACP.
Вот вывод команды show etherchannel detail на коммутаторе B. Мы видим, что он был настроен для PAgP, и интерфейсы настроены для desirable режима. Если бы они были настроены на автоматический режим, мы бы увидели флаг А.
SwitchB(config)#no interface po1
SwitchB(config)#interface fa0/13
SwitchB(config-if)#channel-group 1 mode passive
SwitchB(config-if)#exit
SwitchB(config)#interface fa0/14
SwitchB(config-if)#channel-group 1 mode passive
Давайте сначала избавимся от port-channel interface. Если мы этого не сделаем, вы увидите ошибку при попытке изменить channel-group mode на интерфейсах.
После изменения конфигурации мы видим, что port-channel1 поднялся. Задача решена!
Извлеченный урок: убедитесь, что вы используете один и тот же режим EtherChannel с обеих сторон.
Case #2
Ну что же давайте рассмотрим другую ошибку! Та же топология и EtherChannel, который не функционирует:
Мы проверяем, что port-channel interface существует, но он не работает с обеих сторон.
Мы также видим, что интерфейс FastEthernet 0/13 и 0/14 были добавлены к port-channel interface.
Интерфейсы FastEthernet рабочие, поэтому мы знаем, что проблема не в этом. Давайте углубимся в конфигурацию EtherChannel.
Мы видим, что FastEthernet 0/13 и 0/14 на коммутаторе A оба настроены на автоматический режим PAgP (из-за флага "A").
FastEthernet 0/13 и 0/14 на коммутаторе B также настроены на автоматический режим PAgP. Это никогда не сбудет работать, потому что оба коммутатора теперь пассивно ждут сообщений PAgP.
SwitchB(config)#interface fa0/13
SwitchB(config-if)#channel-group 1 mode desirable
SwitchB(config-if)#interface fa0/14
SwitchB(config-if)#channel-group 1 mode desirable
Давайте изменим один из коммутаторов, чтобы он активно отправлял сообщения PAgP.
EtherChannel сейчас работает. Проблема решена!
Извлеченный урок: при использовании PAgP убедитесь, что хотя бы один из коммутаторов использует требуемый режим, или в случае LACP убедитесь, что один коммутатор находится в активном режиме.
Case #3
Еще одна ситуация: EtherChannel настроен между коммутатором A и коммутатором B, но клиент жалуется, что соединение медленное ... что может быть не так?
Быстрая проверка говорит нам, что port-channel interface работает.
Команда show etherchannel detail дает нам много выходных данных, но она так же нам говорит, что происходит. Вы видите, что интерфейс FastEthernet 0/13 и 0/14 были настроены для port-channel, но коммутатор не смог связать их, потому что FastEthernet 0/14 настроен на 10 Мбит. Возможно, что это основная причина медленной скорости передачи данных.
Мы будем использовать один из операторов для команды show. Нас интересует только то, чтобы увидеть вероятную причину, которую команда "show etherchannel detail" покажет.
SwitchA(config)#interface fa0/14
SwitchA(config-if)#speed auto
SwitchB(config)#interface fa0/14
SwitchB(config-if)#speed auto
Давайте изменим скорость на авто. Мы должны убедиться, что FastEthernet 0/13 и 0/14 имеют одинаковую конфигурацию.
Вероятно, вы увидите пару сообщений о том, что ваши интерфейсы переходят в состояние up и down.
Теперь мы видим, что оба интерфейса были добавлены в port-channel... проблема решена!
Извлеченный урок: убедитесь, что все интерфейсы, которые будут добавлены в port-channel, имеют одинаковую конфигурацию!
Ищете возможность анализировать сетевой трафик/отправлять его на систему записи телефонных разговоров? Изи. Коммутаторы Cisco (да и многие другие) дают возможность копировать пакеты с определенного порта или VLAN и отправлять эти данные на другой порт для последующего анализа (Wireshark, например).
Кстати, этот функционал полезен при использовании IDS (Intrusion Detection System) систем в целях безопасности. Мы уже рассказывали теоретические основы SPAN/RSPAN, поэтому, сегодняшняя статья будет посвящена практике настройке.
Про настройку SPAN
В рамках обычной SPAN сессии захват (копирование) сетевого трафика происходит с порта источника (source port) и отправляется на порт назначения (destination port). Обратите внимание на пример ниже: мы сделаем SPAN – сессию с порта fa 0/1 и отправим данные на порт fa 0/5:
Важно! SPAN – сессия может работать только в рамках одного коммутатора (одного устройства).
Конфигурация:
switch# configure terminal
switch(config)# monitor session 1 source interface fa0/1
switch(config)# monitor session 1 destination interface fa0/5
Просто, не правда ли? В рамках данной конфигурации весь трафик с порта fa 0/1 будет скопирован на порт fa 0/5.
Интереснее: пример RSPAN
Идем вперед. Более продвинутая реализация зеркалирования трафика это RSPAN (Remote SPAN). Эта фича позволяет вам зеркалировать трафик между различными устройствами (коммутаторами) по L2 через транковые порты. Копия трафика будет отправляться в удаленный VLAN между коммутаторами, пока не будет принята на коммутаторе назначения.
На самом деле, это легко. Давайте разберемся на примере: как показано на рисунке, мы хотим копировать трафик с коммутатора №1 (порт fa 0/1) и отправлять трафик на коммутатор №2 (порт fa 0/5). В примере показано прямое транковое подключение между коммутаторами по L2. Если в вашей сети имеется множество коммутаторов между устройствами источника и назначения – не проблема.
Конфигурация:
//Настройки на коммутаторе источнике
switch_source# config term
switch_source(config)# vlan 100 //Создаем Remote VLAN на первом коммутаторе (в который будем передавать данные с source порта)
switch_source(config-vlan)# remote span
switch_source(config-vlan)# exit
switch_source(config)# monitor session 10 source interface fa0/1
switch_source(config)# monitor session 10 destination remote vlan 100
//Настройки на коммутаторе получателе
switch_remote# config term
switch_remote(config)# vlan 100 //Создаем Remote VLAN на втором (удаленном) коммутаторе (в который будем передавать данные с source влана уже на порт назначения)
switch_remote(config-vlan)# remote span
switch_remote(config-vlan)# exit
switch_remote(config)# monitor session 11 source remote vlan 100
switch_remote(config)# monitor session 11 destination interface fa0/5
Таким образом, весь трафик с интерфейса fa 0/1 на локальном коммутаторе (источнике) будет отправлен в vlan 100, и, когда коммутатор получатель (remote) получит данные на 100 VLAN он отправит их на порт назначения fa 0/5. Такие дела.
Party Hard: разбираемся с ERSPAN
ERSPAN (Encapsulated Remote Switched Port Analyzer) - фича, которая используется для копирование трафика в L3 сетях. В основе работы механизма лежит GRE инкапсуляция.
Как показано ниже, между коммутатором источником и коммутатором получателем устанавливается GRE – туннель (между IP – адресами машин). Опять же, мы хотим отправить трафик с порт fa 0/1 на порт fa 0/5.
Конфигурация:
//Настройки на коммутаторе источнике
switch_source(config)# monitor session 1 type erspan-source
switch_source(config-mon-erspan-src)# source interface fa0/1
switch_source(config-mon-erspan-src)# destination
switch_source(config-mon-erspan-src-dst)# erspan-id 111 //Это значение должно быть одинаковым на всех устройствах
switch_source(config-mon-erspan-src-dst)# ip address 192.168.1.5 //IP - адрес коммутатора получателя
switch_source(config-mon-erspan-src-dst)# origin ip address 192.168.2.5 //IP - адрес коммутатора отправителя (источника)
//Настройки на коммутаторе получателе
switch_remote(config)# monitor session 1 type erspan-destination
switch_remote(config-mon-erspan-dst)# destination interface fa0/5
switch_remote(config-mon-erspan-dst)# source
switch_remote(config-mon-erspan-dst-src)# erspan-id 111
switch_remote(config-mon-erspan-dst-src)# ip address 192.168.1.5 //IP - адрес коммутатора получателя (назначения)
Траблшутинг
Мониторинг трафика в указанном VLAN:
monitor session 1 source vlan 13
Мониторинг входящего или только исходящего трафика:
monitor session 1 source vlan 13 rx/tx
Посмотреть конфигурацию сессии зеркалирования:
show monitor session 1