[Cisco, Сетевые технологии] VxLAN фабрика. Часть 2.5
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Всем привет. Проходил тут собеседование и появилась мысль следующую часть из цикла статей, посвященных запуску курса "Сетевой инженер" от OTUS, сделать более теоретической, дабы ответить на некоторые вопросы с которыми столкнулся во время интервью.
Многие тут вещи будут скорее базового уровня в понятиях VxLAN и не должны вызывать трудностей.
I. как VxLAN фабрика узнает о MAC адресах?
Да мы уже разобрали, что MAC и IP адреса передаются через EVPN route-type 2. Но как EVPN узнает о них?
Все довольно просто и работает аналогично логике обычного VLAN:
- Кадр от источника попадает на порт коммутатора (VTEP)
- Коммутатор, если не знает MAC источника — записывает его в свою таблицу TCAM
- Так как коммутатор выполняет роль VTEP, то информацию о MAC и IP адресах источника он передает через EVPN route-type 2 (каким именно образом зависит от настройки фабрики. В нашем случае используется Route-reflector(RR), поэтому информация отправляется к RR и от него к остальном VTEP)
С источником все понятно, а что делать с Destination? Ведь Host-источник скорее всего не знает MAC адрес назначения и пошлет ARP запрос.
Появляется два варианта:
- не использовать функцию Suppress-ARP
- использовать функцию Suppress-ARP
В первом случае все довольно просто, но не оптимально. При получении Broadcast запроса VTEP отправит его дальше в рамках того VNI, от куда пришел запрос. То есть по всей фабрики разойдется этот запрос в виде Unicast сообщений.
Во втором случае, при получении ARP запроса VTEP сам отвечает ARP reply, а ARP REQ дальше не отправляется.
Однако такая логика работает только если VTEP уже знает Destination MAC. Если адрес не известен, то пойдем по первому пути. Более подробно работу и настройку Suppress-ARP я касался в первой части цикла.
II. Зачем используется UDP?
Вопрос не менее интересный и ответить довольно просто. Для этого вспомним логику работы VxLAN фабрики:
К кадру, прилетающему на порт VTEP, добавляется VxLAN метка с номером VNI. Далее получившийся кадр запаковывается в UDP, инкапсулируется в новый IP пакет и передается поверх Underlay сети.
Так почему же нельзя оригинальный кадр с меткой VxLAN запаковать в IP и необходимо использовать UDP?
А все из-за одного поля в заголовке протокола IP — Protocol, который указывает, какой именно протокол находится выше. Примеры протоколов и их номера (wiki):
ICMP - 1
TCP - 6
UDP - 17
GRE - 47
И в этом кроется весь секрет — VxLAN не имеет такой номер, а значит протокол IP не сможет о нем рассказать и уважающая себя сеть такой пакет не пропустит, поэтому инженеры обошли эту проблему с использованием протокола UDP.
И тут может возникнуть второй вопрос — почему не TCP, ведь он такой надежный и хороший? А все потому, что TCP такой надежный и хороший — гарантирует доставку и для такой гарантии использует жутко долгие таймеры, проверки, регулирование полосы пропускания и т.д. В итоге TCP дает большую задержку, которая, особенно сильно, будет заметна, когда клиент VxLAN фабрики тоже будет использовать TCP.
III. Разница между ingress-replication и Multicast
Тема довольно объемная и в качестве краткого пояснения ответ дать не получится. Поэтому работа Multicast будет рассмотрена в рамках одной из следующей статьи цикла. Однако я попробую дать краткое описание различий двух технологий.
Для начала рассмотрим как передаются пакеты в обоих случаях.
при использовании ingress-replication — при получения широковещательного трафика (например ARP запрос) — запрос инкапсулируется внутрь VxLAN и передается каждому VTEP в VxLAN через Unicast сообщения (для примера откажемся от RR). Так как VTEP будет больше 1, то широковещательный трафик будет дублироваться:
В случае использования Multicast, каждый VTEP для каждого VNI подписывается на определенную Multicast группу. И теперь, при получении широковещательного трафика, VTEP инкапсулирует ARP запрос в IP пакет. В заголовках IP пакета в качестве адреса назначения используется multicast адрес группы для этого VNI, а адрес источника — IP адрес интерфейса NVE. Например, VNI 10000 ассоциируем c multicast группой 225.1.10.10
Таким образом у нас пропадает дублирование широковещательного трафика. Плюс, при должной оптимизации трафика, работа через Multicast будет более масштабируема. Единственная сложность — underlay сеть должна поддерживать Multicast трафик.
Если у вас возникает вопрос — Зачем вообще понадобился EVPN, если все может отлично работать через Multicast, ведь это более масштабируемое решение?
Ответ тут дать довольно затруднительно и вам придется решить самостоятельно какую технологию использовать. На данный момент, Multicast действительно является более масштабируемым решением. Но EVPN постоянно дорабатывается и в нем появляются новые route-type для передачи все большей информации о сети для более гибкой настройки. Дополнительно, EVPN строится на основе BGP, а значит есть возможность использовать все методы оптимизации, что есть и в самом BGP (например в моем стенде уже используется RR, для уменьшения BUM трафика и оптимизации анонсируемой информации).
Получилась довольно небольшая часть, но думаю она поможет прояснить некоторые моменты в понимании технологии.
OSPF ipv6. Практические навыки
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-инфраструктура, Сетевое оборудование, Сетевые технологии] Что нового в линейке высокопроизводительных маршрутизаторов NetEngine
- [Asterisk, IT-инфраструктура, Сетевое оборудование, Сетевые технологии] Младшенький. Обзор IP-телефона Snom D315
- [Flutter, Программирование, Разработка мобильных приложений] Flutter.dev: Простое управление состоянием приложения (перевод)
- [Искусственный интеллект, Машинное обучение] Распознавание мелодии путем изучения языка тела музыканта (перевод)
- [Искусственный интеллект, Машинное обучение] Развеиваем мифы о Deep Learning – Как учатся нейронные сети? (перевод)
- [Сетевые технологии, Системное администрирование] Синхронизация внешних календарей и адресных книг в Zimbra OSE
- [CRM-системы, IT-компании, Разработка систем связи, Сетевые технологии] Как мы интегрировали amoCRM с Виртуальной АТС от МегаФона
- [Сетевые технологии, Облачные сервисы, Искусственный интеллект] How Can AI & Data Science Help to Fight the Coronavirus?
- [JavaScript, Программирование] Как улучшить SEO с помощью Next.js (перевод)
- [Java, Тестирование веб-сервисов, Тестирование мобильных приложений] Совет инженерам по тестированию №1: Докерезируйте ваш Selenium Grid (перевод)
Теги для поиска: #_cisco, #_setevye_tehnologii (Сетевые технологии), #_vxlan, #_evpn, #_cisco, #_nexus, #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
), #_cisco, #_setevye_tehnologii (
Сетевые технологии
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:33
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Всем привет. Проходил тут собеседование и появилась мысль следующую часть из цикла статей, посвященных запуску курса "Сетевой инженер" от OTUS, сделать более теоретической, дабы ответить на некоторые вопросы с которыми столкнулся во время интервью.  Многие тут вещи будут скорее базового уровня в понятиях VxLAN и не должны вызывать трудностей. I. как VxLAN фабрика узнает о MAC адресах? Да мы уже разобрали, что MAC и IP адреса передаются через EVPN route-type 2. Но как EVPN узнает о них? Все довольно просто и работает аналогично логике обычного VLAN:
 С источником все понятно, а что делать с Destination? Ведь Host-источник скорее всего не знает MAC адрес назначения и пошлет ARP запрос. Появляется два варианта:
