Прочитал две статьи «Dual ISP на маршрутизаторах cisco без BGP» и «Одновременное использование двух провайдеров на маршрутизаторах cisco». На ум пришла мысль попробовать нарисовать и описать решение к ещё одной, немного нестандартной задаче.
Итак, рассмотрим простой пример. Есть клиент и имеется два провайдера (аплинка). Автономной системы для построения BGP-peer'ов у нас нет, а работать, при падении одного каналов как-то надо. При этом у нас есть внутренний клиент нашей сети который работает не как все, а с точностью до наоборот. В нормальной (оба канала работают) этот клиент всё-равно ходит через резервный канал (Dialer1), в то время как все работают по основному (Dialer0) и переключается он на основной канал только в том случае если резервный(!) падает (бывает и такое).

Предисловие.

Как сказали в комментариях к первой статье, что могут руки не дойти до второй статьи, как в воду глядели. Она лежала незавершенная очень долгое время. Сейчас подогнал чуть-чуть, только пришлось отказаться от многих деталей и пожеланий, которые высказывались в комментариях к первой части. Но думаю интерес все таки вызовет данное продолжение статьи, хоть и высказывались, что PBR банальная и избитая тема. В прочем я согласен, но что бы писать следующую статью все таки нужно завершить начатое ранее.

Кому интересно продолжение статьи добро пожаловать под кат

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

Введение

Добрый день!

В этой статье я хотел бы рассказать о типах областей OSPF. Статьи по настройке OSPF с использованием областей как-то здесь мне уже попадались. Я же хочу рассмотреть, чем эти типы областей отличаются друг от друга: normal, stub, totally stubby, NSSA, totally NSSA. Итак, начнем.

По заявкам слушателей, так сказать. Правильно соединить кабель — половина дела, но если он будет свободно болтаться, то долго он не проживет — или заденут, или порвут, или откусят(необязательно со злыми намерениями). А может просто под своим весом выскользнуть из соединения. А может не выскользнуть, что еще хуже — поди-ка найди место пропадания контакта. Так что эта статья расскажет о том, какими способами можно закрепить кабель так, чтоб он никуда не делся.
Да и вот такие крепления некрасивы, неудобны, и выдают непрофессионала:

UPD:

Ребята, взамен помершего Tunlr мы подняли свой DNS Proxy для Pandora и Spotify. Работает, понянтно, на всех платформарх и практически не требует настройки — habrahabr.ru/post/215889/. Велкам!

Если вам, как мне, надоело подключать VPN-туннель на штаты каждый раз, когда вы хотели бы послушать знающее ваши музыкальные вкусы радио Pandora или увидеть видео по ссылке на hulu.com, вам помогут два волшебных адреса (проверьте на сайте, они периодически меняются):

142.54.177.158

209.141.56.79

Это адреса DNS-сервера сайта tunlr.net который проделывает хитрую магию с заголовками помогает вам избежать проверки на страну пребывания для вашего IP.

Сервис поддерживает только определенный список сайтов, для которых это будет работать. В случае всех остальных запросов он будет работать как обычный честный DNS-сервер.

Продолжаем серию общеобразовательных статей, под общим названием «Теория радиоволн».
В предыдущих статьях мы познакомились с радиоволнами и антеннами:

• Теория радиоволн: ликбез
• Теория радиоволн: антенны

Давайте ближе познакомимся с модуляцией радиосигнала.

Помимо свойств радиоволн, необходимо тщательно подбирать антенны, для достижения максимальных показателей при приеме/передаче сигнала.
Давайте ближе познакомимся с различными типами антенн и их предназначением.

Думаю все крутили ручку радиоприемника, переключая между «УКВ», «ДВ», «СВ» и слышали шипение из динамиков.
Но кроме расшифровки сокращений, не все понимают, что скрывается за этими буквами.
Давайте ближе познакомимся с теорией радиоволн.

Сеть “Лифт ми Ап” вместе со своим штатом разрастается вдоль и поперёк. Обслуживание ИТ-инфраструктуры вынесли в отдельную специально созданную организацию “Линк ми Ап”.
Буквально на днях были куплены ещё четыре филиала в различных городах и инвесторы открыли для себя новые измерения движения лифтов. А сеть выросла с четырёх маршрутизаторов сразу до десяти. При этом количество подсетей теперь увеличилось с 9 до 20, не считая линков точка-точка между маршрутизаторами. И тут во весь рост встаёт управления всем этим хозяйством. Согласитесь, добавлять на каждом из узлов маршруты во все сети вручную — мало удовольствия.
Ситуация усложняется тем, что сеть в Калининграде уже имеет свою адресацию и на ней запущен протокол динамической маршрутизации EIGRP.
Итак, сегодня:
— Разбираемся с теорией протоколов динамической маршрутизации.
— Внедряем в сеть “Лифт ми Ап” протокол OSPF
— Настраиваем передачу (редистрибуцию) маршрутов между OSPF и EIGRP
— В этом выпуске мы добавляем раздел “Задачи”. Идентифицировать по ходу статьи их будут такие пиктограммы:


