Wireless - Словарь сокращений, связанных с беспроводной связью

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

Cisco WLC - Назначение виртуального адреса контроллера

    При настройке контроллеров беспроводной связи Cisco WLC, независимо от того, осуществляется ли настройка через мастер или она выполняется полностью в ручном режиме, требуется задать виртуальный адрес (Virtual IP address). Что это, зачем он нужен, и какой адрес можно задать в качестве виртуального адреса - рассмотрим ниже.

    Судя по документации, основных назначений данного адреса несколько:

- поддержка Mobility Management;

- работа с DHCP-релей (при условии, что контроллер настроен в качестве релея);

- предоставление функций безопасности на уровне L3, таких, как гостевая аутентификация посредством Web и VPN-терминация.

   Кроме вышеперечисленного, этот адрес используется при обработке DNS запросов, а также присутствует в сертификате, используемом для веб-авторизации на L3. 

   Таким образом, этот адрес - нечто вроде точки взаимодействия с контроллером при установлении соединения. Этот адрес используется только между клиентскими устройствами и контроллером, он не появляется в виде источника или отправителя в пакетах, идущих в сторону сети.

   Данный адрес нельзя пинговать, он вообще никак не взаимодействует с сетью. Он не маршрутизируется. Отсюда требование - данный адрес должен быть уникальным, неиспользуемым, не присоединенным к какому-либо маршрутизируемому порту где-либо в сети.

Отображение метки времени в логах IOS в локальном часовом поясе

   Логи (они же журналы событий, но будем пользоваться привычным "логи" от английского logs) важны. Это аксиома. Еще важнее, чтобы логи всех устройств могли рассказать нам не только что произошло, но и когда оно произошло. Из этого вытекает следующая аксиома - время в логах тоже важно.

   Про время, NTP и синхронизацию расскажу в следующей статье. А пока решим конкретную задачу, с которой недавно пришлось столкнуться. Проблема заключалась в том, что на коммутаторе Cisco под управлением IOS 15 в выводе команды show logging метка времени отличалась от настроенного времени на 3 часа.

    Вот вывод команды show logging:

 

Apr  1 07:06:20.496: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/7, changed state to up
Apr  1 07:06:56.179: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/7, changed state to down

   А вот конфигурация часовых поясов и настроенное время на самом коммутаторе:

Как узнать дату производства оборудования Cisco по серийному номеру

   Серийный номер оборудования Cisco можно увидеть в нескольких местах: на наклейке, нанесенной на корпус устройства, на коробке, в котором устройство приехало, или же непосредственно в системе, выполнив в командной строке команду show version в случае IOS-устройств (коммутаторы, маршрутизаторы, межсетевые экраны).

   Серийный номер имеет следующий формат: LLLYYWWSSSS, где:

• L - три буквы, обозначающие место производства данного устройства. Ниже примеры некоторых кодов:

                    CTH --- Celestica - Thailand
                    FOC --- Foxconn - Shenzhen, China
                    JAB  --- Jabil - Florida
                    JPE  --- Jabil - Malaysia
                    JSH  --- Jabil - Shanghai , China
                    TAU --- Solectron - Texas
                    PEN --- Solectron - Malaysia

• YY - две цифры, обозначающие год производства. Год здесь закодирован, отсчет начинается с кода 01, который означает год производства 1997. Соответственно, 2000 год - это код 04, 2010 год - это код 14, ну а текущий 2019 - это код 23.
• WW - две цифры, указывающие на номер недели в году, в которой и было произведено устройство (партия). Например,  23я неделя 2010 года - это период с 7 по 13 июня 2010 (можете проверить).
• SSSS - буквенно-цифровой код (в источниках его называют BASE-34, т.к. тут могут содержаться цифры от 0 до 9 и буквы латинского алфавита от A до X, за исключением I и O), являющийся уникальным для каждого устройства. 

    Ниже пример чтения и расшифровки кодов.

Cisco UCM - Как посмотреть историю звонков

    Одна из часто встречающихся задач при обслуживании систем IP-телефонии - проверить время того или оного звонка, собрать некую статистику. Если система построена на базе Cisco UCM, то сделать сбор такой информации можно через веб-интерфейс. Для этого необходимо выполнить следующие действия:

• Открываем веб-интерфейс Cisco UCM;
• В правом верхнем углу выбрать в меню навигации Cisco Unified Serviceability, нажать Go для перехода;
• В разделе Tools выбрать CDR Analysis and Reporting. Аббревиатура CDR расшифровывается как Call Detail Records.
• Если от нас требуется узнать только факт звонка, переходим в меню CDR---Search и выбираем критерий поиска. Например, на рисунке ниже представлено диалоговое окно, которое возникает при выборе критерия By User/Phone Number/SIP URL:

Зоопарк неукротим или Хабр давно уже не тот

   Как-то раз сидел я в очередной командировке на очередном промышленном объекте, на котором выполнял работы по обеспечению защиты очередных АСУ ТП и КИИ от различного вида угроз, а параллельно участвовал в строительстве сетевой инфраструктуры заказчика. И вот после трудового дня решил почитать habr.com. А там замечательная статья под названием "Зоопарк на нефтебуровой: наводим порядок". У меня опыт работы в области безопасности промышленных сетей и систем небольшой - всего 6 лет (нефтепровод, протяженностью более 1000 км, добывающая промышленность, химпром, электроэнергетика). Поэтому тема интересная, решил ознакомиться, узнать что-то новое... После прочтения же мне захотелось написать очень большой комментарий, но, к сожалению, не хватает прав.

   С этого я и хотел бы начать новую рубрику, которую назову мягко - "Критика". Собственно, здесь будет много критики.

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

   Я же в свою очередь не хотел бы, чтобы в следующий раз очередной заказчик или подрядчик ссылался на такую статью в корпоративном блоге одного из крупнейших российских интеграторов и говорил: "Ну вот же ж! Они же строят так! Значит, нормально!"

   В этом разборе постараемся не вырывать слова из контекста, опираться только на то, что написал сам автор, т.е. будем делать прямые цитаты. Кроме того, мы не будем додумывать за автора, а понимать то, что он написал, буквально. Это тоже важно.

   Итак, поехали.

Способ удаленного сбора копии трафика (SPAN) в случае, когда обычными методами это сделать сложно

   Имеется следующая задача. Собрана схема, показанная на рисунке ниже.

   Трафик передается между PC1 и PC2 через коммутатор SW1. Между коммутаторами SW2 и SW1 настроен транк. К коммутатору SW2 подключен сервер с софтом для сбора трафика (например, Wireshark). Мы хотим собрать копию трафика, идущего от PC1 к PC2 и обратно.

   Если на месте коммутаторов стоят довольно таки умные устройства с расширенным фунционалом (например, Cisco 2960x или что-то иное), то можно было бы просто настроить Remote SPAN (RSPAN). Но у нас здесь коммутаторы Natex 3424GW v1 или иные, которые: 1) не умеют работать с RSPAN, 2) могут снимать SPAN только с физических интерфейсов.

   Как решить такую задачу, если мы не можем протянуть дополнительные физические линии, не можем изменить коммутацию между коммутаторами, но при этом можем настраивать интерфейсы на коммутаторах так, как нам захочется? Правильно! "По-колхозному"!