Jump to content
Калькуляторы

"Traffic Segmentation" + "Local Proxy ARP" Теоретический вопрос

Для уменьшения броадкаст-домена, надо изолировать порты абонентов и включить на агрегации "Local Proxy ARP".

Но т.к. не все коммутаторы на доступе умеют "Traffic Segmentation", появился теоретический вопрос.

 

Вот схема:

Абонент А ---[access-switch]---[magistaral-switch]---[aggregation-switch]---[L3-router]---[...]
Абонент Б ---[access-switch]------/

Где:

access-switch - не умеет "Traffic Segmentation"

magistaral-switch - тоже не умеет "Traffic Segmentation"

aggregation-switch - умеет "Traffic Segmentation", ну и представим что он L2+ и даже умеет "Local Proxy ARP"

 

Вопрос такой, что будет в ARP-таблицах абонентов А и Б, при том что они находятся в одной подсети, и передают друг-другу данные?

 

Если бы изоляцию сделали на access-switch или на magistaral-switch, тут все понятно, на ARP-Discovery обоим абонентам ответил бы aggregation-switch и получилось бы:

А) IP-Б <---> MAC-aggregation-switch

Б) IP-А <---> MAC-aggregation-switch

При этом трафик между абонентами бегал бы через aggregation-switch.

 

А вот если изоляцию делать, как на схеме, только на aggregation-switch, то видимо получится так:

А) IP-Б <---> MAC-А

А) IP-Б <---> MAC-aggregation-switch

Б) IP-А <---> MAC-Б

Б) IP-А <---> MAC-aggregation-switch

 

Что за "каша" будет при этом твориться в сегменте?

Share this post


Link to post
Share on other sites

ThreeDHead

Кто раньше ответит(сосед или точка терминирования) - того mac и появится в таблице arp, т.е. трафик будет как "напрямую" так и через точку терминирования, т.е. как повезёт

Share this post


Link to post
Share on other sites

ThreeDHead

Кто раньше ответит(сосед или точка терминирования) - того mac и появится в таблице arp, т.е. трафик будет как "напрямую" так и через точку терминирования, т.е. как повезёт

При этом будет "ощущаться" какие проблемы?

Каков вообще алгоритм будет у клиента? Он сможет оба соответствия в ARP-таблицу в писать?

Share this post


Link to post
Share on other sites

Он сможет оба соответствия в ARP-таблицу в писать?

Я не видел ни одной системы, которая умела бы писать 2 соответствия в arp-таблицу.

 

При этом будет "ощущаться" какие проблемы?

Не сталкивался с каким-то проблемами в похожей ситуацией, но делал это не в абонентском сегменте, а там где всего несколько типов устройств. А в принципе, особо умные фаерволы или что-то подобное могут воспринять подобный трафик(2 arp-reply подряд с разными маками) как атаку.

 

P.S. Вместо создания сомнительных схем, просто поделите сегмент вланами на том оборудовании, где нет port-isolate

Share this post


Link to post
Share on other sites

P.S. Вместо создания сомнительных схем, просто поделите сегмент вланами на том оборудовании, где нет port-isolate

У нас есть на районы побиты по 10 абонентских виланов, но проблема в том что эти виланы присутствуют во всех коммутаторах района. Получается, что есть 10 сетей размером с район, каждая, в каждой сети по ~десятой части абонентов района.

Вот тут про изоляцию и вспомнили...

Share this post


Link to post
Share on other sites

Сделайте vlan per customer. Решит все проблемы.

Share this post


Link to post
Share on other sites

Либо vlan-на-абонента, либо плавно вводить vlan-на-здание.

У вас получается абонент А напрямую через magistaral-switch "видит" абонента Б, и судя по всему, не только его.

Локально разгружается aggregation-switch, но глобально у вас слишком много устройств в широковещательном влане, это чревато как минимум штормом.

Share this post


Link to post
Share on other sites

Как миниум vlan на свич, проблем не будет, у меня такая схема работала лет 5, ещё около 50 свичей в моей сети работают именно по этой технологии.

Далее, при необходимости переходить на vlan на абонента. Но при достаточно умном доступе это не особо нужно, и не требует сильного ядра.

Share this post


Link to post
Share on other sites

Сделайте vlan per customer. Решит все проблемы.

' timestamp='1363430924' post='819887']

Либо vlan-на-абонента, либо плавно вводить vlan-на-здание.

Изоляция портов сделает ровным счетом то-же самое, только "щелчком двух пальцев".

 

' timestamp='1363430924' post='819887']

