Хотя я работаю в телекоме уже 5 лет и читаю различные стандарты регулярно, на этот старый стандарт 1996 года я наткнулся недавно.

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

12 сетевых истин

(оригинал — RFC1925 The Twelve Networking Truths)
Р. Каллон, издатель
IOOF
1 апреля 1996

Статус этого документа

Этот документ предоставляет информацию для Интернет сообщества. Этот документ не является стандартом Интернет никакого рода. Распространение этого документа не ограничено.

Краткий обзор

Этот документ описывает фундаментальные сетевые истины Интернет сообщества. Этот документ определяет не стандарт, но чувство, что все стандарты должны неявно соответствовать фундаментальным истинам.

Официальное заявление

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

1. Вступление

Данный RFC предоставляет информацию о фундаментальных сетевых истинах. Эти истины применимы к построению сетей в целом, они не ограничены только TCP/IP, Интернетом или любым другим подмножеством сетевого сообщества.

2. Сетевые истины

1) Это должно работать.

Долгое время все большие проекты, связанные с сетью, будь то web-проект или ДЦ крупного предприятия представляли собой одну и ту же структуру. Это была характерная древовидная архитектура, различающаяся лишь размером дерева и плотностью «ветвей», обусловленных разными требованиями к надежности и производительности. Но цифровой мир не стоит на месте, а стремительно растет и развивается, при чем не только в увеличиваясь объемах и скоростях, но и меняя свою структуру. Всевозможные Big Data, облака и распределенные вычисления привели к тому, что по сети стало необходимым передавать огромные объемы данных между большим количеством конечных узлов, причем, желательно, с минимальной задержкой.

Все это привело к тому, что традиционная древовидная архитектура, состоящая из уровней доступа, агрегации трафика и ядра, стала откровенно буксовать и давать сбои. Назрела необходимость ее заменить. На что?

Сегодня мы рассмотрим протокол BGP. Не будем долго говорить зачем он и почему он используется как единственный протокол. Довольно много информации есть на этот счет, например тут.

Итак, что такое BGP? BGP — это протокол динамической маршрутизации, являющийся единственным EGP( External Gateway Protocol) протоколом. Данный протокол используется для построения маршрутизации в интернете. Рассмотрим как строится соседство между двумя маршрутизаторами BGP.


Рассмотрим соседство между Router1 и Router3. Настроим их при помощи следующих команд:

Протокол PIM — это набор протоколов для передачи мультикаста в сети между маршрутизаторами. Отношения соседства строится аналогично как и в случае динамических протоколов маршрутизации. PIMv2 отправляет каждые 30 секунд Hello сообщения на зарезервированный мультикаст адрес 224.0.0.13 ( All-PIM-Routers ). Сообщение содержит в себе Hold Timers — обычно равен 3.5*Hello Timer, то есть 105 секунд по умолчанию.

PIM использует два основных режима работы — Dense и Sparse mode. Начнем c Dense mode.

На github опубликован код, приводящий к force restart iOS (11/12 GM) устройств при посещении html-страницы. Также приводит к зависанию Mac OS High Sierra/Mojave при использовании Safari.

СДСМ-15. Про QoS. Теперь с возможностью Pull Request'ов.

И вот мы дошли до темы QoS.

Знаете почему только сейчас и почему это будет закрывающая статья всего курса СДСМ? Потому что QoS необычайно сложен. Сложнее всего, что было прежде в цикле.

Это не какой-то магический архиватор, который ловко сожмёт трафик на лету и пропихнёт ваш гигабит в стомегабитный аплинк. QoS это про то как пожертвовать чем-то ненужным, впихивая невпихуемое в рамки дозволенного.

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

Поэтому давайте просто осознаем, что QoS это обязательно, познать его придётся так или иначе, и почему-бы не начать сейчас, в спокойной обстановке.

В этом году мы опубликовали две статьи, связанные со сравнением функциональности маршрутизаторов и межсетевых экранов компании Cisco, а также с обзором разделения control и data plane в сетевом оборудовании. В комментариях к этим статьям был затронут вопрос производительности сетевого оборудования. А именно как зависит производительность маршрутизаторов Cisco разных поколений от включения на них тех или иных сервисов. Так же обсуждалась тема производительности межсетевых экранов Cisco ASA. В связи с этим возникло желание посмотреть на эти вопросы с практической стороны, подкрепив известные моменты цифрами. О том, что получилось и, что получилось не очень, расскажу под катом.

Недавно столкнулся с проблемой: у клиента две Cisco ASA 5512-x, которые работают в режиме active/standby. Клиент забыл обновить пароли, и у всех пользователей истек срок действия пароля. ASA при попытке залогиниться только лишь сообщает об истечении срока действия и не даёт возможности сменить пароль. Так как срок действия истек у всех пользователей, то каким-либо способом подключиться и сменить пароль не представлялось возможным. Всегда был железный вариант сбросить пароль при помощи изменения регистра, но тут без простоя не обойтись. Такой вариант не подходил. Было решено использовать standby ASA, чтоб избежать простоя. Но и там были свои нюансы:

1) Если просто перезагрузить standby ASA, зайти в ROMMON mode, поменять регистр и загрузиться, то мы получим доступ и сможем сменить пароли, но как только выполним

copy startup-config running-config

то сразу standby ASA найдет активную ноду и уже будет синхронизировать конфиг оттуда.

2) Если же отключить синхронизацию и только потом загрузить конфигурацию, то standby ASA возьмет себе активные ip адреса и у нас будет конфликт.

После размышлений был придуман следующий план:

1. Перезагружаем standby ASA, заходим в ROMMON, меняем регистр на 0x41 и загружаемся:

rommon #1> confreg 0x41

rommon #2> boot

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