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

Покритикуйте схему или как терминировать на 65й больше 4К влан

Идея в том, что при такой схеме можно использовать одну и ту же конфигурацию на всех коммутаторах доступа, сократить число 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...) число привязок мне неизвестно((((

 

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

Screenshot_4.png

Топология_тестового_стенда_test6.png

Топология_тестового_стенда.png

Edited by Stak

Share this post


Link to post
Share on other sites
Идея в том, что при такой схеме можно использовать одну и ту же конфигурацию на всех коммутаторах доступа, сократить число 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"

 

Share this post


Link to post
Share on other sites
Идея в том, что при такой схеме можно использовать одну и ту же конфигурацию на всех коммутаторах доступа, сократить число 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, да? и т.д. и т.п.

 

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

Share this post


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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


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

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

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

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

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

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

 

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

 

Share this post


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

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

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

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

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

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

 

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

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

 

Share this post


Link to post
Share on other sites
на 15к абонентов на 1 железку у вас саб-интерфейсов нехватит.

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

Share this post


Link to post
Share on other sites
на 15к абонентов на 1 железку у вас саб-интерфейсов нехватит.

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

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

Share this post


Link to post
Share on other sites

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

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

Edited by nnm

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

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

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

 

 

Share this post


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

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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

Share this post


Link to post
Share on other sites
Для 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)

Edited by Stak

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Если делать 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 интерфейса). Доступ опять же обслуживать проще. Да и аггрегацию тоже, особенно если публичные адреса давать - один раз настроил,и забыл, дальше всё управление пользователем через связку БРАС+радиус. При этом БРАС большой производительности не нужен, т.к. через него локальный траффик не идёт, только число сессий имеет значение.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Вопрос по лабе - всё в Dynamips сделано? )
Нет, в Dynamips только ISG на 7200+npe400 - у меня её живъём нету)). свичи реальные.

 

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

Edited by Stak

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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