[zi_rus]

а в том как они появляются.

та в подсети работает dhcp-proxy, видимо по выданным адресам они и появляются, я же не про буковку писал, а про то что они есть, причем вообще ничего не настраивал, сам удивился когда их увидел, но тк циска пилит BNG для ASR9k в принципе представляю зачем все это сделано и к чему все идет

[s.lobanov]

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

 

на обычном IOS они тоже появляются(но с буковкой S, а не A) если настроен dhcp-relay.

[zi_rus]

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

[NiTr0]

в оспф не должно быть клиентских маршрутов, ни /30, ни /32. при определенных масштабах, это просто само по себе начинает сказываться на сходимости, лучший вариант использовать людой igp только для распространения лупбеков роутеров, а между ними поднять bgp и в нем гонять все клиентское

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

 

спуфинг на доступе должен быть закрыт, это же азбука

Т.е. в схеме влан на юзера еще и свичи должны уметь опцию 82 с source guard'ом, так?

А в схеме с shared l2 и статическими ip - на свичах придется прописывать ACL-ями исключения?

 

В IPoE маршрут /32 создается с единственной целью - проанонсить маршруты через протокол маршрутизации и сообщить соседям. Больше ни для чего не требуется данный костыль. В PPP есть отдельные интерфейсы, поэтому там маршрут /32 объективная необходимость.

Нет. /32 создается для того, чтобы указать путь трафика клиента. Ну т.е. на каком ифейсе он будет висеть. Вся широкая подсеть пула не вешается. Независимо от того - 1 клиент на интерфейсе, или 100.

 

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

DHCP запросы идут на радиус сервер. ARP - радиус на каждый ARP дергать же не будете?

 

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

Вы о чем вообще сейчас? О кабельных сетях с вланом на пользователя/опцией 82 на порту, или о wifi помойке без радиус-авторизации клиентов, где ип-маки проконтроллировать невозможно? О необходимости утсанавливать IP вручную, или о возможности несанкционированной установки IP? Потому как начали за здравие, а кончили за упокой - начали о необходимости кому-то прописать статику, а окончили несанкционированной установкой статики...

 

На цисках бывает все что можно. Проблема в том, что установка необходимых цисок чаще всего делает проект бессмысленным с экономической точки зрения.

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

Скажите уж прямо - не нравится что на микротиках так не осилил вендор реализовать :)

[Ivan_83]

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

В твоём случае нельзя.

У тебя же мак уже проверен на входе в сеть.

 

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

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

Не купируется без ACL только спуфинг IP шлюза.

[zi_rus]

Ну бгп с совсем не нулевым временем обновления маршрутов - не лучший вариант.

у бгп сходимость внутри сети зависит исключительно от сходимости igp и количества маршрутов, причем второе уже победили с помощью BGP PIC, но это зависит от железки, так что действительно у кого-то могут быть проблемы. однако, если машррутов мало, то разницы фактически не будет, если много, значит клиентов много, значит можно позволить нормальное оборудование.

 

да вообще это обычный интернет, не нужна там миллисекундная сходимость.

 

в схеме влан на юзера

нет никакой проблемы спуфинга

 

в схеме с shared l2 и статическими ip

в зависимости от реализации статики

если статика прописана в биллинге, то выдача адреса по связке порт/мак не имеет проблем

если ip прибивается на клиентской железке без dhcp, то простая команда все решает (ну это я опять про циски)

ip dhcp snooping binding aaaa.aaaa.aaaa vl 7 1.1.1.1 interface Fa0/1

[NiTr0]

нет никакой проблемы спуфинга

Смотря как построено. Sonne, как я понял, хочет, чтобы при поступлении от клиента арп запроса с установленным статикой ип тут же создавался маршрут на клиента. Итог - клиент начинает менять ип (ну, там, вирь гадит), и сеть засирается маршрутами...

Не, можно прибивать костылями ип к порту - но это ИМХО криво, и смысл от редистрибуции арп маршрутов теряется (с тем же успехом тупо вбивается статический /32 через интерфейс и клиент работает).

Можно конечно на каждый арп чих спрашивать у радиуса - но это не менее криво, и арп флуд положит радиус-сервер.

[s.lobanov]

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

 

Фича работает, но это никак не гипотетический redistribute arp, который "изобрёл" Sonne (основная идея которой как я понял - без создания маршрута в таблицы маршрутизации анонсировать часть содержимого arp-таблицы по ospf/bgp/прочему)

 

