ThreeDHead Опубликовано 16 марта, 2013 · Жалоба Для уменьшения броадкаст-домена, надо изолировать порты абонентов и включить на агрегации "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 Что за "каша" будет при этом твориться в сегменте? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 16 марта, 2013 · Жалоба ThreeDHead Кто раньше ответит(сосед или точка терминирования) - того mac и появится в таблице arp, т.е. трафик будет как "напрямую" так и через точку терминирования, т.е. как повезёт Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 16 марта, 2013 · Жалоба ThreeDHead Кто раньше ответит(сосед или точка терминирования) - того mac и появится в таблице arp, т.е. трафик будет как "напрямую" так и через точку терминирования, т.е. как повезёт При этом будет "ощущаться" какие проблемы? Каков вообще алгоритм будет у клиента? Он сможет оба соответствия в ARP-таблицу в писать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 16 марта, 2013 · Жалоба Он сможет оба соответствия в ARP-таблицу в писать? Я не видел ни одной системы, которая умела бы писать 2 соответствия в arp-таблицу. При этом будет "ощущаться" какие проблемы? Не сталкивался с каким-то проблемами в похожей ситуацией, но делал это не в абонентском сегменте, а там где всего несколько типов устройств. А в принципе, особо умные фаерволы или что-то подобное могут воспринять подобный трафик(2 arp-reply подряд с разными маками) как атаку. P.S. Вместо создания сомнительных схем, просто поделите сегмент вланами на том оборудовании, где нет port-isolate Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 16 марта, 2013 · Жалоба P.S. Вместо создания сомнительных схем, просто поделите сегмент вланами на том оборудовании, где нет port-isolate У нас есть на районы побиты по 10 абонентских виланов, но проблема в том что эти виланы присутствуют во всех коммутаторах района. Получается, что есть 10 сетей размером с район, каждая, в каждой сети по ~десятой части абонентов района. Вот тут про изоляцию и вспомнили... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 16 марта, 2013 · Жалоба Сделайте vlan per customer. Решит все проблемы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[S] Опубликовано 16 марта, 2013 · Жалоба Либо vlan-на-абонента, либо плавно вводить vlan-на-здание. У вас получается абонент А напрямую через magistaral-switch "видит" абонента Б, и судя по всему, не только его. Локально разгружается aggregation-switch, но глобально у вас слишком много устройств в широковещательном влане, это чревато как минимум штормом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andryas Опубликовано 16 марта, 2013 · Жалоба Как миниум vlan на свич, проблем не будет, у меня такая схема работала лет 5, ещё около 50 свичей в моей сети работают именно по этой технологии. Далее, при необходимости переходить на vlan на абонента. Но при достаточно умном доступе это не особо нужно, и не требует сильного ядра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 16 марта, 2013 · Жалоба Сделайте vlan per customer. Решит все проблемы. ' timestamp='1363430924' post='819887']Либо vlan-на-абонента, либо плавно вводить vlan-на-здание. Изоляция портов сделает ровным счетом то-же самое, только "щелчком двух пальцев". ' timestamp='1363430924' post='819887']У вас получается абонент А напрямую через magistaral-switch "видит" абонента Б, и судя по всему, не только его. Локально разгружается aggregation-switch, но глобально у вас слишком много устройств в широковещательном влане, это чревато как минимум штормом. Конечно, это я понимаю. Тут больше не штормы страшны, а раздутые до посинения fdb на коммутаторах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[S] Опубликовано 16 марта, 2013 · Жалоба Я так понимаю, вы сами в курсе, что за "каша" будет твориться. Если у вас ни один свич не умеет traffic segmentation, то в таком случае только vlan-на-здание. Или я вас (вопрос) не правильно понял? Конечно, это я понимаю. Тут больше не штормы страшны, а раздутые до посинения fdb на коммутаторах. Ну я и написал: "как минимум". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 16 марта, 2013 · Жалоба rdc (Сегодня, 14:09) писал: Сделайте vlan per customer. Решит все проблемы. (Сегодня, 14:48) писал: Либо vlan-на-абонента, либо плавно вводить vlan-на-здание. Изоляция портов сделает ровным счетом то-же самое, только "щелчком двух пальцев". не совсем. когда много хостов в одном влан и если даже всё изолировано, то всё равно есть такие неприятные вещи как mac-flapping, особенно если флапает мак-адрес шлюза. Ну ещё бывает лишний unknown unicast, особенно в случае простого терминирования, тогда время жизни arp-записи(по умолчанию) - 20минут, время жизни мак-адреса - 5 минут и поэтому может получиться приличное кол-во unknown unicast трафика. Практика показывает, что больше вланов - меньше проблем. Влан на свитч это хороший компромисс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 16 марта, 2013 · Жалоба VLAN на дом подразумевает ip-сеть на дом. Тут больше организационный аопрос - ip-адреса прописаны у абонентов в договорах, и т.д., и т.п. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 16 марта, 2013 · Жалоба LAN на дом подразумевает ip-сеть на дом. Тут больше организационный аопрос - ip-адреса прописаны у абонентов в договорах, и т.д., и т.п. Вот с этого и надо было начинать, что у вас нет возможности малой кровью провести ip-ренамберинг. Абоненты хоть по dhcp получают свои адрес(а в конфиге уже статика - тогда к чем привязка?) или настоящая статика? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 16 марта, 2013 · Жалоба LAN на дом подразумевает ip-сеть на дом. Тут больше организационный аопрос - ip-адреса прописаны у абонентов в договорах, и т.д., и т.п. Вот с этого и надо было начинать, что у вас нет возможности малой кровью провести ip-ренамберинг. Абоненты хоть по dhcp получают свои адрес(а в конфиге уже статика - тогда к чем привязка?) или настоящая статика? По DHCP получают, всегда одно и то-же, что в договоре. Некоторые прописывают статикой, только это ничего не меняет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 16 марта, 2013 · Жалоба ThreeDHead Кто раньше ответит(сосед или точка терминирования) - того mac и появится в таблице arp, т.е. трафик будет как "напрямую" так и через точку терминирования, т.е. как повезёт Скорее кто позже ответ, тот и будет в таблице, т.к. второй мак тут же перезапишет первый. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 16 марта, 2013 (изменено) · Жалоба Изоляция портов сделает ровным счетом то-же самое, только "щелчком двух пальцев".Нет, не то же самое.При изоляции портов всё равно можно огрести массу проблем. Пример - у абонентов совпали маки. Другой пример - абонент поставил себе ip-адрес соседа. Друг друга не видят, а проблемы всё равно есть. В случае же vlan per customer у абонента нет никакой возможности напакостить соседям. Ни сознательно, ни сдуру. Тут больше организационный аопрос - ip-адреса прописаны у абонентов в договорахОоооооочень плохая практика.У абонента по умолчанию должно быть dhcp, никаких адресов в договорах, иначе связываете себе руки. Адрес в договоре (кстати, а зачем он там?) может быть только в одном случае - если абонент в явном виде запросил фиксированный адрес. В том случае, если это платная услуга, ею пользуется менее 10% абонентов. А ренамберинг может приспичить в любой момент… Изменено 16 марта, 2013 пользователем rdc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 16 марта, 2013 · Жалоба Скорее кто позже ответ, тот и будет в таблице, т.к. второй мак тут же перезапишет первый. ДА, скорее именно так. Тесты показали что все маки в арп-таблице тестового хоста, от коммутатора агрегации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 16 марта, 2013 · Жалоба Пример - у абонентов совпали маки. Другой пример - абонент поставил себе ip-адрес соседа. Зависит как все организовать. Можно запрещать ARP-ответы с чужих адресов. Если абонент поставит себе чужой IP, то об этом никто не узнает, из-за того, что не пройдет ARP. Вероятность совпадения маков небольшая, а посмотреть маки соседей абонент не сможет. ДА, скорее именно так. Тесты показали что все маки в арп-таблице тестового хоста, от коммутатора агрегации. В любом случае, надо добиться ситуации, чтобы только один хост мог отвечать ARP. Иначе будет "каша". У нас абонент включал у себя proxy-arp, очень долго выясняли причину, почему "у абонентов разрывы". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 16 марта, 2013 · Жалоба Пример - у абонентов совпали маки. Билинг не пропустит. Другой пример - абонент поставил себе ip-адрес соседа. ARP-инспекция умнику отключит порт. У абонента по умолчанию должно быть dhcp, никаких адресов в договорах, иначе связываете себе руки. Иначе вы развязываете абоненту руки в подозрении вас что вы "что-то за его спиной мутите, и сами качаете его трафик". Вы проиграете первый-же суд, если к несчастью абонент будет упертым. Адрес в договоре (кстати, а зачем он там?) может быть только в одном случае - если абонент в явном виде запросил фиксированный адрес. В том случае, если это платная услуга, ею пользуется менее 10% абонентов. Первое - вы учет трафика в сети IPoE, по каким критериям будете осуществлять, если не по IP-адресу? И второе - я говорю про серую сеть и NAT. А ренамберинг может приспичить в любой момент… Конечно! Имя ему IPv6. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 17 марта, 2013 · Жалоба у сиськит есть такая штука как local-proxy-arp, она работает внутри одного интерфейса, тоесть он на любой запрос отвечает своим маком, а proxy-arp только между интерфейсами. Но в любом случае - по схеме на картинке мак появится того кто первый ответит Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 марта, 2013 · Жалоба В зависимости от реализации арп в конкретной системе/версии будет использоваться первый или последний макс адрес привязанный к IP. Фря юзает последний и пишет в лог что IP переехал на новый мак адрес. PS: арп вообще часто реализуют криво в силу не понимания как оно работает, и эти реализации встречаются как в железе так и в ос. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 17 марта, 2013 · Жалоба Пример - у абонентов совпали маки.Билинг не пропустит.Речь про привязку маков?Если да - то такого провайдера надо расстреливать через повешение. Первое - вы учет трафика в сети IPoE, по каким критериям будете осуществлять, если не по IP-адресу?По порту. Снимаю счётчики по snmp.Впрочем, учёт трафика я делаю исключительно в целях диагностики - тарифы безлимитные. Вероятность совпадения маков небольшая,Я бы не сказал.На старой пппое сети я с этим сталивался неоднократно, причём причины были в основном две: 1) абонент сделал mac clone на роутере, а потом роутер после апгрейда был подарен соседям; 2) несколько абонентов залили какую-то альтернативную прошивку, игнорирующую mac роутера и ставящую некий дефолтный. Сейчас, используя dhcp и vlan per customer, я не обращаю внимания на подобные проблемы. а посмотреть маки соседей абонент не сможет.При использовании wifi точки доступа (роутера в режиме моста) соседские маки видны в эфире. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 17 марта, 2013 · Жалоба PS: арп вообще часто реализуют криво в силу не понимания как оно работает, и эти реализации встречаются как в железе так и в ос. [offtopic]Сам недавно сталкивался с зухелевскими -N точками доступа, которые делали ARP-запрос на все подряд адреса, в том числе и не из их сегмента управления. В результате без проксиарпа управление через L3 нее работало. Пришлось пободаться с техподдержкой, но паршивку таки запатчили. [/offtopic] Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 17 марта, 2013 · Жалоба Пример - у абонентов совпали маки.Билинг не пропустит.Речь про привязку маков?Если да - то такого провайдера надо расстреливать через повешение. Погодите немного, не расстреливайте пока, пусть он сначала расскажет как именно биллинг не пропускает мак-адреса? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 17 марта, 2013 · Жалоба Речь про привязку маков? Если да - то такого провайдера надо расстреливать через повешение. Не надо проецировать свои комплексы на окружающих. По порту. Снимаю счётчики по snmp. Впрочем, учёт трафика я делаю исключительно в целях диагностики - тарифы безлимитные. Интересно как вы "порт" прописали в договор :) Покажите ваше определение "порта". "Учет трафика по SNMP" - фантастика какая-то :) Сейчас, используя dhcp и vlan per customer, я не обращаю внимания на подобные проблемы. Мы уже готовы приклониться перед вами. Но счас некогда, чуть позже :) Погодите немного, не расстреливайте пока, пусть он сначала расскажет как именно биллинг не пропускает мак-адреса? Ммм, эээ, ну это ноухау такое, две сточки-то сравнить... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...