Уровень сложности будет разный. Ко всем задачам будут ответы, которые можно посмотреть на сайте цикла. В некоторых из них вам понадобится подумать, в других почитать документацию, в третьих разобраться в топологии и, может, даже смотреть отладочную информацию. Если задача нереализуема в РТ, мы сделаем специальную пометку об этом.

В прошлой статье мы рассмотрели основные моменты настройки сетевого оборудования HUAWEI и остановились на статической маршрутизации. В сегодняшнем топике речь пойдёт о динамической маршрутизации по протоколу OSPF совместно с маршрутизаторами Cisco. Добро пожаловать под кат.

Вопрос SMS уведомлений в zabbix уже освещался на Хабре и проблема решалась с использованием СМС-шлюзов. Также упоминали про Отправку SMS c помощью Delphi. Я же хочу рассказать, как настроить SMS уведомления используя USB модем.
Итак, что имеем:

1) довольно обширная ИТ-инфраструктура

2) система мониторинга Zabbix 2.0.3 (актуальная версия на момент написания статьи) функционирующая под Fedora 14 x64

3) 3G USB модем ZTE MF100 от национального украинского оператора Киевстар.



4) Prepaid симка, которая шла в комплекте с модемом.

Также для модема была куплена корпоративная 3G симка, но её использовать не получится, так как с 3G-карточек невозможно позвонить и отправлять смс, а это нам не подходит.Итак, положил на карточку небольшую сумму «для опытов», втыкнул модем в USB и

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

И так, встречайте: Zabbix.

Началось все с того, что я откопал в полке с железками USB модем huaweiE1550, купленный мной прошлым летом для организации резервного канала Интернет. Проработал он тогда недолго и за ненадобностью был убран в «закрома» до лучших времен. Первое что сделал, разлочил его для работы с МТС (так уж сложилось исторически, что я предпочитаю именно этого оператора). Изначально в голову пришла идея отправки смс с предупреждениями от Nagios, вместо почты. Бегло пробежавшись по Интернетам, наткнулся на smsd демона для отправки/приемки смс-ок из пакета smstools. После прочтения документации по этому зверю, в голову пришла идея о том, что можно принимать сообщения с нужных телефонов, с командами для сервера. Так и родилась идея «Управлять сервером посредством СМС», которая может применяться для чего угодно: перезагрузить сервер, выключить его, перезапустить демона, сбросить кеш, открыть порт на фаерволе для удаленного подключения по ssh.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Всем доброго дня!

В этой статье я бы хотел поговорить про возможности Cisco IOS Access Control Lists (ACLs). Тема многим из вас должна быть знакомой, поэтому мне хочется обобщить информацию по разным типам ACLs. Я кратко пробегусь по основам, а затем поговорим про специальные типы ACLs: time-based (на основе времени), reflexive (отражающие), dynamic (динамические). Итак, начнем…

Наверное, некоторые знают такую штуку, но думаю, далеко не все.

Как мы все знаем, адрес IPv4 представляет собой 32-битное число. Традиционно IP-адрес записывается в виде 4-х октетов, разделенных точкой, в десятичной системе счисления. Например: 77.88.21.8.
Однако существуют и другие, менее распространенные варианты записи.

Во-первых, каждый из 4-х октетов можно записать в восьмеричной или шестнадцатеричной системах счисления:
77.88.21.8 = 0x4d.0x58.0x15.0x8 = 0115.0130.025.010, или даже можно смешивать 77.88.0x15.010.

Во-вторых, адрес можно записывать в виде числа:
77 * 256³ + 88 * 256² + 21 * 256¹ + 8 * 256^О = 1297618184.
Аналогично п.1 это число можно записывать в восьмеричной и шестнадцатеричной системах счисления: 1297618184 = 011526012410 = 0x4D581508.

Честно говоря, не нашел RFC, в котором описываются эти форматы, но это работает везде: в браузере, команде ping и т.д. Попробуйте сами.

Если совершить опечатку в IP-адресе, то результат будет странным, на первый взгляд. Например, пинг к 192.168.72 распознаётся как 192.168.0.72, а 192.168.072 уже распознаётся как 192.168.0.58.

Народ слишком усложняет здесь из-за разных RFC, IP-классов и тому подобных вещей. Просто запустите пару тестов и посмотрите, как команда ping парсит входящие значения.

Введение

Многие интересуются Full-Mesh (или P2P) VPN, хотят использовать их для игр с друзьями, для связи удаленных офисов, серверов, да для чего угодно. Обычные VPN, вроде OpenVPN или PPTP, пропускают весь трафик через центральный сервер, а Full-Mesh соединяются непосредственно с нодами, зачастую пробивая NAT.

При создании локальной сети не каждый администратор подходит с ответственностью к выбору диапазона адресов. А может и не каждый догадывается о наличии частных диапазонов кроме 192.168.0.0/24. И со временем такая бомба замедленного действия может дать о себе знать. Локальные сети объединяются, возникает потребность в коммуникации между хостами разных сетей. И тут выясняется, что номера сетей совпадают. И менять их по каким либо причинам проблематично или невозможно.