В первом случае все довольно просто, но не оптимально. При получении Broadcast запроса VTEP отправит его дальше в рамках того VNI, от куда пришел запрос. То есть по всей фабрики разойдется этот запрос в виде Unicast сообщений.  Во втором случае, при получении ARP запроса VTEP сам отвечает ARP reply, а ARP REQ дальше не отправляется.  Однако такая логика работает только если VTEP уже знает Destination MAC. Если адрес не известен, то пойдем по первому пути. Более подробно работу и настройку Suppress-ARP я касался в первой части цикла. II. Зачем используется UDP? Вопрос не менее интересный и ответить довольно просто. Для этого вспомним логику работы VxLAN фабрики: К кадру, прилетающему на порт VTEP, добавляется VxLAN метка с номером VNI. Далее получившийся кадр запаковывается в UDP, инкапсулируется в новый IP пакет и передается поверх Underlay сети. Так почему же нельзя оригинальный кадр с меткой VxLAN запаковать в IP и необходимо использовать UDP? А все из-за одного поля в заголовке протокола IP — Protocol, который указывает, какой именно протокол находится выше. Примеры протоколов и их номера (wiki): ICMP - 1
TCP - 6 UDP - 17 GRE - 47 И в этом кроется весь секрет — VxLAN не имеет такой номер, а значит протокол IP не сможет о нем рассказать и уважающая себя сеть такой пакет не пропустит, поэтому инженеры обошли эту проблему с использованием протокола UDP.  И тут может возникнуть второй вопрос — почему не TCP, ведь он такой надежный и хороший? А все потому, что TCP такой надежный и хороший — гарантирует доставку и для такой гарантии использует жутко долгие таймеры, проверки, регулирование полосы пропускания и т.д. В итоге TCP дает большую задержку, которая, особенно сильно, будет заметна, когда клиент VxLAN фабрики тоже будет использовать TCP. III. Разница между ingress-replication и Multicast Тема довольно объемная и в качестве краткого пояснения ответ дать не получится. Поэтому работа Multicast будет рассмотрена в рамках одной из следующей статьи цикла. Однако я попробую дать краткое описание различий двух технологий. Для начала рассмотрим как передаются пакеты в обоих случаях. при использовании ingress-replication — при получения широковещательного трафика (например ARP запрос) — запрос инкапсулируется внутрь VxLAN и передается каждому VTEP в VxLAN через Unicast сообщения (для примера откажемся от RR). Так как VTEP будет больше 1, то широковещательный трафик будет дублироваться:  В случае использования Multicast, каждый VTEP для каждого VNI подписывается на определенную Multicast группу. И теперь, при получении широковещательного трафика, VTEP инкапсулирует ARP запрос в IP пакет. В заголовках IP пакета в качестве адреса назначения используется multicast адрес группы для этого VNI, а адрес источника — IP адрес интерфейса NVE. Например, VNI 10000 ассоциируем c multicast группой 225.1.10.10  Таким образом у нас пропадает дублирование широковещательного трафика. Плюс, при должной оптимизации трафика, работа через Multicast будет более масштабируема. Единственная сложность — underlay сеть должна поддерживать Multicast трафик. Если у вас возникает вопрос — Зачем вообще понадобился EVPN, если все может отлично работать через Multicast, ведь это более масштабируемое решение? Ответ тут дать довольно затруднительно и вам придется решить самостоятельно какую технологию использовать. На данный момент, Multicast действительно является более масштабируемым решением. Но EVPN постоянно дорабатывается и в нем появляются новые route-type для передачи все большей информации о сети для более гибкой настройки. Дополнительно, EVPN строится на основе BGP, а значит есть возможность использовать все методы оптимизации, что есть и в самом BGP (например в моем стенде уже используется RR, для уменьшения BUM трафика и оптимизации анонсируемой информации). Получилась довольно небольшая часть, но думаю она поможет прояснить некоторые моменты в понимании технологии. OSPF ipv6. Практические навыки =========== Источник: habr.com =========== Похожие новости:
Блог компании OTUS. Онлайн-образование ), #_cisco, #_setevye_tehnologii ( Сетевые технологии ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:33
Часовой пояс: UTC + 5