У вас получается абонент А напрямую через magistaral-switch "видит" абонента Б, и судя по всему, не только его.

Локально разгружается aggregation-switch, но глобально у вас слишком много устройств в широковещательном влане, это чревато как минимум штормом.

Конечно, это я понимаю. Тут больше не штормы страшны, а раздутые до посинения fdb на коммутаторах.

Share this post


Link to post
Share on other sites

Я так понимаю, вы сами в курсе, что за "каша" будет твориться.

Если у вас ни один свич не умеет traffic segmentation, то в таком случае только vlan-на-здание.

Или я вас (вопрос) не правильно понял?

 

Конечно, это я понимаю. Тут больше не штормы страшны, а раздутые до посинения fdb на коммутаторах.

Ну я и написал: "как минимум".

Share this post


Link to post
Share on other sites

rdc (Сегодня, 14:09) писал:

Сделайте vlan per customer. Решит все проблемы.

 

(Сегодня, 14:48) писал:

Либо vlan-на-абонента, либо плавно вводить vlan-на-здание.

 

Изоляция портов сделает ровным счетом то-же самое, только "щелчком двух пальцев".

 

не совсем. когда много хостов в одном влан и если даже всё изолировано, то всё равно есть такие неприятные вещи как mac-flapping, особенно если флапает мак-адрес шлюза. Ну ещё бывает лишний unknown unicast, особенно в случае простого терминирования, тогда время жизни arp-записи(по умолчанию) - 20минут, время жизни мак-адреса - 5 минут и поэтому может получиться приличное кол-во unknown unicast трафика.

Практика показывает, что больше вланов - меньше проблем. Влан на свитч это хороший компромисс.

Share this post


Link to post
Share on other sites

VLAN на дом подразумевает ip-сеть на дом. Тут больше организационный аопрос - ip-адреса прописаны у абонентов в договорах, и т.д., и т.п.

Share this post


Link to post
Share on other sites

LAN на дом подразумевает ip-сеть на дом. Тут больше организационный аопрос - ip-адреса прописаны у абонентов в договорах, и т.д., и т.п.

Вот с этого и надо было начинать, что у вас нет возможности малой кровью провести ip-ренамберинг. Абоненты хоть по dhcp получают свои адрес(а в конфиге уже статика - тогда к чем привязка?) или настоящая статика?

Share this post


Link to post
Share on other sites

LAN на дом подразумевает ip-сеть на дом. Тут больше организационный аопрос - ip-адреса прописаны у абонентов в договорах, и т.д., и т.п.

Вот с этого и надо было начинать, что у вас нет возможности малой кровью провести ip-ренамберинг. Абоненты хоть по dhcp получают свои адрес(а в конфиге уже статика - тогда к чем привязка?) или настоящая статика?

По DHCP получают, всегда одно и то-же, что в договоре. Некоторые прописывают статикой, только это ничего не меняет.

Share this post


Link to post
Share on other sites

ThreeDHead

Кто раньше ответит(сосед или точка терминирования) - того mac и появится в таблице arp, т.е. трафик будет как "напрямую" так и через точку терминирования, т.е. как повезёт

Скорее кто позже ответ, тот и будет в таблице, т.к. второй мак тут же перезапишет первый.

Share this post


Link to post
Share on other sites
Изоляция портов сделает ровным счетом то-же самое, только "щелчком двух пальцев".
Нет, не то же самое.

При изоляции портов всё равно можно огрести массу проблем.

Пример - у абонентов совпали маки.

Другой пример - абонент поставил себе ip-адрес соседа.

Друг друга не видят, а проблемы всё равно есть.

В случае же vlan per customer у абонента нет никакой возможности напакостить соседям. Ни сознательно, ни сдуру.

 

Тут больше организационный аопрос - ip-адреса прописаны у абонентов в договорах
Ооооооочень плохая практика.

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

Адрес в договоре (кстати, а зачем он там?) может быть только в одном случае - если абонент в явном виде запросил фиксированный адрес. В том случае, если это платная услуга, ею пользуется менее 10% абонентов.

А ренамберинг может приспичить в любой момент…

Edited by rdc

Share this post


Link to post
Share on other sites

Скорее кто позже ответ, тот и будет в таблице, т.к. второй мак тут же перезапишет первый.

ДА, скорее именно так. Тесты показали что все маки в арп-таблице тестового хоста, от коммутатора агрегации.

Share this post


Link to post
Share on other sites

Пример - у абонентов совпали маки.

Другой пример - абонент поставил себе ip-адрес соседа.

