Перейти к содержимому
Калькуляторы

"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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ThreeDHead

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ThreeDHead

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ThreeDHead

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

 

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

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

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

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

Изменено пользователем rdc

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

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

 

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пример - у абонентов совпали маки.
Билинг не пропустит.
Речь про привязку маков?

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

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

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

 

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

[/offtopic]

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пример - у абонентов совпали маки.
Билинг не пропустит.
Речь про привязку маков?

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

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

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.