[Stak]

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

 

В продолжение темы:

Собрал посложнее топологию, с двумя брасами и двумя или более свичами на агрегации, с полным резервированием. Потестил, всё работает как запланировано) Может кому пригодится)))

 

Все картинки и конфиги по ссылке:

http://ciscovod.blogspot.com/2009/03/cisco...dhcp-opt82.html

 

 

П.С. Описанное в этой теме будет работать только при цисках или аналогичном железе (мне такое не известно...) на агрегации.

Обязательные фичи:

ip unnumbered on SVI

dhcp snooping witn option 82

Vlan-acl ( VACL или vlan-map acl)

Желательные фичи:

UBRL (позволит заполисить локалку)

 

Масштабируемость ограничена числом привязок dhcp snooping на железку; 8К для 6500+суп720; 64К для 7600+суп720. На мелких (3550-3750-3560...) число привязок мне неизвестно((((

 

П.П.С. Если кто внедрит, отпишите пожалуйста о результатах)))

Изменено 11 февраля, 2010 пользователем Stak

[derini]

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

отвечу выдержкой из анализа проведённого специалистами junper'а про то, почему DHCP это плохо:

 

1) Плохая утилизация адресного пространства

2) Плохая авторизация (Option 61, Option 82)

3) Отсутствие keepalive

4) Отсутствие OAM

5) Невозможность выдать подсеть

6) IP уровень усложняющий резервирование

7) Усложняет переход на IPv6

8) Сложность контроля безопасности

9) Нет поддержки "wholesale"

 

А вот выдержки из мнения специалистов DSLF, о том почему DHCP это плохо:

Критичные недостатки

1) No "Per subscriber authentication"

2) No "Per subscriber state"

3) No "Per subscriber wholesale/vpn selection"

полукритичные:

1) No "Subscriber separation"

2) No "Per subsriber multicast state, BW and Control"

 

[vIv]

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

отвечу выдержкой из анализа проведённого специалистами junper'а про то, почему DHCP это плохо:

 

1) Плохая утилизация адресного пространства

2) Плохая авторизация (Option 61, Option 82)

3) Отсутствие keepalive

4) Отсутствие OAM

6) IP уровень усложняющий резервирование

7) Усложняет переход на IPv6

8) Сложность контроля безопасности

9) Нет поддержки "wholesale"

 

А вот выдержки из мнения специалистов DSLF, о том почему DHCP это плохо:

Критичные недостатки

1) No "Per subscriber authentication"

2) No "Per subscriber state"

3) No "Per subscriber wholesale/vpn selection"

полукритичные:

1) No "Subscriber separation"

2) No "Per subsriber multicast state, BW and Control"

Чтобы не собирать полосатость цитат, не буду каждую строчку выделять. Но очень прошу развернуть столь убойные результаты анализа. Для примера:

Каким боком способ конфигурирования влияет на утилизацию адресного пространства (см ip-unnumbered)? как он же связан с OAM? каков процент наших операторов (в подключенных домохозяйствах к примеру), умеющих wholesale? Каким боком способ конфигурирования относится к контролю безопасности (см ACL)? Куда пропал 802.1X, доступный опуионально в Ethernet? А... он не относится к DHCP, да? и т.д. и т.п.

 

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

[vIv]

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

Собственно, довольно типовая схема. Есть какие-то вопросы о деталях работы? Я бы пририсовал ещё:

1) от этого Aggregation sw поток sFlow/NetFlow если предусмотрено снятие статистики.

2) если используем одну VLAN на многих портах, то надо либо на доступе, либо на нём же пофильтровать трафик, чтобы адреса абонентов были бы индивидуально проконтроллированы.

[EvilShadow]

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

В произвольный момент времени можно воспользоваться и активными средствами - arping'ом, например. А для меньшей точности есть время аренды адреса. Не продлил - значит выключен.

[Stak]

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

Собственно, довольно типовая схема. Есть какие-то вопросы о деталях работы? Я бы пририсовал ещё:

1) от этого Aggregation sw поток sFlow/NetFlow если предусмотрено снятие статистики.

2) если используем одну VLAN на многих портах, то надо либо на доступе, либо на нём же пофильтровать трафик, чтобы адреса абонентов были бы индивидуально проконтроллированы.

Есть вопросы о натягивании этой схемы на конкретное оборудование. Например с циской 65-й на аггрегации проблем не ожидается ,там и ip unnumbered есть и остальное. Вопрос в том хватит ли ресурсов её для этого.

Т.е. если у нас на ней 240 портов на уровень доступа, по 64 влан на каждом (на доме до 3-х свичей по 24 порта) - это 15К пользователей максимум на каждый коммутатор аггрегации. И столько же привязок dhcp-snooping. Собственно и интересно, потянет ли?

 

