Админская фамилия

Make Sysadmins Great Again

DHCP, Option 82

Встала задача: определять на каком порту какого свитча находится конкретный IP-адрес. На самом деле задача глобальнее, но сейчас имеет смысл именно это. В ходе гугления вышел на DHCP Option 82. Инфы много, но кроме теории важно это.
Суть в том, что коммутатор в запрос DHCP добавляет два поля: Agent Remote ID (идентификатор коммутатора) и Agent Circuit ID (идентификатор порта). Казалось бы, всё просто. Но я столкнулся с некоторыми трудностями.

Дело в том, что сеть поделена на сегменты для улучшения безопасности, выделения потоков трафика и уменьшения широковещательного трафика. Каждый сегмент имеет свою адресацию и, соответственно, свой DHCP-сервер.
Чтобы настроить работу Option 82, коммутатор необходимо настроить как DHCP-relay. Это значит, что при получении DHCP request’a коммутатор просто отправит этот запрос DHCP серверу, указанному в настройках релея. Таким образом можно уменьшить количество широковещательного трафика в пределах сегмента и иметь один DHCP сервер на несколько подсетей. Но, DHCP-relay может работать только с одним DHCP-сервером (указанным в настройках релея), соответственно, все наши сегменты получат адреса из одной подсети, что
нас совсем не устраивает.


Failover Datacenter/LAN. Best practice

Принципы построения катастрофоустойчивых ЦОДЛучшие практики и рекомендуемыедизайны по построению LAN-сетейна базе возможностей оборудованияСiscoАрхитектура и дизайн распределенной корпоративной сети высокой доступностиАрхитектура Smart Business Architecture"Сети без границ" для организаций среднего размера


Моя сертифицированный консультант Mikrotik

Теперь я сертифицированный консультант Mikrotik. Единственный на Урале, между прочим. Жду ваших вопросов.Страница с консультантами тут


PDU. Количество полезной информации на рахных уровнях модели OSI

PDU (Protocol Data Unit) - общий блок данных протокола (полезные данные + заголовки) (wikipedia).  Своими словами - часть блока данных, в которой содержится информация верхнего уровня (для IP - часть пакета, где лежит TCP/UDP, для TCP/UDP - часть сегмента/датаграммы, где лежит информация прикладного уровня).MTU (Maximum Transmission Unit) - максимальный размер полезного блока данных одного пакета (PDU)Например, IP-пакет. Wiki говорит так:IP-пакеты состоят из заголовка и полезной нагрузки. Заголовок пакета IPv4 состоит из:4 бита содержат версию пакета: IPv4 или IPv6.4 бита содержат длину интернет-заголовка, которая измеряется отрезками по 4 байта (например, 5 означает 20 байт).8 бит содержат тип обслуживания, известный также как качество обслуживания (QoS), описывающее приоритеты пакета.16 бит содержат длину пакета в байтах.16 бит содержат тег идентификации, помогающие восстановить пакет из нескольких фрагментов.3 бита содержат нуль, флаг разрешения фрагментации пакета (DF: не фрагментировать), а также флаг разрешения дальнейшей фрагментации (MF: фрагментировать дальше).13 бит содержат смещение фрагмента, поле для идентификации положение фрагмента в исходном пакете.8 бит содержат время жизни (TTL), которое определяет количество переходов (через маршрутизаторы, компьютеры и сетевые устройства), разрешённых пройти пакету, прежде чем он исчезнет (например, пакету с TTL 16 разрешено пройти не более 16 маршрутизаторов, чтобы добраться до места назначения).8 бит содержат протокол (TCP, UDP, ICMP и т. д.).16 бит содержат контрольную сумму заголовка, используемую при обнаружении ошибок.32 бит содержат IP-адрес источника.32 бит содержат адрес назначения.После этих данных могут быть добавлены разное количество необязательных флагов, меняющиеся в зависимости от используемого протокола, затем идут данные, которые переносит пакет. IP-пакет не имеет хвостового прицепа. Однако, IP-пакеты часто переносятся как полезная нагрузка внутри фрейма Ethernet, который имеет свой собственный заголовок и хвост.Те данные, которые переносятся пакетом и есть PDU. А его максимальный размер - MTU.На картинке видны PDU разных уровней. Блок данных, в которых есть data и есть PDU.Для модели OSI выделяют следующие PDU:Уровень 1 (физический/physical) - бит/bitУровень 2 (канальный/data link) - кадр/frameУровень 3 (сетевой/network) - пакет/packetУровень 4 (транспортный/transport) - сегмент/segment для TCP, датаграмма/datagram для UDPУровни 5-7 (прикладной/application) - данные/dataРассмотрим каждый уровень подробнее.2. Payload (полезная нагрузка) канального уровня содержит 46-1500 байт. В эту полезную нагрузку входит блок данных более высоко уровня, один из частных (и наиболее распространенный) PDU для L2 - IP. Соответственно, MTU - 15003. Заголовки сетевого уровня составляют 40 байт, соответственно максимальный размер PDU  (в терминологии этого уровня называется MSS - Maximum Segment Size) равен 1500 (MTU более низкого уровня) - 40 (заголовки) = 14604. На следующем уровне MTU определяется размером заголовков.


