Metro Ethernet и Q-in-Q: нужен ли коммутатор клиента для его поддержки?

Мы смотрим на получение расширения локальной сети для филиала; мы хотели бы, чтобы VLAN в головном офисе присутствовали на этом новом месте. Местные телекоммуникационные компании говорят, что могут выполнять Q-in-Q, но я не считаю, что наши текущие коммутаторы поддерживают Q-in-Q.

Из того, что я читаю, похоже, что согласованные VLAN будут помечены на выходном порту клиента (т. е. на нашем коммутаторе), а затем коммутатор CPE telco будет обрабатывать Q-in-Q и наоборот на другом конце, так что предположительно нам просто нужно пометить соответствующие VLAN на наших портах коммутатора.

Просто хочу быть уверенным, что Q-in-Q не является обязательной функцией переключения на стороне клиента уравнения.

Спасибо

3 голоса | спросил gravyface 30 Maypm18 2018, 13:05:07

2 ответа


4

Ты прав. Обычная услуга заключается в том, что кадры на стороне клиента инкапсулируются на границе сети в кадрах служебной стороны, которые затем выглядят как обычные кадры 802.1q для других коммутаторов в поставщике услуг. Деинкапсуляция происходит на крайнем краю сети, а теги VLAN, установленные клиентом, представлены на интерфейсе, обращенном к клиенту.

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

В этом описании службы также будут перечислены другие важные параметры, например, сколько MAC-адресов может быть видимым для службы, и что произойдет, когда это число будет превышено. Практика там варьируется в широких пределах: «один на клиентский интерфейс» и «отключение до восстановления вручную» является общим для служб, предназначенных для работы между IP-маршрутизаторами (например, соединениями в LINX), и, возможно, несколько тысяч являются типичными для служб, предназначенных для между центральным маршрутизатором и удаленным офисным коммутатором.

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

Убедитесь, что описание сервиса поставщика услуг четко указано о типах BPDU, которые будут прозрачно транспортироваться по всей службе. Вы, по крайней мере, хотите иметь возможность передавать свои связующее дерево и LLDP PDU без изменений. В идеальном сервисе все BPDU передаются без изменений между вашим оборудованием. Служба стресс-тестирования здесь, как правило, представляет собой контрольные BPDU для поддержки шифрования MacSec (и вам действительно стоит подумать о запуске MacSec между интерфейсами вашего поставщика услуг, это самый простой способ защитить себя от подрывной деятельности инфраструктуры поставщика услуг, есть даже SFP который будет запускать MacSec внутренне).

ответил vk5tu 30 Maypm18 2018, 13:32:36
0

Если telco говорит, что они будут делать QinQ, вам это не понадобится на вашем оборудовании. Кроме того, вам не будет необходимо согласовать транспортную VLAN и установить ее на вашем коммутаторе, так как это настройка на устройстве, которое фактически выполняет QinQ. С точки зрения сторонности QinQ у вас есть простое соединение с локальной сетью VLAN-agnostic с удаленным местоположением.

ответил Tomasz Pala 30 Maypm18 2018, 13:20:37

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132