Не удивлюсь, если у какого-нибудь вендора если появится очередная фича с приставкой "Russia" типа "Russia PPTP Dual Access".

 

ARP - радиус на каждый ARP дергать же не будете?

 

Не на каждый запрос. А на каждое значительное изменение arp-таблицы(т.е. любое изменение кроме счётчика expire)

[zi_rus]

Фича работает, но это никак не гипотетический redistribute arp, который "изобрёл" Sonne

Я думаю тут надо идти от начала, абонент не может послать арп если у него нет ip, а ip должен выдавать провайдером каким-то способом (arp таким способом не является), именно способ выдачи адреса и будет решать как о подключившемся клиенте узнает сеть. даже когда у абонентов статические адреса, некая привязка должна быть, иначе кто угодно сможет подключаться к сети и пользоваться.

[NiTr0]

Не на каждый запрос. А на каждое значительное изменение arp-таблицы

Спуфинг же...

[weedman]

Привет всем из этой старой темы, я не некропостер, просто стало интересно:

1) Вот сейчас что-то изменилось? Чтобы без особых заморочек, костылей и гибко

2) Если клиенты в большей массе по радио на микротах, которые по факту и есть клиенты, получают адреса по DHCP, натятся, ну и в свою очередь раздают свою сеть тоже по DHCP. То получается не нужно заморачиваться с фрагментацией сети, вланами, или PPPoE, для решения проблемы со штормами\флудами и прочими возможными проблемами? Можно смело вешать /24 и раздавать с привязкой к маку? Ну а там, где Микрот бриджем, все же прокинуть Vlan или отдельно сажать на PPPoE?

3) При оказании услуги предоставления ТВ+все что там может присутствовать, это удобнее делать через Vlan? Если я правильно понимаю, то с PPPoE не возникнет проблем и туда просто пробросится все точно так же?

[Saab95]

Основной плюс PPPoE в том, что можно легко изолировать абонентов одной БС от другой. Достаточно прокинуть уникальный влан от каждой БС (или EoIP) туннель, или заблокировать на транспорте все протоколы по направлениям, кроме PPPoE.

 

С IP так просто не сделать, там есть ARP, для запросов DHCP так же не все просто. Поэтому вопрос надо смотреть не в возможности, а в уменьшение широковещательных сегментов сети.

 

Поэтому сейчас если говорить про беспроводную сеть, то выгодно до каждой БС прикинуть канал, на каждой БС поднять OSPF маршрутизацию, на каждой БС настроить DHCP сервер, выделив некую серую подсеть для адресации, и раздавать на CPE адреса по DHCP без туннелей, это снизит нагрузку на оборудование и вернет МТУ до 1500 байт.

 

ТВ сейчас выгодно подавать юникастом поверх основной сети.

[weedman]

22 минуты назад, Saab95 сказал:

Основной плюс PPPoE в том, что можно легко изолировать абонентов одной БС от другой. Достаточно прокинуть уникальный влан от каждой БС (или EoIP) туннель, или заблокировать на транспорте все протоколы по направлениям, кроме PPPoE.

 

С IP так просто не сделать, там есть ARP, для запросов DHCP так же не все просто. Поэтому вопрос надо смотреть не в возможности, а в уменьшение широковещательных сегментов сети.

 

Поэтому сейчас если говорить про беспроводную сеть, то выгодно до каждой БС прикинуть канал, на каждой БС поднять OSPF маршрутизацию, на каждой БС настроить DHCP сервер, выделив некую серую подсеть для адресации, и раздавать на CPE адреса по DHCP без туннелей, это снизит нагрузку на оборудование и вернет МТУ до 1500 байт.

 

ТВ сейчас выгодно подавать юникастом поверх основной сети.

У меня серая подсеть, которую нужно выдать - \24. Как в этом случае быть с DHCP-сервером на БС? Сегментировать на БС подсети  Х.Х.Х.Х/27 (условно) из этой /24 и как тогда связать это все с центром?

[Saab95]

Если у вас ограниченный ресурс адресации, тогда можно выдавать IP адреса поштучно вида address=11.22.33.1 network=11.22.33.адрес_абонента, прописывается это все дело, например, на бридже куда попадают абоненты при подключении. Если там будет 10 абонентов, то заведете так же 10 копий адресов, меняя только адрес абонента в network. Так же туда вешаете DHCP сервер, а сами адреса для раздачи привязываете по мак адресу абонентской антенны.