MTCNA, MTCRE

В дополнение к предыдущему посту.


Как один админ роутинг изучал

Давно мечтал стать сертифицированным специалистом в ИТ. Мечтал не о сертификате, а о знаниях, приобретаемых с подготовкой к сертификации. И вот выдалась возможность. Мой работодатель оплатил мне перелет в Москву и обратно, гостиницу и, собственно, курсы.Сертифицироваться хотелось по оборудованию Mikrotik, так как именно с ним приходится работать большую часть времени. Так как по своим ощущениям, знаниями на уровне MTCNA (CCNA аналог Cisco) я обладаю, хотелось подтянуть знания по динамической маршрутизации, следовательно, был выбран курс MTCRE (CCNP Routing). Но получить сертификат MTCRE без MTCNA невозможно, поэтому решил проверить и улучшить свои базовые знания.По удобным датам обучения и отзывам был выбран тренинг центр Mikrotik-Trainings. Началась активная переписка с представителями, ответы на все интересующие вопросы были получены, учеба оплачена. Вылет в Москву.Часть первая. MTCNAГоворят, первое впечатление определяет дальнейшее отношение к чему-либо. Так и вышло. Учебный центр находится в 10 минутах от метро, в небольшом невзрачном здании. Думаю, что это связано с арендной платой. Но в классе уютно, светло и приятно. Встретили меня очень тепло, хоть я и опоздал. Предложили кофе, печеньки и начали активное обучение. Такое отношение осталось на всю мою учебную неделю - ничего не расстроило.На MTCNA учащихся было 6 человек. Сразу выделились лидеры с огромным опытом и говорящие непонятными словами и буквами (привет, Анатолий!). Сначала я со своим 2-летним опытом в сетях почувствовал себя совсем глупым. Но потом, когда нашел со всеми общий язык и понял о чем курс, стал посмелее.На самом деле, MTCNA совсем не сложен. Тут преподают азы сетей, и нового для себя я узнал максимум процентов 10 из всего, что было сказано.НО! Это не говорит о том, что я не считаю этот курс полезным. Все, о чем было сказано, я познавал сам. Сколько было набито шишек из-за неучтенных нюансов, сколько пользователей оставалось без сервисов из-за банального неучета какой-нибудь мелочи. Тут все это разбирают за 3 дня, у меня ушло 2 года. Дружественная обстановка, ответы на любые вопросы, общение с единомышленниками сделали своё дело. И, если из курса нового было 10%, то при общении со студентами и преподавателями я получил массу полезной информации.Несомненный плюс именно этого учебного центра в том, что проводятся лабораторные работы по каждой теме. Это не включено в официальную программу Микротик. С помощью “работы руками” материал воспринимается лучше. Кто так не считает, может кинуть в меня патчкорд.Экзамен был сдан очень хорошо и дался без труда. Сдали все. Если не ошибаюсь, самый низкий бал был 79%.Часть вторая. MTCREПосле легкой победы на MTCNA, меня ожидал курс по роутингу. Я знал, что тут будет не так просто. Собственно, из-за OSPF я сюда и приехал. Тема OSPF занимает половину курса, вторую половину - VPN и статик-роутинг.На инженерном курсе студенты были “посерьезнее”. Все старше меня и гораздо опытней. Все лично знакомы с тренером - получали у него MTCNA. “Вот тут я всосу” - подумал я. Но не просто так люди приехали на курсы. Знаний в этом у них не больше моего - они спецы в других областях, а тут только учатся.Тема за темой, лаба за лабой, мы познавали различные виды туннелей и маршрутизации.Забыл написать. Преподают не теоретики. Тренеры - Олег и Ирина - занимаются интеграцией, имеют за плечами кучу проектов по различным направлениям. То есть со всеми практическими нюансами знакомы не по наслышке, а так же, как и большинство из нас, набили когда шишки.Курс пройден, лабы сданы, экзамены тоже.Подведу итог.Касаемо курсов в общем.Даже если вы считаете себя мегаспецом, столкнувшимся со всеми возможными тонкостями. Идите на курсы! Тут ваши знания обретут порядок и улягутся в голове. Что-то новое да услышите от тренеров. А общение с такими же как вы позволит взглянуть на мир ИТ чужими глазами.Касаемо конкретного учебного центра.Если тянетесь за “илитой” и бумажкой - вам не сюда. Вас не будут водить на обеды в рестораны и поить дорогим кофе. Но несмотря на не самую современную техническую оснащенность (есть ноутбук, проектор и стенд для экспериментов - а что ещё нужно?) преподаватели очень компетентны. Дают всю информацию по курсу и даже больше. Помогают разобраться в ваших проблемах. На все вопросы о реорганизации моей очень непростой сети было отвечено и разобрано в схемах. Даже одну лабораторную посвятили моим вопросам. Будьте уверены - приобретете огромный багаж знаний и примеры их применения в реальной жизни. Mikrotik-Trainings настоящие профессионалы как в ИТ, так и в педагогике. И просто хорошие, веселые и отзывчивые люди. Спасибо вам, Олег и Ирина! Я обязательно вернусь.


