По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В версиях Asterisk начиная с версии 1.4 периодически наблюдались проблемы с утечкой памяти, которые лечились с помощью перезагрузки сервера. Так как никто не застрахован от вероятных неизвестных багов, лучше для перестраховки перезагружать сервер IP - АТС раз в неделю (или чаще) с помощью скрипта. В статье расскажем про создание bash скрипта и его настройку в cron.
Скрипт перезагрузки
По факту, в скрипте достаточно одной команды перезагрузки. Сделаем немного информативной нагрузки – добавим запись в лог – файл: мы будем записывать дату и время ребута с лог – файл. Итак, создаем файл reboot.sh:
[root@asterisk ~]# touch reboot.sh
Далее открываем этот файл для редактирования через vim редактор:
[root@asterisk ~]# vim reboot.sh
Открыв файл, нажмите «О» для редактирования. Вставьте код, указанный ниже:
#!/bin/sh
LOGFILE=/home/admin/log_mail.txt
DATE="`date +%d.%m.%Y" "%H:%M:%S`"
echo "REBOOT :: $DATE :: Reboot is in progress" >> "$LOGFILE"
shutdown -r now
После этого нажимаем комбинацию «:x!» для сохранения конфигурации. В данном скрипте:
LOGFILE - переменная, которая указывает на лог – файл;
DATE - записываем дату и время в указанную переменную;
echo "…" - записываем в лог – файл отметку о перезагрузке;
shutdown -r now - команда перезагрузки сервера;
Получаем простенький скрипт для осуществления перезагрузки. Осталось только сделать его работу по расписанию. Для этого, мы воспользуемся планировщиком cron:
* * * * * команда для выполнения
- - - - -
| | | | |
| | | | +----- день недели (0 - 6) (Воскресенье=0)
| | | +------- месяц (1 - 12)
| | +--------- день месяца (1 - 31)
| +----------- час (0 - 23)
+------------- минута (0 - 59)
Зашедулим скрипт на выполнение каждую полночь в воскресение. Для этого, открываем для редактирования crontab файл:
[root@asterisk ~]# crontab -e
В открывшийся файл добавляем:
0 0 * * 0 /bin/bash /home/reboot.sh >/dev/null
Где /home/reboot.sh - полный путь к скрипту перезагрузки сервера. Нажимаем F2 и далее Yes. Задача на выполнение сохранена.
Примеры планирования в cron
Разберем пару примеров того, по какому расписанию можно планировать выполнение скрипта:
15 0 1 1,3,6,9,12 * - выполнение скрипта каждое 1 число января, марта, июня, сентября и декабря в 00:15 ночи;
0 20 * 8 1-5 - выполнение скрипта каждый будний день в 20:00 в августе;
0 0 1,15,25 * * - выполнение скрипта в полночь каждого месяца первого, пятнадцатого и двадцать пятого числа;
Первая часть тут.
В конце 1980—х в мире сетевой инженерии появилась новая тема для обсуждения-асинхронный режим передачи данных (ATM). Потребность в более скоростных схемах в сочетании с медленным развитием в коммутации пакетов персонально на основе их адресов назначения привела к толчку к новому виду передачи, который, в конечном счете, реконфигурировал бы весь набор (или стек, потому что каждый протокол образует слой поверх протокола ниже, как «слоёный пирог») протоколов, используемых в современных сетях. ATM объединил размер ячейки (или пакета) с фиксированной длиной коммутации каналов с заголовком из коммутации пакетов (хотя и значительно упрощенным), чтобы произвести «промежуточное» технологическое решение. Было два ключевых момента для ATM: label switching и fixed call sizes; рисунок 1 иллюстрирует первый вариант.
На рис. 1 G отправляет пакет, предназначенный для H. При получении этого пакета A проверяет локальную таблицу и обнаруживает, что следующий переход к H — это C. Локальная таблица A также указывает метку, показанную как L, а не «просто» информацию о том, куда переслать пакет. A вставляет эту метку в специальное поле в начале пакета и пересылает ее в C. Когда C получает пакет, ему не нужно читать адрес назначения в заголовке, скорее, он просто читает метку, которая является коротким полем фиксированной длины. Метка просматривается в локальной таблице, которая сообщает C переадресовать трафик в D для назначения H. Метка очень мала и поэтому легко обрабатывается для устройств пересылки, что делает переключение намного быстрее.
В некотором смысле метка также может «содержать» информацию для обработки пакета. Например, если на самом деле существует два потока трафика между G и H, каждому из них может быть назначена своя метка (или набор меток) через сеть. Пакеты, несущие одну метку, могут иметь приоритет над пакетами, несущими другую метку, поэтому сетевым устройствам не нужно просматривать какие-либо поля в заголовке, чтобы определить, как обрабатывать конкретный пакет.
Это можно рассматривать как компромисс между коммутацией пакетов и коммутацией каналов. В то время как каждый пакет все еще пересылается hop by hop, виртуальный канал также может быть определен путем метки через сеть. Второй момент заключался в том, что ATM также был основан на ячейке фиксированного размера: каждый пакет был ограничен 53 октетами информации. Ячейки фиксированного размера могут показаться незначительной проблемой, но пакеты фиксированного размера могут иметь огромное значение для производительности. Рисунок 2 иллюстрирует некоторые факторы, связанные с фиксированными размерами ячеек.
На рисунке 2 пакет 1 (A1) копируется из сети в память на сетевой карте или интерфейсе LC1; затем он проходит через внутреннюю структуру внутри B (между ячейками памяти) к LC2, и, наконец, возвращается в сеть на исходящем интерфейсе B. На такой диаграмме это может показаться тривиальным, но, пожалуй, наиболее важным фактором скорости, с которой устройство может переключать / обрабатывать пакеты, является время, необходимое для копирования пакета по любым внутренним путям между ячейками памяти. Процесс копирования информации из одного места в памяти в другое является одной из самых медленных операций, которые может выполнять устройство, особенно на старых процессорах. Создание одинакового пакета (фиксированный размер ячейки) позволило оптимизировать код во время процесса копирования, что значительно увеличило скорость переключения.
Путь пакета 2 через B еще хуже с точки зрения производительности; сначала он копируется из сети в локальную память. Когда порт назначения определяется путем поиска в локальной таблице пересылки, код, обрабатывающий пакет, понимает, что пакет должен быть фрагментирован, чтобы соответствовать наибольшему размеру пакета, разрешенному на исходящем канале [B,C]. Карта входящей линии, LC1, фрагментирует пакет на A1 и A2, создавая второй заголовок и корректируя любые значения в заголовке по мере необходимости. Пакет делится на два пакета, А1 и А2. Эти два пакета копируются в двух операциях через матрицу на исходящую сетевую карту LC2. Используя ячейки фиксированного размера, ATM избегает затрат на производительность фрагментации пакетов (в то время, когда предлагалась ATM), понесенных почти любой другой системой коммутации пакетов.
ATM, на самом деле, не начинался в ядре сети и не прокладывал свой путь к краю сети. А почему бы и нет? Первый ответ заключается в довольно странном выборе размера ячейки. Почему 53 октета? Ответ прост-и, возможно, немного поразителен. АТМ должна была заменить не только сети с коммутацией пакетов, но и тогдашнее поколение голосовых сетей, основанных на технологиях коммутации каналов. Объединяя эти две технологии, провайдеры могли бы предлагать оба вида услуг на одном наборе схем и устройств.
Какой объем информации или размер пакета идеально подходит для передачи голосового трафика? Около 48 октетов. Какой объем информации или размер пакета является минимумом, который имеет какой-либо смысл для передачи данных? Около 64 октетов. Пятьдесят три октета были выбраны в качестве компромисса между этими двумя размерами; это не было бы идеально для передачи голоса, так как 5 октетов каждой ячейки, несущей голос, были бы потрачены впустую. Это не было бы идеально для трафика данных, потому что самый распространенный размер пакета, 64 октета, должен был бы быть разделен на две ячейки для переноса через сеть ATM. Общим мнением во время проведения этих обсуждений было то, что протоколы передачи данных могли бы адаптироваться к немного меньшему размеру ячейки, что делает 53 октета оптимальным размером для поддержки широкого спектра трафика. Протоколы передачи данных, однако, не изменились. Для переноса 64-октетного блока данных одна ячейка будет содержать 53 октета, а вторая - 9 октетов с 42 октетами свободного пространства. Провайдеры обнаружили 50% или более доступной пропускной способности на каналах ATM использовались пустые ячейки, что фактически приводило к потере пропускной способности. Следовательно, поставщики данных прекратили развертывание ATM, поставщики голосовой связи так и не начали его развертывание, и ATM умер.
Что интересно, так это то, как наследие таких проектов, как ATM, живет в других протоколах и идеях. Концепция переключения меток была подхвачена Yakov Rekhter и другими инженерами и превращена в переключение меток. Это сохраняет многие фундаментальные преимущества быстрого поиска ATM на пути пересылки и объединения метаданных об обработке пакетов в саму метку. Коммутация по меткам в конечном итоге стала Multiprotocol Label Switching (MPLS), которая не только обеспечивает более быстрый поиск, но также стеки меток и виртуализацию. Таким образом, была взята и расширена основная идея, которая существенно повлияла на современные сетевые протоколы и конструкции.
Вторым наследием ATM является фиксированный размер ячейки. В течение многих лет доминирующий сетевой транспортный пакет, основанный на TCP и IP, позволял сетевым устройствам фрагментировать пакеты при их пересылке. Однако это хорошо известный способ снижения производительности сети. Бит «не фрагментировать» был добавлен в заголовок IP, сообщая сетевым устройствам о необходимости отбрасывать пакеты, а не фрагментировать их, и были предприняты серьезные усилия для обнаружения самого большого пакета, который может передаваться по сети между любой парой устройств. Новое поколение IP, названное IPv6, удалило фрагментацию сетевыми устройствами из спецификации протокола.
Третья часть тут.
В данной статье мы опишем настройки сети, которые могут очень пригодится для малых и средних сетей. Мы настроим на Cisco ASA DHCP сервер с несколькими внутренними локальными сетями.
У нас есть три разных внутренних локальных сети с ПК пользователей и другой инфраструктурой – серверами, принтерами и так далее.
Нашей задачей является разделение этих сетей с помощью использования Cisco ASA (данная задача решается как на старых моделях 5500, так и на новых 5500-X). Три внутренних локальных сети будут подключены к одному коммутатору второго уровня с тремя VLAN-ами на данном коммутаторе
ASA будет предоставлять доступ к интернету для всех внутренний ЛВС. Кроме того, ASA также будет выполнять функции DHCP сервера для каждой из ЛВС, назначая нужные IP – адреса для каждой из сетей, используя разные DHCP пулы. Кроме того, мы будем использовать один физический интерфейс на ASA для размещения внутренних зон безопасности (“inside1”,“inside2”,“inside3”). Для этого нам необходимо настроить саб-интерфейсы на физическом интерфейсе нашего МСЭ, который подключен к транковому порту коммутатора. Каждый саб-интерфейс будет служить шлюзом по умолчанию для соответствующих подсетей.
Касаемо настроек свитча – нам необходим один порт Dot1Q, который будет подключен к фаерволлу, и также необходимо будет настроить порты доступа для внутренних хостов.
Топология изображена ниже:
Убедитесь, что вы используете лицензию security-plus.
Из топологии мы видим:
Интерфейс GE1 на ASA – внешняя зона с адресом 100.1.1.1 будет подключен к провайдеру
Интерфейс GE0 на ASA – интерфейс, подключенный к транковому порту на коммутаторе. Данный интерфейс будет разбит на три саб-интерфейса, каждый из которых принадлежит свой зоне безопасности и VLAN.
Саб-интерфейс GE0.1 - VLAN10 (адрес 10.1.1.254) – зона безопасности “inside 1”
Саб-интерфейс GE0.2 - VLAN10 (адрес 10.2.2.254) – зона безопасности “inside 2”
Саб-интерфейс GE0.3 - VLAN10 (адрес 10.3.3.254) – зона безопасности “inside 3”
Интерфейс Eth0/1, Eth0/2, Eth 0/3 на коммутаторе – настраиваются как порты доступа для соответствующих VLAN-ов (10, 20, 30)
Хосты в VLAN 10 – получат адреса с ASA через DHCP (10.1.1.0/24) на интерфейсе “inside1”
Хосты в VLAN 20 - получат адреса с ASA через DHCP (10.2.2.0/24) на интерфейсе “inside2”
Хосты в VLAN 30 – получат адреса с ASA через DHCP (10.3.3.0/24) на интерфейсе “inside3”
Все внутренние локальные сети – данные сети получат доступ к интернету через ASA с использованием PAT (NAT Overload) на внешнем интерфейсе МСЭ
Важно отметить, что в данном примере настройка меж-VLAN маршрутизации проведена не была – есть только доступ в интернет.
Конфигурация Cisco ASA
Ниже указан конфиг для МСЭ
! Данный физический интерфейс разбиваем на три саб-интерфейса (порт подключен к транковому порту коммутатора)
interface GigabitEthernet0
no nameif
no security-level
no ip address
!
! Это саб-интерфейс GE0.1 для VLAN10
interface GigabitEthernet0.1
vlan 10
nameif inside1
security-level 100
ip address 10.1.1.254 255.255.255.0
! Это саб-интерфейс GE0.2 для VLAN20
interface GigabitEthernet0.2
vlan 20
nameif inside2
security-level 90
ip address 10.2.2.254 255.255.255.0
! Это саб-интерфейс GE0.3 для VLAN30
interface GigabitEthernet0.3
vlan 30
nameif inside3
security-level 80
ip address 10.3.3.254 255.255.255.0
! This is the WAN interface connected to ISP Это WAN интерфейс, подключенный к ISP
interface GigabitEthernet1
nameif outside
security-level 0
ip address 100.1.1.1 255.255.255.0
! Настраиваем сетевые объекты для трех ЛВС
object network inside1_LAN
subnet 10.1.1.0 255.255.255.0
object network inside2_LAN
subnet 10.2.2.0 255.255.255.0
object network inside3_LAN
subnet 10.3.3.0 255.255.255.0
! Данный ACL полезен тем, что разрешает ходить ICMP трафику (пинг и так далее)
access-list OUT extended permit icmp any any
access-group OUT in interface outside
! Разрешаем доступ в Интернет – для этого настраиваем PAT (NAT Overload) на внешнем интерфейсе
object network inside1_LAN
nat (inside1,outside) dynamic interface
object network inside2_LAN
nat (inside2,outside) dynamic interface
object network inside3_LAN
nat (inside3,outside) dynamic interface
access-group OUT in interface outside
route outside 0.0.0.0 0.0.0.0 100.1.1.2
! Создаем три разных DHCP cущности
! DHCP сущность для VLAN10 – “inside1”
dhcpd address 10.1.1.1-10.1.1.100 inside1
dhcpd enable inside1
! DHCP сущность для VLAN20 – “inside2”
dhcpd address 10.2.2.1-10.2.2.100 inside2
dhcpd enable inside2
! DHCP сущность для VLAN30 – “inside3”
dhcpd address 10.3.3.1-10.3.3.100 inside3
dhcpd enable inside3
! Назначаем DNS cервер для внутренних хостов
dhcpd dns 200.1.1.1
На этом все, переходим к настройке свитча.
Настройка коммутатора
Настройка коммутатора очень проста – необходимо настроить транковый порт и три порта доступа, с указанием VLAN.
! Транковый порт, который подключается к GE0
interface Ethernet0/0
switchport trunk encapsulation dot1q
switchport mode trunk
duplex auto
! Порт доступа для VLAN10
interface Ethernet0/1
switchport access vlan 10
switchport mode access
duplex auto
! Порт доступа для VLAN20
interface Ethernet0/2
switchport access vlan 20
switchport mode access
duplex auto
! Порт доступа для VLAN30
interface Ethernet0/3
switchport access vlan 30
switchport mode access
duplex auto