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

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

Конкретно в этой части:

• Автоматические события
• Макросы

А в первой части были рассмотрены:

• Простейшая настройка Shorewall
• Ужасно сложная настройка dnsmasq
• Не менее сложная настройка OpenVPN
• И для многих продолжающих админов нетипичная, динамическая маршрутизация, на примере OSPF

А во второй:

• Более подробная настройка Shorewall
• Страшный и не понятный QoS
• Балансировка нагрузки и резервирование

А в третьей:

• QoS во всю ширь в Shorewall
• Более подробная настройка Shorewall
• Раскидывание трафика по каналам в соответствии с протоколами
• Костыли, без них, никуда

Стандарт 802.11ac принят в 2014 году, а устройства с его поддержкой, как водится, появились раньше. Как многие знают, в нем значительно увеличена скорость передачи данных (теоретически, до 6.7 Гбит/с!). Достигается это благодаря увеличенной ширине каналов (до 160 МГц), количеству потоков (до 8) и новой улучшенной модуляции (256-QAM). Конечно, не все новшества стандарта стали доступны сразу. Реализация на точках доступа и клиентских станциях происходит поэтапно. Первая волна (wave 1) устройств поддерживает каналы 80 МГц, модуляцию 256-QAM и два-три пространственных потока. Корпоративные точки доступа второй волны (wave 2), появившиеся в 2015 году, поддерживают ширину канала до 80 МГц и до четырех пространственных потоков, что дает скорость 1.7 Гбит/с. Также, для второй волны устройств добавлена поддержка многопользовательского пространственного мультиплексирования MultiUser-MIMO (MU-MIMO). Эта технология позволяет передать несколько потоков информации нескольким пользователям одновременно (ага, точка доступа превращается в некий беспроводной коммутатор). Сейчас практически любое новое устройство с беспроводной Wi-Fi сетью поддерживает как минимум первую волну стандарта.

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

Что это такое — 12.10.0.1.10.0.1.23. Нет, это не ссылка на ветку MIB протокола SNMP. Сегодня мы поговорим об Enhanced IP (далее EnIP).

Если трезво смотреть на мир, то транспортная сеть состоит из кучи «костылей», чего только стоят такие технологии как nat (во всех его видах) или virtual links в ospf. Прочитав драфт rfc , посвященный EnIP, я понял, что это очередной костыль. Но честно говоря идея мне понравилась. Ну, начнем.

Не буду говорить как тяжело сейчас живется и как мало у нас IPv4 адресов (это все и так уже слышали), а перейду непосредственно к технологии.

Чем больше знакомишься с оборудованием Juniper, тем больше влюбляешься в это оборудование и операционную систему JunOS. Сегодня речь пойдет о Static, Aggregate и Generate маршрутах. По этой теме есть статьи на английском (не встречал на русском даже переводов), поэтому решил написать свою статью. Надеюсь, помогу какому-нибудь начинающему инженеру.

Итак, начну. Все три перечисленых выше видов маршрутов по своей сути являются статическими маршрутами и прописывают в конфигурации junos в иерархии edit routing-options.

Итак, static route. Любой сетевой инженер знает что это такое. Нам надо попасть в какую то сеть, но нет возможности (или желания) использовать протоколы динамической маршрутизации, выход — статика.

Ценообразование в сфере интерент-провайдеров продолжает видоизменяться в том числе и под влиянием IaaS-провайдеров, которые позволяют создавать новые бизнес-модели.

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

Сегодня мы решили проанализировать заметку Маршалла Брейна (Marshall Brain), автора проекта HowStuff Works. Он привел пример самой дорогой интернет-связи в мире.

Представляю вторую статью из серии, ориентированных на «продолжающих» системных администраторов, для опытных я вряд ли открою что-то новое.
В этих статьях мы рассмотрим построение интернет шлюза на linux, позволяющего связать несколько офисов компании, и обеспечить ограниченный доступ в сеть, приоритезацию трафика (QoS) и простую балансировку нагрузки с резервированием канала между двумя провайдерами.
Конкретно в этой части:

• Более подробная настройка Shorewall
• Страшный и не понятный QoS
• Балансировка нагрузки и резервирование

А в предыдущей части были рассмотрены:

• Простейшая настройка Shorewall
• Ужасно сложная настройка dnsmasq
• Не менее сложная настройка OpenVPN
• И для многих продолжающих админов нетипичная, динамическая маршрутизация, на примере OSPF

В третьей части:

• QoS во всю ширь в Shorewall
• Более подробная настройка Shorewall
• Раскидывание трафика по каналам в соответствии с протоколами
• Костыли, без них, никуда

В четвертой части:

• Автоматические события
• Макросы

Представляю пока две статьи, ориентированных на «продолжающих» системных администраторов, для опытных я вряд ли открою что-то новое.
В этих статьях мы рассмотрим построение интернет шлюза на linux, позволяющего связать несколько офисов компании, и обеспечить ограниченный доступ в сеть, приоритезацию трафика (QoS) и простую балансировку нагрузки с резервированием канала между двумя провайдерами.
Конкретно в этой части:

• Простейшая настройка Shorewall
• Ужасно сложная настройка dnsmasq
• Не менее сложная настройка OpenVPN
• И для многих продолжающих админов нетипичная, динамическая маршрутизация, на примере OSPF

А во второй части будут рассмотрены:

• Более подробная настройка Shorewall
• Страшный и не понятный QoS
• Балансировка нагрузки и резервирование

В третьей части:

• QoS во всю ширь в Shorewall
• Более подробная настройка Shorewall
• Раскидывание трафика по каналам в соответствии с протоколами
• Костыли, без них, никуда

В четвертой части:

• Автоматические события
• Макросы

Wi-Fi сейчас является одним из основных видов беспроводной связи. Большинство коммуникационных устройств оснащены именно этим беспроводным видом связи. Но вот умные гаджеты, т.е. устройства с приставкой «smart» обычно не используют Wi-Fi для связи друг с другом. Исключения есть, но их не так много.

Производители неохотно идут на встраивание такого рода модулей связи в умные гаджеты, поскольку Wi-Fi требует значительных затрат энергии. И это реальная проблема для устройств, которые должны быть маленькими, дешевыми и работать в автономном режиме месяцы или даже годы. Но сейчас эту проблему, кажется, постепенно решают. Wi-Fi Alliance собирается сертифицировать стандарт Wi-Fi HaLow, основной для которого служит неутвержденная пока спецификация IEEE 802.11ah.

При классической схеме подключения двух ISP к одному роутеру, есть возможность использовать сразу два канала для NATирования внутренних клиентов с балансировкой нагрузки, а не только для фейловера при отказе одного из провайдеров.

В прошлый раз мы не оставили камня на камне при разборе MPLS. И это, пожалуй, хорошо.

Но до сих пор только призрачно прорисовывается применение его в реальной жизни. И это плохо.

Этой статьёй начнём исправлять ситуацию. Вообще же читателя ждёт череда из трёх статей: L3VPN, L2VPN, Traffic Engineering, где мы постараемся в полной мере рассказать, для чего нужен MPLS на практике.

Итак, linkmeup — уже больше не аутсорсинг по поддержке хоть и крупной, но единственной компании, мы — провайдер. Можно даже сказать федеральный провайдер, потому что наша оптика ведёт во все концы страны. И наши многочисленные клиенты хотят уже не только высокоскоростной доступ в Интернет, они хотят VPN.
Сегодня разберёмся, что придётся сделать на нашей сети (на которой уже меж тем настроен MPLS), чтобы удовлетворить эти необузданные аппетиты.

Замечательным примером сетевой солидарности являются многочисленные сервисы looking-glass, позволяющие заглянуть за кулисы очень многих больших и маленьких сетей во всём мире. Это настолько удивительно в современном мире, спрятанном за сотней систем безопасности, просто так взять и выполнить команды на маршрутизаторах являющихся одними из самых критичных устройств всей инфраструктуры передачи данных.



Надо лишь ввести IP адрес или префикс в поле и получить в ответ таблицу маршрутизации или трассировку и результаты работы утилиты ping. Поэтому когда понимаешь, что можно вводить не только адреса, но и некоторые другие символы сформированные в осмысленные команды и получать осмысленные результаты, наступает ступор. Хочется бежать и кричать на всех углах: «Да что же это такое надо немедленно запретить, что за несуразность?». Это всё последствия последних лет, когда безопасность превыше открытости и удобности и на это, несомненно, есть причины.

Речь пойдёт об очень популярной реализации looking-glass от version6.net и о том что-же можно получить от этого сервиса.

Введение

Образы в WIM формате, подготовленные в системе MDT, компания Microsoft предлагает развертывать по сети с помощью WDS-сервера, либо интегрировать в SCCM.
SCCM стоит довольно дорого, а вот WDS-сервер бесплатен в случае, если вы являетесь счастливым обладателем лицензии на Windows Server 2008/2012. Но не всех устраивают возможности WDS-сервера.
Предлагаемый мной способ будет полезен тем:

• у кого нет лицензии на Windows Server, или все ресурсы на имеющихся серверах уже задействованы и нет возможности приобрести еще одну лицензию;
• кого не устраивает скорость загрузки Windows PE по протоколу TFTP, используемому WDS-сервером;
• кому необходимо совместить развертывание ОС Windows и Linux по сети на одном сервере.

Хочу предложить читателям решение на базе ОС Ubuntu Linux, с использованием syslinux и iPXE.

Я использую Mikrotik в качестве домашнего и офисного маршрутизатора, и в целом система очень нравится. RouterOS имеет широкие возможности, которые покрывают 90% моих задач, если чего-то недостает, то можно «дописать» функционал с помощью внутренних скриптов. Но когда начинаешь писать более-менее вменяемый скрипт или пытаешься понять и применить чужой рецепт, становятся заметны очертания подводной части айсберга, всплывают странные особенности языка.

Содержимое: как сделать так, чтобы компьютер отвечал в интернете на все свои IP-адреса по всем своим интерфейсам, каждый из которых имеет шлюз по умолчанию. Касается и серверов, и десктопов.

Ключевые слова: policy routing, source based routing

Лирика: Есть достаточно статей про policy routing в Linux. Но они чаще всего разбирают общие, более тонкие и сложные случаи. Я же разберу тривиальный сценарий следующего вида:



Нашему компьютеру (серверу) доступно три интерфейса. На каждом интерфейсе шлюз ему выдал IP (статикой или по dhcp, не важно) и сказал «весь трафик шли мне».

Если мы оставим эту конфигурацию как есть, то будет использоваться принцип «кто последний встал, того и дефолтный шлюз». На картинке выше, если последним поднимется нижний интерфейс (241), то в него будет отправляться весь трафик. Если к нашему серверу придёт запрос на первый интерфейс (188), то ответ на него всё равно пойдёт по нижнему. Если у маршрутизатора/провайдера есть хотя бы минимальная защита от подделки адресов, то ответ просто дропнут, как невалидный (с точки зрения 241.241.241.1 ему прислали из сети 241.241.241.0/24 пакет с src 188.188.188.188, чего, очевидно, быть не должно).

Другими словами, в обычном варианте будет работать только один интерфейс. Чтобы сделать ситуацию хуже, если адреса получены по dhcp, то обновление аренды на других интерфейсах может перезаписать шлюз по умолчанию, что означает, что тот интерфейс, который работал, работать перестанет, а начнёт работать другой интерфейс. Удачной стабильной работы вашему серверу, так сказать.

Решение

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

Считаю, что динамическая маршрутизация именно в данной задаче работала бы не так быстро и вероятно надежно, как того требует проект. Ничего не имею против динамической маршрутизации, но негативные отзывы о работе ее на оборудовании MikroTik и некоторая специфика сети (об этом ниже), повлияли на выбор в сторону статики и скриптов.

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

Освоил expect и сразу в бой. Написал, опробовал, получилось. Теперь делюсь с Вами, может кому и пригодится.

Сегодня хотелось бы поговорить о двух достаточно схожих технология виртуализации коммутаторов, которые позволяют объединять несколько коммутаторов в один логический. Речь пойдёт про технологии Cisco Virtual Switching System (VSS) и HPE Intelligent Resilient Framework (IRF). В рамках статьи мы рассмотрим более подробно, как работает технология VSS, после чего поговорим о технологии IRF.

Предыстория:

Собственно, задача — объединить дом 1 и дом 2 в одну сеть с гуляющими бродкастами и мультикастами.
Цель — заставить PlayStation TV подключаться к PlayStation 4(без основного акк.) и полноценно использовать Remote Play локально.

На вооружении имеем следующее железо:

Дом 1:
Dlink dir615C2
Дом 2:
Dlink dir615E4

Samba (самба) под Linux. Этот удивительный софт подарил линуксоидам возможность связи с миром Windows.
Помню то дивное чувство, когда в локальной сети появился мой первый самба-сервер. Эх, было время!

Но пост не об этом. Не по наслышке знаю, что многих раздражает ограниченная поддержка спец.символов в Windows. Но ведь это не повод отказываться от них, не так ли?



Подробности моих злоключений и (почти) счастливый финал под катом. Приступим!

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