Must read!

Очень интересная статья про то, куда идти после эникейства


Режимы бондинга в RouterOS. И не только в RouterOS

В вики микротика не совсем понятно описано. На хабре об этом сказали лучше:mode=0 (balance-rr)Последовательно кидает пакеты, с первого по последний интерфейс. mode=1 (active-backup)Один из интерфейсов активен. Если активный интерфейс выходит из строя (link down и т.д.), другой интерфейс заменяет активный. Не требует дополнительной настройки коммутатораmode=2 (balance-xor)Передачи распределяются между интерфейсами на основе формулы ((MAC-адрес источника) XOR (MAC-адрес получателя)) % число интерфейсов. Один и тот же интерфейс работает с определённым получателем. Режим даёт балансировку нагрузки и отказоустойчивость.mode=3 (broadcast)Все пакеты на все интерфейсыmode=4 (802.3ad)Link Agregation — IEEE 802.3ad, требует от коммутатора настройки. mode=5 (balance-tlb)Входящие пакеты принимаются только активным сетевым интерфейсом, исходящий распределяется в зависимости от текущей загрузки каждого интерфейса. Не требует настройки коммутатора.mode=6 (balance-alb)Тоже самое что 5, только входящий трафик тоже распределяется между интерфейсами. Не требует настройки коммутатора, но интерфейсы должны уметь изменять MAC.


Всеобъемлющая дока по MTU

http://www.cisco.com/image/gif/paws/25885/pmtud_ipfrag.pdfОно и по-русски есть


Как Windows работает с несколькими шлюзами по умолчанию

Для обеспечения отказоустойчивости сетей применяется практика использования нескольких шлюзов по умолчанию. В таком случае при доступности одного из шлюзов, трафик будет идти через него (шлюзы не эквивалентны, постоянно активен только один). При отказе этого шлюза, трафик пойдет через второй шлюз. С соединениями по TCP проблем это не создаст. Единственное, TCP коннект должен будет пересоединиться по новому маршруту после завершения таймаута соединения. С трафиком же UDP могут возникнуть проблемы при переключении шлюза - телефония начнет заикаться, видео будет пропадать. Но по прошествии какого-то времени проблема исчезнет. А как Windows определяет доступность шлюза? Об этом ниже.Когда TCP-соединение маршрутизируется через основной шлюз, хост пытается отправить пакет к получателю столько раз, сколько указано в ключе реестра TcpMaxDataRetransmissions, деленное пополам. И если ответ от получателя за это количество попыток ни разу не пришел, то алгоритм меняет Route Cache Entry (RCE) (кэш маршрутов). Наше соединение (отправившее TcpMaxDataRetransmissions/2 пакетов и не получившее ни одного ответа) переключается на шлюз, указанный вторым в настройках адаптера. Когда 25% TCP-соединений переключатся на второй шлюз, он становится шлюзом по умолчанию. Новый шлюз по умолчанию будет использоваться до возникновения аналогичных проблем с ним, либо до перезагрузки системы.Вольный перевод KB171564