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

Сегодня про восстановление доступа к виртуальной машине с linux после удаления части операционной системы.

Если содержание будет интересно аудитории, то попробую написать ряд подобных статей.

Добрый день уважаемое сообщество.

В рамках подготовки к сдаче экзамена SECURE (642-637) хотелось бы поговорить о технологии uRPF (Unicast Reverse Path Forwarding).

Эта технология является средством антиспуфинга (antispoofing) на третьем уровне модели OSI, и используется как одна из технологий при защите data plane. Точнее, она позволяет бороться с подделкой IP адреса отправителя в пакетах, которые приходят на интерфейсы маршрутизатора. Ведь злоумышленник может использовать в отправляемых пакетах «похищенный с другой сети» IP адрес, либо некорректный IP адрес из отведённых для специфического использования диапазонов, например 127.0.0.0/8.

Очень часто администраторы выполняют настройку системы просто настройкой базовых вещей — ip,dns,hostname, поставить софт, а все остальное уже настройки приложений. В большинстве случаев так оно и есть, поскольку в linux’е очень разумные умолчания и, в большинстве случаев, этих умолчаний хватает и все живут счастливо. Среди совсем начинающих ходят легенды о неких sysctl’ях, а те, кто поопытнее видели и даже чего-то правили.

Но приходит момент, когда админ в своих походах по системе встречает этого зверя — sysctl. Вероятнее всего он встречает кого-то из семейства net.ipv4 или vm, даже вероятнее всего net.ipv4.ip_forward, если поход за роутером или vm.swappinness, если он обеспокоен подросшим swap’ом своего пингвина. Первый зверь разрешает пингвину принимать пакеты одним крылом и отдавать другим (разрешает маршрутизацию), а второй помогает справиться с использованием swap’а в спокойной системе и регулировать его использование — в нагруженной.

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

Всем привет! Периодически при проектировании компьютерных сетей на базе оборудования Cisco возникает вопрос, что поставить на периметр сети: маршрутизатор или межсетевой экран Adaptive Security Appliance (ASA)? Далеко не всегда можно однозначно ответить на данный вопрос. Хотел бы в очередной раз сделать попытку и провести небольшое сравнение этих двух устройств. Вы заметите, что уже много раз это обсуждалось. Согласен. Но устройства постоянно развиваются: появляются новые модели, добавляется функционал. Поэтому иногда стоит отойти подальше и ещё раз посмотреть со стороны на данный вопрос. Вдруг что-то поменялось?

В рамках данной статьи хотелось бы обсудить вопрос: «Как выбрать NGFW решение из многообразия предлагаемых продуктов, решений и вендоров?» В связи с этим, мы рассмотрим несколько соображений по этому поводу и сформируем некий «чек-лист», по которому желательно пробежаться перед выбором решения.
Соображение №1. Все конкретно недоговаривают
Последние несколько лет я очень плотно занимаюсь темой NGFW, и самый частый запрос от клиентов, выбирающих решение для защиты сети, это сравнение и вопросы различия между лидерами различных квадрантов Gartner, NSS Lab и так далее. И это могло бы быть простой задачей. Но, как говорил один герой известного сериала…

К большому сожалению, нет НИ одного вендора с полностью достоверной информацией в маркетинговых брошюрах и DataSheet-ах. Каждый из них либо что-то недоговаривает, либо использует заведомо бесполезные характеристики, которые получаются с помощью искусственных тестов. Уловок у них миллионы. В большинстве случаев только личный опыт и большая (огромная) практика работы со всеми решениями на рынке, могут помочь вам обстоятельно выбрать решение для конкретной задачи за тот бюджет, который у вас есть.

В предыдущих частях (часть 1 и часть 2) мы рассказывали об архитектуре и функциях SDN-решения для сети ЦОД Big Cloud Fabric от компании Big Switch Networks. В заключительной статьей мы рассмотрим возможности фабрики по интеграции со смежными системами, а также приведем краткое резюме предыдущих частей обзора.

Недоступный простым смертным мифический ресурс pcet.cisco.com

Читатель, сталкивавшийся с необходимостью заниматься захватом данных PCM на маршрутизаторах Cisco ISR, легко находит исчерпывающее пошаговое руководство по данной теме, но непременно спотыкается о пункт «полученный файл следует отправить в TAC для дальнейшего извлечения звука». Можно ли обойтись без этого?

Построение инфраструктуры CDN связано с большим количеством технических вопросов: от выбора оборудования и установки его в датацентрах до пользовательского интерфейса для взаимодействия с возможностями сети. Мы приводим перевод статьи из блога Fastly, где команда рассказывает об очень интересных кастомных решениях для работы с сетью (значительная часть которых независимо была использована в инфраструктуре Айри).

В результате оптимизации инфраструктуры удалось добиться минимального времени простоя при отказе какого-либо узла и большой масштабируемости системы.

«Для чего в команде ping используются опции Loose, Strict, Record, Timestamp и Verbose?» — такой вопрос мне недавно встретился в вендорном экзамене. Они позволяют влиять на маршрутизацию ICMP пакетов и собирать информацию о транзитных L3-устройствах. Но занимаясь сетевыми технологиями уже достаточно давно, я почти никогда их не использовал.

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

UPD от 2017-03-04: кто-то выполнил английский перевод. Обсуждение на Hacker News.

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

Костыли в UNIX начали возникать ещё с момента появления UNIX, а это было ещё раньше появления не только Windows, но даже вроде бы Microsoft DOS (вроде бы, мне лень проверять, проверяйте сами). Если лень читать, хотя бы просмотрите все пункты, что-нибудь интересное найдёте. Это далеко не полный список, это просто те косяки, который я захотел упомянуть.