Фильтрация естественно будет, дабы побороть левые dhcp сервера.

 

[Nafanya]

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

Собственно, довольно типовая схема. Есть какие-то вопросы о деталях работы? Я бы пририсовал ещё:

1) от этого Aggregation sw поток sFlow/NetFlow если предусмотрено снятие статистики.

2) если используем одну VLAN на многих портах, то надо либо на доступе, либо на нём же пофильтровать трафик, чтобы адреса абонентов были бы индивидуально проконтроллированы.

Есть вопросы о натягивании этой схемы на конкретное оборудование. Например с циской 65-й на аггрегации проблем не ожидается ,там и ip unnumbered есть и остальное. Вопрос в том хватит ли ресурсов её для этого.

Т.е. если у нас на ней 240 портов на уровень доступа, по 64 влан на каждом (на доме до 3-х свичей по 24 порта) - это 15К пользователей максимум на каждый коммутатор аггрегации. И столько же привязок dhcp-snooping. Собственно и интересно, потянет ли?

 

Фильтрация естественно будет, дабы побороть левые dhcp сервера.

на 15к абонентов на 1 железку у вас саб-интерфейсов нехватит.

 

[Stak]

на 15к абонентов на 1 железку у вас саб-интерфейсов нехватит.

В этой схеме сабинтерфейсов будет только 64:) В том то и фокус. Посмотрите повнимательнее на схему, число SVI интерфейсов равно числу влан на свич доступа. А их число=числу портов на свиче агрегации, набор влан на них один и тот же.

[Nafanya]

на 15к абонентов на 1 железку у вас саб-интерфейсов нехватит.

В этой схеме сабинтерфейсов будет только 64:) В том то и фокус. Посмотрите повнимательнее на схему, число SVI интерфейсов равно числу влан на свич доступа. А их число=числу портов на свиче агрегации, набор влан на них один и тот же.

тогда у меня вопрос. при такой схеме в одном vlan на N разных портах получается N клиентов, которые будут друг друга видеть в одной подсети? или не будут видеть? И всё ли будет хорошо, если, допустим в сетку мультикаст пустить?

Изменено 28 октября, 2008 пользователем Nafanya

[nnm]

Для DHCP snooping на 65xx Cisco пишет, что поддерживается 'at least 8000' записей. Что будет на самом деле видимо зависит от результатов хэширования пар MAC/IP. И поэтому непредсказуемо :(

Вообще идея интересная :) но контролировать локальный трафик может быть непросто...

Изменено 28 октября, 2008 пользователем nnm

[zoro]

могу сказать следующее... я месяц как плотно занимаюсь именно этим вопросом...

могу покритиковать слова...

1) Плохая утилизация адресного пространства (точно также как и PPP подобные протоколы) проверенно :) на 300юзверях...

2) Плохая авторизация (Option 61, Option 82) с 82 очень даже не плохо :) ты знаешь точное положение абонента в сети... плюс снупинг на свичах доступа.... и ляпота...

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

 

Минусы... если применять в качестве DHCP сервера циску то можно прикрутить к любому билингу... если применять стандартные DHCP сервера то возникают единственная проблема как передать текущий адрес абонента в биллинг :) NETUP, Lanbilling BGbiling выдавать из пула могут только по радиусу... обратно в билинги адреса не дашшш....

средняя цена доработки этих биллингов = стоимости бу циски с прошивкой 12.3-12.4 в которой есть необходимая функция DHCP Accounting, в линуксах фряхах, микротиках полноценной связки нет :) доработка требует рашпиля... рашпиль на клиентах не хочется испытывать...

 

 

[Stak]

тогда у меня вопрос. при такой схеме в одном vlan на N разных портах получается N клиентов, которые будут друг друга видеть в одной подсети? или не будут видеть? И всё ли будет хорошо, если, допустим в сетку мультикаст пустить?

Да, так и есть, если 240 портов на аггрегаторе - будет один влан на 240 пользователей. По поводу мультикаста тоже потенциальных проблем не вижу... Его предполагается пускать в отдельном влане, с использованием MVR на доступе.

[mikevlz]

для нетапа есть спец модуль, хотспотом зовется. Аккаунтинг с адресами из пула DHCP. Только вот реализация слегка ресурсоемкая и наплыв клиентов не выдерживает. :)

[Nafanya]

тогда у меня вопрос. при такой схеме в одном vlan на N разных портах получается N клиентов, которые будут друг друга видеть в одной подсети? или не будут видеть? И всё ли будет хорошо, если, допустим в сетку мультикаст пустить?

