Привет, незнакомец!

Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!

QinQ, петля и VPLS

отредактировано июня 2016 Раздел: MPLS
В процессе работы возникла у меня чудная задача. Схема, конечно, передает лишь суть.
Небольшая предыстория. Есть вышестоящий провайдер, на рисунке это MX480 с облаком MPLS. Этому провайдеру (Ростелекому) мы всегда предоставляли сеть доступа.. Сейчас мы и Ростелеком в результате объединения - один и тот же провайдер, собственно, Ростелеком. Разделение осталось таким же, мы настраиваем сеть доступа. Удумалось им сделать для клиента L2VPN через VPLS. Есть одна точка в Санкт-Петербурге и есть пять точек в Петрозаводске, для которых я и настраиваю доступ.
С MX480 для клиентов мы берем кадры с двойным тегированием, так как жирно для каждого клиента выделять целый влан. Вот тут и возникла проблема. Для клиентов, настроенных таким образом, исторический РТК всегда выделяет отдельный сабинтерфейс на своем PE (MX480), чтобы они могли нарезать полиси, и мониторить по MRTG. Но т.к. cisco 6509 ведет отдельную таблицу MAC лишь для внешнего тега, получится петля:
1) Компьютер 10.3.25.1 шлет broadcast в vlan 951-255. При этом 6509 выучивает MAC данного компьютера на порту Ge1/1 в 951 влане
2) Broadcast достигает MX480, где VPLS рассылает его во все интерфейсы, ему принадлежащие, кроме входящего xe-0/0/1.9255.
3) Таким образом, кадр из интерфейса xe-0/0/1.9259 вылетает на 6509... и мак адрес компьютера 10.3.25.1 теперь светится за портом Te1/1, потому что внешний тег-то не изменился.
Это, наверное, не петля, но мак-адрес постоянно флапает, из-а чего, естественно, сервис не работает. Я решил проблему тупо - назначил один влан на клиента. Что-то мне кажется, что это очень криво, т.к. каждый узел клиента светится в каждом влане клиента, ну и неэкономное использование вланов.
Я пытался объяснить коллегам из исторического Ростелекома, что правильнее было бы отдать нам один саб-интерфейс на всех клиентов, но что им до проблем в нашей сети, им нужен MRTG. Может быть есть еще какое-то хорошее решение для данной проблемы?
Тэги темы:

Комментарии

  • Гарантировать работоспособность решения без тестов не могу, но в качестве направления. На Juniper в vpls есть mesh-group, внутри которой не ведется пересылка BUM трафика до CE/VE. В случае объединения выходных интерфейсов от MX до одного cat65 в такую группу, бродкаст пришедший с cat6509 в теории не должен улетать обратно. При таком решении, тем не менее связность между разными c-vlan внутри одного s-vlan будет из-за того, что 1/1 и 1/2 на cisco в одном s-vlane.
    Не уверен что эти mesh-group работают для CE девайсов, для PE точно работают. В противном случае можно посмотреть в сторону того как отменить local-switching для CE.
  • А можно ещё раз пояснить про "исторический РТК всегда выделяет отдельный сабинтерфейс на своем PE (MX480)"?
    Не совсем понятно, зачем делать два attachment circuit, которые логически создают петлю и фактически живут в одном bridge-domain, по сути являясь дублированием линка к одному и тому же заказчику, с точки зрения l2vpn как сервиса.
    Даже будь линки физическими, а вместо 6500 - л2 облако с STP, уже не торт. Косяк в дизайне, не городите костылей.
    Режьте вы свои полиси и vlan-ы на 6500, хоть тем же qinq, чтобы он бедный не обманывался. Или может я что-то не так понял? Или что мешает сделать один AC? Брас для слабаков?
    v0lk написал:

    Гарантировать работоспособность решения без тестов не могу, но в качестве направления. На Juniper в vpls есть mesh-group, внутри которой не ведется пересылка BUM трафика до CE/VE. В случае объединения выходных интерфейсов от MX до одного cat65 в такую группу, бродкаст пришедший с cat6509 в теории не должен улетать обратно. При таком решении, тем не менее связность между разными c-vlan внутри одного s-vlan будет из-за того, что 1/1 и 1/2 на cisco в одном s-vlane.
    Не уверен что эти mesh-group работают для CE девайсов, для PE точно работают. В противном случае можно посмотреть в сторону того как отменить local-switching для CE.

    Просто поясню, в контексте cisco-железок (и ios-xr) это может звучать как "запили split-horizon группу, чтобы два AC не могли перекидывать трафик между собой"
  • Chelioz написал:

    А можно ещё раз пояснить про
    Не совсем понятно, зачем делать два attachment circuit, которые логически создают петлю и фактически живут в одном bridge-domain, по сути являясь дублированием линка к одному и тому же заказчику, с точки зрения l2vpn как сервиса.

    Объясняю: потому что им надо сделать MRTG для каждого клиента. На Mx480 у меня доступ лишь на чтение конфига. Моим коллегам без разницы, что у нас одна сеть коммутации, им все едино.. Фактически, мы разные конторы, но они главнее.
    ribeha написал:


    Я пытался объяснить коллегам из исторического Ростелекома, что правильнее было бы отдать нам один саб-интерфейс на всех клиентов, но что им до проблем в нашей сети, им нужен MRTG. Может быть есть еще какое-то хорошее решение для данной проблемы?

    Поэтому я и задал вопрос, т.к. у меня опыта не так много, но, чую, что сделано все криво.
    v0lk написал:

    Гарантировать работоспособность решения без тестов не могу, но в качестве направления. На Juniper в vpls есть mesh-group, внутри которой не ведется пересылка BUM трафика до CE/VE. В случае объединения выходных интерфейсов от MX до одного cat65 в такую группу, бродкаст пришедший с cat6509 в теории не должен улетать обратно. При таком решении, тем не менее связность между разными c-vlan внутри одного s-vlan будет из-за того, что 1/1 и 1/2 на cisco в одном s-vlane.

    Как же там будет связность? там дальше дсламы стоят, броадкаст до дслама дойдет, но c-vlan'ы-то разные, на дсламе кадр и отбросится, т.к. нет там интерфейсов с нужным c-vlan


Войдите или Зарегистрируйтесь чтобы комментировать.