Зависит как все организовать. Можно запрещать ARP-ответы с чужих адресов. Если абонент поставит себе чужой IP, то об этом никто не узнает, из-за того, что не пройдет ARP.

Вероятность совпадения маков небольшая, а посмотреть маки соседей абонент не сможет.

 

ДА, скорее именно так. Тесты показали что все маки в арп-таблице тестового хоста, от коммутатора агрегации.

В любом случае, надо добиться ситуации, чтобы только один хост мог отвечать ARP. Иначе будет "каша". У нас абонент включал у себя proxy-arp, очень долго выясняли причину, почему "у абонентов разрывы".

Share this post


Link to post
Share on other sites

Пример - у абонентов совпали маки.

Билинг не пропустит.

 

Другой пример - абонент поставил себе ip-адрес соседа.

ARP-инспекция умнику отключит порт.

 

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

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

 

Адрес в договоре (кстати, а зачем он там?) может быть только в одном случае - если абонент в явном виде запросил фиксированный адрес. В том случае, если это платная услуга, ею пользуется менее 10% абонентов.

Первое - вы учет трафика в сети IPoE, по каким критериям будете осуществлять, если не по IP-адресу?

И второе - я говорю про серую сеть и NAT.

 

А ренамберинг может приспичить в любой момент…

Конечно! Имя ему IPv6.

Share this post


Link to post
Share on other sites

у сиськит есть такая штука как local-proxy-arp, она работает внутри одного интерфейса, тоесть он на любой запрос отвечает своим маком, а proxy-arp только между интерфейсами. Но в любом случае - по схеме на картинке мак появится того кто первый ответит

Share this post


Link to post
Share on other sites

В зависимости от реализации арп в конкретной системе/версии будет использоваться первый или последний макс адрес привязанный к IP.

Фря юзает последний и пишет в лог что IP переехал на новый мак адрес.

 

PS: арп вообще часто реализуют криво в силу не понимания как оно работает, и эти реализации встречаются как в железе так и в ос.

Share this post


Link to post
Share on other sites
Пример - у абонентов совпали маки.
Билинг не пропустит.
Речь про привязку маков?

Если да - то такого провайдера надо расстреливать через повешение.

Первое - вы учет трафика в сети IPoE, по каким критериям будете осуществлять, если не по IP-адресу?
По порту. Снимаю счётчики по snmp.

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

 

Вероятность совпадения маков небольшая,
Я бы не сказал.

На старой пппое сети я с этим сталивался неоднократно, причём причины были в основном две:

1) абонент сделал mac clone на роутере, а потом роутер после апгрейда был подарен соседям;

2) несколько абонентов залили какую-то альтернативную прошивку, игнорирующую mac роутера и ставящую некий дефолтный.

Сейчас, используя dhcp и vlan per customer, я не обращаю внимания на подобные проблемы.

а посмотреть маки соседей абонент не сможет.
При использовании wifi точки доступа (роутера в режиме моста) соседские маки видны в эфире.

Share this post


Link to post
Share on other sites

PS: арп вообще часто реализуют криво в силу не понимания как оно работает, и эти реализации встречаются как в железе так и в ос.

[offtopic]Сам недавно сталкивался с зухелевскими -N точками доступа, которые делали ARP-запрос на все подряд адреса, в том числе и не из их сегмента управления.

В результате без проксиарпа управление через L3 нее работало.

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

[/offtopic]

Share this post


Link to post
Share on other sites
Пример - у абонентов совпали маки.
Билинг не пропустит.
Речь про привязку маков?

Если да - то такого провайдера надо расстреливать через повешение.

 

Погодите немного, не расстреливайте пока, пусть он сначала расскажет как именно биллинг не пропускает мак-адреса?

Share this post


Link to post
Share on other sites

Речь про привязку маков?

Если да - то такого провайдера надо расстреливать через повешение.

Не надо проецировать свои комплексы на окружающих.

 

По порту. Снимаю счётчики по snmp.

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

Интересно как вы "порт" прописали в договор :) Покажите ваше определение "порта".

"Учет трафика по SNMP" - фантастика какая-то :)

 

Сейчас, используя dhcp и vlan per customer, я не обращаю внимания на подобные проблемы.

Мы уже готовы приклониться перед вами. Но счас некогда, чуть позже :)

 

Погодите немного, не расстреливайте пока, пусть он сначала расскажет как именно биллинг не пропускает мак-адреса?

Ммм, эээ, ну это ноухау такое, две сточки-то сравнить...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this