Да, так и есть, если 240 портов на аггрегаторе - будет один влан на 240 пользователей. По поводу мультикаста тоже потенциальных проблем не вижу... Его предполагается пускать в отдельном влане, с использованием MVR на доступе.

недешёвый доступ получается тогда :)

[Stak]

На des-3028 например. MVR там говорят есть:) Но вообще-то, если нужно дешевле доступ сделать, то можно и без MVR. Достаточно только поддержки dot1Q. А IGMP snooping будет работать на аггрегации.

 

для нетапа есть спец модуль, хотспотом зовется. Аккаунтинг с адресами из пула DHCP. Только вот реализация слегка ресурсоемкая и наплыв клиентов не выдерживает. :)

Это можно средствами BRAS реализовать. E-серия у жунипера например подойдёт. Или циски с ISG. Или хуавеи MA5200... Все они могут из опции 82 конструировать юзернайм для авторизации и аккоутинга через радиус. И политики на клиентскую сессию применять, те что на радиусе прописаны.

[Stak]

Для DHCP snooping на 65xx Cisco пишет, что поддерживается 'at least 8000' записей. Что будет на самом деле видимо зависит от результатов хэширования пар MAC/IP. И поэтому непредсказуемо :(

Вообще идея интересная :) но контролировать локальный трафик может быть непросто...

Исходя из этого размах можно несколько уменьшить:

при 3х24 порта свитчах на доступе на каждый линк на аггрегацию подойдёт что-то вроде 6504 с 3х48sfp. Это 9К юзеров максимум на железку , вполне достаточно. Особенно с учётом того, что по 3 свича на доступе будет не везде.

Но вот про максимальное число привязок IGMP snooping на циске ничего не нашёл...

 

По поводу локального траффика: если ip-unnumbered на SVI использовать, то абоненты с адресами выданными не БРАСОМ, за пределы своего влана не выйдут, обратного маршрута /32 на них не будет (144 абонента на влан макимум получается). А пофильтровать лишнее внутри одного влан можно с помощью vlan-acl (http://www.cisco.com/en/US/docs/switches/l....html#wp1037692)

Изменено 29 октября, 2008 пользователем Stak

[nnm]

Если делать DHCP, то VACL наверное не подходит... Что-то закрадывается мысль, что единообразная конфигурация доступа не окупит усложнения общей схемы...

[Stak]

На 7600 можно существенно больше:

With Release 12.2(18)SRA and later releases, the DHCP snooping database stores at least 64,000 bindings.

http://www.cisco.com/en/US/docs/routers/76....html#wp1114949

[Stak]

Если делать DHCP, то VACL наверное не подходит... Что-то закрадывается мысль, что единообразная конфигурация доступа не окупит усложнения общей схемы...

Почему не подходит? См. по предыдущей ссылке: VACLs can provide access control for all packets that are bridged WITHIN a VLAN...

А так как применяются они на вход, то с их помощью можно зафильтровать ненужные dhcp-reply пакеты, от левых dhcp серверов. Ну и другой траффик тоже при необходимости.

 

Усложнения общей схемы же не происходит, наоборот упрощение - SVI интерфейсов намного меньше ,чем в схеме влан-на-пользователя ,особенно если учесть "We recommend that you configure no more than 2,000 Layer 3 VLAN interfaces." из того же мануала , возможность терминировать больше чем 4К пользователей на одном шасси (например 7609+7*48sfp*96(портов на доступе)=32К юзеров, 672 svi интерфейса). Доступ опять же обслуживать проще. Да и аггрегацию тоже, особенно если публичные адреса давать - один раз настроил,и забыл, дальше всё управление пользователем через связку БРАС+радиус. При этом БРАС большой производительности не нужен, т.к. через него локальный траффик не идёт, только число сессий имеет значение.

 

[Stak]

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

[leveler]

Вопрос по лабе - всё в Dynamips сделано? )

[Stak]

Вопрос по лабе - всё в Dynamips сделано? )

Нет, в Dynamips только ISG на 7200+npe400 - у меня её живъём нету)). свичи реальные.

 

Обнаружил неприятную особенность - дхцп снупинг не срабатывает , если активны оба линка между с3560 и ISG... видимо косяк с cef - dhcp reply приходит не на тот интерфейс, откуда ушёл dhcp request.

Изменено 9 февраля, 2009 пользователем Stak

[Stak]

Придумал "плохой" способ победить - сделать один путь с более поганой метрикой чем другой:) Может у кого то лучше решение есть?

[leveler]

А можно забрать кусок лабы, который касается dynamips? :)

[Stak]

А можно забрать кусок лабы, который касается dynamips? :)

Да на здоровье) Конфиги там ранее по ссылке были)