Jump to content

Recommended Posts

Posted

Такой вот вопрос назрел.

На коммутаторах доступа включена изоляция портов, трафик может ходить только на аплинк.

Даю некоторым клиентам L2VPN. Когда они в разных местах, тогда все хорошо, но иногда получается так, что обе точки подключены в один коммутатор доступа.

И тогда, разумеется, трафик у них не ходит.

Если с этих портов убрать изоляцию, тогда все начинает работать, но это не лучшее решение.

Я бы хотел, чтобы трафик L2VPN ходил до ядра и коммутировался уже там. Но коммутаторы доступа пакеты в аплинк не передают; как я понимаю, если источник и приемник на коммутаторе, но изолированы, то пакеты просто дропаются.

Пока что мне на ум только одно решение приходит — помещать точки L2VPN в разные VLAN и бриджевать на ядре.

Но может можно что-то другое придумать?

Posted

Вам шашечки или ехать?

 

В едро то он уйдет, а как вернется?

 

 

А по теме: В едре делаете interface vlan xxx, а на нем ip proxy-arp. Это если циска.

Posted

Вам шашечки или ехать?

 

В едро то он уйдет, а как вернется?

Согласен, тогда только разные вланы

Posted

Видимо я что-то не понял.

Вот у меня пачка VLAN: 301, 302, 303, ..., 399.

Мне нужно "соединить" 301+302, 303+304, 305+306+307.

Если я создам пачку interface vlan и везде укажу ip proxy-arp, разве не получится полная каша?

Мне фактически нужен mpls pseudowire, только у меня нет MPLS.

На маршрутизаторах Cisco можно сделать сабинтерфейсы и сбриджевать их, но у меня из подходящих железок на ядре только каталисты (которые так не умеют) и Extreme X670. Extreme наверняка такое умеет, но я бы предпочел эту задачу передать на каталисты.

Posted

я бы просто отключил изоляцию портов и не занимался ерундой. Не смысла гонять через центр трафик между двумя портами одного свича

Потому что опять начинается, того не могу, этого нету, и никто не помнит зачем вообще это надо было

Posted

Смысл в единообразии настроек оборудования.

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

А отключать изоляцию портов нежелательно, у меня PPPoE и VLAN на дом/ветку.

Кроме того, на доступе мало возможностей по управлению полосой и приоритетами (некоторые коммутаторы умеют только на egress применять полисер), а на ядре этих возможностей больше.

Posted

Изоляцию отключать только для портов с этми сервисом. или ваши свичи этого тоже не умеют?

Posted

Вроде бы на русском языке писал.

Сейчас я именно так и делаю.

Но мне это кажется не очень правильным, я бы предпочел гонять трафик до ядра и коммутировать там.

Posted

Пока что мне на ум только одно решение приходит — помещать точки L2VPN в разные VLAN и бриджевать на ядре.

 

Если вы хотите гнать трафик до "ядра", то запихивать порты одного свитча в разные вланы это лучшее решенее. Другое дело чем их бриджевать... Надо ли очень хороший свитч, либо костыли

 

Ну а вообще не вижу причин не отключать порт-изоляцию на конкретных портах, куда включены 2 точки L2VPN-клиента. Всё равно ж влан будет отличаться от других портов, так что не нагадят они другим абонентам.

Posted

Повторюсь. Два абонента в одном vlan будут общаться через ядро если в ядре завести на этот влан интерфейс и включить ip proxy-arp. Только ядро должно знать ip абонентов, потому как будет уже маршрутизировать этот трафик. Не забыть выделить в отдельный vrf.

 

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

Posted (edited)

трафик не будет бежать через ядро при л3 интерфейсе и прокси-арпе

так-как банальный arp запрос прилетит быстрее из соседнего порта нежели от ядра, только начнутся ещё и непонятки в виде "хост пытается подменить арп запись, АХТУНГ!!"

вот всякие аннамбереды + разные вланы эт да

 

в ядре:

создаете лупбек, на него ипишку

и вешаете Н количество вланов с включеным прокси-арп

на доступе:

изоляцию не трогаете, разносите порты в разные вланы

 

профит

 

только на каждого клиента свой лупбек есесно

Edited by GrandPr1de
Posted

 

в ядре:

создаете лупбек, на него ипишку

и вешаете Н количество вланов с включеным прокси-арп

 

Какую ip-шку надо вешать на лупбек? На n-ное кол-во SVI разве не должно быть маршрутов, какие за ними адреса, чтобы proxy-arp отрабатывал? Это уже не l2vpn.

Posted (edited)

в ядре:

создаете лупбек, на него ипишку

и вешаете Н количество вланов с включеным прокси-арп

 

Какую ip-шку надо вешать на лупбек? На n-ное кол-во SVI разве не должно быть маршрутов, какие за ними адреса, чтобы proxy-arp отрабатывал? Это уже не l2vpn.

poll

поидее исходя из ипишек в л2 пространстве клиента хотя хз, может можно и левые ставить

 

Какой IP, я же L2 даю.

 

ну либо бридж либо аннамберед

ваши каталисты не умеют бриджа - зато умеют аннаберед

Edited by GrandPr1de
Posted

Повторюсь. Два абонента в одном vlan будут общаться через ядро если в ядре завести на этот влан интерфейс и включить ip proxy-arp. Только ядро должно знать ip абонентов, потому как будет уже маршрутизировать этот трафик. Не забыть выделить в отдельный vrf.

 

Это говно какое-то извращённое, а не L2VPN. L2 это L2, когда клиент сам назначает IP какие хочет и ISP в этом никак не участвует

Posted

Не знаю сколько у тс абонентов, но есть большая вероятность, когда абон отвалиться, на его место включат другого и никто не вспомнит что там особые настройки, потом разбираться дольше откуда это

 

Я за влан

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.