Привет,
это как в известном тосте о совпадение желаний и возможностей.
В данном случае «имею желание» соответствует установленному через IP связность сигналингу сервиса, но «не имею возможности» — прерыванию передачи MPLS трафика на уровне data-plane где-то посредине. Как-то так простыми словами.
Спасибо.
Существует три сервисные модели — VLAN-Based, VLAN Bundle и VLAN-Aware.
VLAN Based и VLAN Bundle расположены на разных полюсах с точки зрения сложности управления, масштабируемости и контроля широковещательного трафика. Последняя модель VLAN-Aware — разумный компромисс между этими характеристиками, на пограничных устройствах управление не особенно сложнее классической езернет сети, в ядре — все совсем просто.
symmetric/assymetric модель маршрутизации обусловлена исключительно возможностями коммутационного чипа и реализованными в софте вариантами обмена NLRI. Type 5 анонс может быть рекурсивно раскрыт либо через дополнительную информацию в своих полях (тогда он является самодостаточным) либо через информацию во вспомогательном Type 2 анонсе. Самодостаточные (pure type 5) анонсы обычно используют в таких задачах DCI, где можно или нужно делить сети на третьем уровне, чтобы максимально разделить топологию разных площадок и снизить требования к размерам таблиц коммутации.
В этой статье я не планировал хвалить/ругать конкретные реализации вендора A или B, сферические сравнения рискуют быть бесполезными без проработки деталей. Могу лишь посоветовать — в выборе отталкивайтесь исключительно от требований и условий конкретно вашей задач. И, если вы присматриваетесь к какому-то решению, присматривайтесь к нему со всей внимательностью.
Спасибо, за критику. Не просто находить нужные слова для перевода узкоспециализированных терминов, иногда проще написать оригинальное понятие — в статьях технической направленности я считаю это уместным. При написании именно этой статьи я старался придерживаться понятных не специалистам формулировок. Рад тому, что после прочтения у вас возникло желание копнуть глубже, в концы статьи есть полезные, на мой взгляд, ссылки.
EVPN хорош тем, что топология может быть свободной от каких-то догматов. Если коммутационный чип на leaf позволяет им работать в качестве l2/l3 шлюзов, и потребности портовой емкости согласованы с имеющимися каналами, нет никакой проблемы запустить эту схему.
Не… я не о том, просто хотел обозначить еще одну потенциальную проблему возникновения потерь, разрешение которой обычно не регламентирует договор. Это скорее взгляд со стороны, такие ситуации мне иногда приходится разбирать.
Речь исключительно про каналы второго уровня с большой разницей между контрактной скоростью и физической, в этом случае клиент (обычно это сервер или сервера) кратковременно выдают в канал данные на физической скорости, при этом токен буфер (где бы и на каком-уровне он не находился) переполняется очень быстро. Формально в этой ситуации никто не виноват, а фактически никто не остается довольным. Эта проблема имеет что-то общее с проблемой переполнения буффером коммутаторов в ЦОД, когда источник выдает данные на 40G, а потребитель находится за портом 10G, надеюсь так будет понятнее на что я хотел обратить внимание.
Отдельную радость доставляет согласование канальной скорости подключения и контрактной скорости передачи по каналу. Видел много разногласий по этому поводу когда в условный канал 128kbit/s клиенты плевали данными на скости 1Gb/s объемом с отскейленное окно.
VPN-ам такого рода и сигналинг не нужен )
для PPPoE, к слову, даже IP не нужен, потому-что oE
это как в известном тосте о совпадение желаний и возможностей.
В данном случае «имею желание» соответствует установленному через IP связность сигналингу сервиса, но «не имею возможности» — прерыванию передачи MPLS трафика на уровне data-plane где-то посредине. Как-то так простыми словами.
Chaos Engineering
Книга написана сотрудниками компании.
Существует три сервисные модели — VLAN-Based, VLAN Bundle и VLAN-Aware.
VLAN Based и VLAN Bundle расположены на разных полюсах с точки зрения сложности управления, масштабируемости и контроля широковещательного трафика. Последняя модель VLAN-Aware — разумный компромисс между этими характеристиками, на пограничных устройствах управление не особенно сложнее классической езернет сети, в ядре — все совсем просто.
symmetric/assymetric модель маршрутизации обусловлена исключительно возможностями коммутационного чипа и реализованными в софте вариантами обмена NLRI. Type 5 анонс может быть рекурсивно раскрыт либо через дополнительную информацию в своих полях (тогда он является самодостаточным) либо через информацию во вспомогательном Type 2 анонсе. Самодостаточные (pure type 5) анонсы обычно используют в таких задачах DCI, где можно или нужно делить сети на третьем уровне, чтобы максимально разделить топологию разных площадок и снизить требования к размерам таблиц коммутации.
В этой статье я не планировал хвалить/ругать конкретные реализации вендора A или B, сферические сравнения рискуют быть бесполезными без проработки деталей. Могу лишь посоветовать — в выборе отталкивайтесь исключительно от требований и условий конкретно вашей задач. И, если вы присматриваетесь к какому-то решению, присматривайтесь к нему со всей внимательностью.
EVPN хорош тем, что топология может быть свободной от каких-то догматов. Если коммутационный чип на leaf позволяет им работать в качестве l2/l3 шлюзов, и потребности портовой емкости согласованы с имеющимися каналами, нет никакой проблемы запустить эту схему.
Речь исключительно про каналы второго уровня с большой разницей между контрактной скоростью и физической, в этом случае клиент (обычно это сервер или сервера) кратковременно выдают в канал данные на физической скорости, при этом токен буфер (где бы и на каком-уровне он не находился) переполняется очень быстро. Формально в этой ситуации никто не виноват, а фактически никто не остается довольным. Эта проблема имеет что-то общее с проблемой переполнения буффером коммутаторов в ЦОД, когда источник выдает данные на 40G, а потребитель находится за портом 10G, надеюсь так будет понятнее на что я хотел обратить внимание.