1. Введение в ODR – On-Demand Routing

Прежде чем изучать технологию ODR, давайте вспомним два основных метода наполнения таблиц маршрутизации информацией:

• Статическая маршрутизация – маршруты добавляются вручную администратором.
• Динамическая маршрутизация – администратор настраивает протоколы динамической маршрутизации.

Но в каждом из этих случаев есть недостатки:

• Основным недостатком статической маршрутизации является необходимость переконфигурации устройств при изменении структуры сети или адресов.
• Основными недостатками динамической маршрутизации недостатками являются: дополнительная нагрузка на каналы и понижение безопасности.

В принципе нельзя сказать что эти недостатки существенны в современных условиях. Навряд ли сети будут переконфигурироваться часто, современные каналы связи достаточно широки, что бы без проблем передавать относительно небольшой трафик, генерируемый протоколами маршрутизации. И даже проблему внешних динамических IP адресов, получаемых от провайдера можно решить путем использования технологии динамического DNS.
Но на самом деле есть еще один недостаток, общий для обоих вариантов – вам нужен обслуживающий персонал в каждой точке, где стоит маршрутизатор. Тот, кто будет прописывать статические маршруты или настраивать протокол динамической маршрутизации.
Именно для таких случаев компания Cisco разработала проприетарный протокол ODR, который по сути даже не является протоколом динамической конфигурации, это расширение еще одного проприетарного протокола – CDP. С помощью протокола ODR маршрутизаторы могут обмениваться маршрутной информацией специфическим образом (в результате объем передаваемой информации существенно меньше, чем у других протоколов динамической маршрутизации), и при этом конфигурация всех маршрутизаторов сети не требуется. Настраивается только один маршрутизатор – основной маршрутизатор компании, все остальные маршрутизаторы не требуют вообще никакой настройки маршрутизации, ни статической, ни динамической.
Таким образом, получается, что ODR не обладает выше указанными недостатками:

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

Говорят, что нельзя полностью понять систему, пока не поймёшь её сбои. Ещё будучи студентом я ради забавы написал реализацию TCP, а потом несколько лет проработал в IT, но до сих пор продолжаю глубже и глубже изучать работу TCP — и его ошибки. Самое удивительное, что некоторые из этих ошибок проявляются в базовых вещах. И они неочевидны. В этой статье я преподнесу их как головоломки, в стиле Car Talk или старых головоломок Java. Как и любые другие хорошие головоломки, их очень просто воспроизвести, но решения обычно удивляют. И вместо того, чтобы фокусировать наше внимание на загадочных подробностях, эти головоломки помогают изучить некоторые глубинные принципы работы TCP.

Аббревиатуры SDN и NFV в последнее время звучат все чаще и звучат вместе. В тендерах операторы связи требуют от производителей обязательной поддержки SDN и NFV, т.к. уверены, что эти технологии оказывают положительное влияние на OPEX, CAPEX и TTM. Быстрый серфинг интернета показывает, что SDN — это Software-Defined Networking, а NFV — это Network Functions Virtualization. Обе технологии связаны с виртуализацией и с сетями, т.е. на первый взгляд складывается впечатление, что они очень похожие, если не одно и то же. Давайте разбираться, так ли это на самом деле! Проверка по Google Trend сначала подтверждает гипотезу: тренд запроса «SDN and NFV» начинается в 2013 году:

Современные маршрутизаторы обрабатывают по несколько миллионов пакетов в секунду, работают с несколькими FV таблицами маршрутизации, позволяют реализовать огромное количество сервисов. Различные вендоры используют разный подход к построению оборудования. В данной статье не будет огромного количества выводов. Сегодня поговорим об архитектуре оборудования Juniper.

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

Первая часть была тут: Nagios — система мониторинга и некоторые самодельные плагины. Как и обещал, часть вторая, интереснее.

Здесь я расскажу, как и что можно в nagios мониторить в vmware, CMC-TC, Synology, ИБП (APC и Chloride), принтерах и о мониторинге интерфейсов в Cisco по именам и зачем это нужно.

Отказ от ответственности.

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

Сегодня речь пойдет о команде vrf-table-label. Вначале вспомним о способах генерации vrf меток. Метки могут быть сгенерированны тремя способами — per-vrf, per-prefix и per-next-hop.

per-prefix — одна метка — один клиентский префикс, то есть если у нас 100 клиентских vrf и у каждого клиента по 100 префиксов, то мы получим 100х100=10 000 меток, что очень расточительно по сегодняшним меркам. Данный метод распределения меток vrf по дефолту используется в маршрутизаторах Cisco.

per-next-hop — одна метка на все префиксы клиента, которые имеют один и тот же next-hop. Если клиентский маршрутизатор подключен к PE маршрутизатору одним линком, то все префиксы будут иметь один и тот же next-hop, а значит одну и ту же метку. Данный механизм распределения меток vrf по дефолту в JunOS.

per-vrf — одна метка на весь vrf. С точки зрения распределения меток этот режим очень экономичен: если у нас 100 клиентских vrf и у каждого клиента по 100 префиксов, то мы получим 100х1=100 меток. При таком распределении меток vrf маршрутизатор должен делать помимо mpls lookup еще и ip lookup.

Внимательный читатель найдет на этой картинке IPv6

Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.

Что такое DNS

DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.

Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com, и получает в ответ 1.2.3.4.