[RG-45]

В сети появился медиапортал ,так вот абоны авторизуются по pppoe(cisco 7200),ip абонам выдаются DHCP cisco 7200 ,используем vlan на дом . Подскажите как сделать так чтоб внутренний ресурс был доступен в каждом vlan но и не нарушил структуру vlan?

[shicoy]

Так же как и любой другой ресурс в сети (локальной или Интернет)

[darkagent]

подцепить ресурс отдельным вланом с 7200, и не фильтровать маршрутизацию между сетями например.

[s.lobanov]

Есть подозрение, что ip по dhcp выдаются, но без default gw, чисто чтобы винда не ругалась, что у неё нет ip-адреса. Это так? Тогда задачка немного поинтереснее.

[RG-45]

Есть подозрение, что ip по dhcp выдаются, но без default gw, чисто чтобы винда не ругалась, что у неё нет ip-адреса. Это так? Тогда задачка немного поинтереснее.

Все верно!

[darkagent]

proxy arp

[RG-45]

proxy arp

Думал об этом ,а проще решений нет?

[s.lobanov]

proxy arp

Думал об этом ,а проще решений нет?

 

1. выдать специфический(ие) маршрут(ы) по dhcp. минус в том, что не все cpe съедают специфики

2. NAT 1:1 + куча вьюх в dns. минус в большом объёме конфигурационных файлов

 

Что мешает выдать default gw по dhcp? Всё равно pppoe-соединение будет иметь меньшую метрику в таблице маршрутизации

[GFORGX]

А в чём, собственно, проблема маршрутизировать в VLAN с этим медиаресурсом PPPoE-сессии?

[s.lobanov]

GFORGX

Вероятно, чтобы в обход полисера трафик шёл.

[Negator]

Всё равно pppoe-соединение будет иметь меньшую метрику в таблице маршрутизации

Это не всегда так

[RG-45]

Всё равно pppoe-соединение будет иметь меньшую метрику в таблице маршрутизации

Это не всегда так

Все верно ! Хотелось бы чтоб скорость к медиаресурсу не шейпилась (PPPOE) ..... Как то так...

[s.lobanov]

Всё равно pppoe-соединение будет иметь меньшую метрику в таблице маршрутизации

Это не всегда так

 

На винде это вроде так. Для cpe-шок не актуально, всё равно там будет настроен pppoe. Остальное случаи это капля в море

[RG-45]

Так вроде бы конкретного ничего и не посоветовали....

[GFORGX]

Так вроде бы конкретного ничего и не посоветовали....

А вы думали, Вам тут готовое решение Вашей проблемы за бесплатно предоставят? :)

 

Единственным адекватным решением вижу пропуск данного трафика через PPPoE, а дальше уже - да, в обход шейпера/полисера. Можете, например, трафик на входе в этот VLAN помечать определённым ToS/DSCP, а там уже шейпить в зависимости от его значения. И не надо городить dual access!

[RG-45]

Так вроде бы конкретного ничего и не посоветовали....

А вы думали, Вам тут готовое решение Вашей проблемы за бесплатно предоставят? :)

 

Единственным адекватным решением вижу пропуск данного трафика через PPPoE, а дальше уже - да, в обход шейпера/полисера. Можете, например, трафик на входе в этот VLAN помечать определённым ToS/DSCP, а там уже шейпить в зависимости от его значения. И не надо городить dual access!

 

А как быть то с радиус атрибутами которые выдает биллинг.

[sirmax]

GFORGX

по мне дуал-акцесс в разы проще

но и то и то изращение =) Долой тунели )

[GFORGX]

Так вроде бы конкретного ничего и не посоветовали....

А вы думали, Вам тут готовое решение Вашей проблемы за бесплатно предоставят? :)

 

Единственным адекватным решением вижу пропуск данного трафика через PPPoE, а дальше уже - да, в обход шейпера/полисера. Можете, например, трафик на входе в этот VLAN помечать определённым ToS/DSCP, а там уже шейпить в зависимости от его значения. И не надо городить dual access!

 

А как быть то с радиус атрибутами которые выдает биллинг.

Как я понимаю, у вас биллинг выдаёт в аттрибутах rate-limit. Сделайте так, чтобы он отдавал servic-policy, создайте соответствующие policy-map-ы и в них по два class-map-а - один для нулевого dscp, а другой - для того, который навешаете на VLAN с контентом. Как навешивается - не скажу, ибо не делал в IOS, навешиваю на бордере с линуксом, но, думаю, гуглить не более 5 минут :)

 

GFORGX

по мне дуал-акцесс в разы проще

но и то и то изращение =) Долой тунели )

На мой взгляд, туннели или IP - уже вопрос второй. Главное, чтобы CE был представлен одним и только одним интерфейсом в сторону PE/BRAS.

[agr]

Можно матчить медиатрафик и по ip адресам, например следующий конфиг ограничит скорость с условных медиасетей (X.X.X.X Y.Y.Y.Y) к пользователю до 50Мбит/с, а со всех остальных адресов до 1Мбит/с

 

policy-map 1m-out

class MEDIA

police cir 50000000 bc 468750 be 937500

conform-action transmit

exceed-action drop

class class-default

police cir 1000000 bc 187500 be 375000

conform-action transmit

exceed-action drop

 

class-map match-all MEDIA

match access-group name MEDIA

 

ip access-list extended MEDIA

permit ip X.X.X.X Y.Y.Y.Y any

[RG-45]

Так вроде бы конкретного ничего и не посоветовали....

А вы думали, Вам тут готовое решение Вашей проблемы за бесплатно предоставят? :)

 

Единственным адекватным решением вижу пропуск данного трафика через PPPoE, а дальше уже - да, в обход шейпера/полисера. Можете, например, трафик на входе в этот VLAN помечать определённым ToS/DSCP, а там уже шейпить в зависимости от его значения. И не надо городить dual access!

 

А как быть то с радиус атрибутами которые выдает биллинг.

Как я понимаю, у вас биллинг выдаёт в аттрибутах rate-limit. Сделайте так, чтобы он отдавал servic-policy, создайте соответствующие policy-map-ы и в них по два class-map-а - один для нулевого dscp, а другой - для того, который навешаете на VLAN с контентом. Как навешивается - не скажу, ибо не делал в IOS, навешиваю на бордере с линуксом, но, думаю, гуглить не более 5 минут :)

 

GFORGX

по мне дуал-акцесс в разы проще

но и то и то изращение =) Долой тунели )

На мой взгляд, туннели или IP - уже вопрос второй. Главное, чтобы CE был представлен одним и только одним интерфейсом в сторону PE/BRAS.

 

А можно ли оставить rate-limit устанавливаемый биллингом на внешку ,а каким либо правилом ,решением , выход на ip медиапортала в обход шейпера .... Чтоб проще было ...как-то так!

[GFORGX]

А можно ли оставить rate-limit устанавливаемый биллингом на внешку ,а каким либо правилом ,решением , выход на ip медиапортала в обход шейпера .... Чтоб проще было ...как-то так!

rate-limit у Вас ограничивает всё, что проходит через интерфейс. Поэтому Вам необходимо создать на циске policy-map-ы по тарифам и вложенные class-map-ы в зависимости от DSCP или соответствия access-list-ам, как Вам выше показали. А в биллинге отдавать в аттрибутах service-policy <tariff_name> in/out.

Изменено 30 августа, 2011 пользователем GFORGX

[RG-45]

А можно ли оставить rate-limit устанавливаемый биллингом на внешку ,а каким либо правилом ,решением , выход на ip медиапортала в обход шейпера .... Чтоб проще было ...как-то так!

rate-limit у Вас ограничивает всё, что проходит через интерфейс. Поэтому Вам необходимо создать на циске policy-map-ы по тарифам и вложенные class-map-ы в зависимости от DSCP или соответствия access-list-ам, как Вам выше показали. А в биллинге отдавать в аттрибутах service-policy <tariff_name> in/out.

 

 

Кажется Lanbilling 1/9 такие атрибуты service-policy выдавать не умеет....

[agr]

Кажется Lanbilling 1/9 такие атрибуты service-policy выдавать не умеет....

 

Ваш биллинг (а вернее радиус) отдаёт BRAS'у Radius атрибуты под названием Cisco-AVPair. Подозреваю, что сейчас у вас в этих атрибутах выдаётся что-то типа:

 

lcp:interface-config=rate-limit бла бла бла 

 

вам нужно на cisco завести policy-map'ы с раздельными классами, как вам уже советовали, а радиусе отдавать такие cisco-avpair

lcp:interface-config#1=service-policy input имя_policy-map
lcp:interface-config#2=service-policy output имя_policy-map

[sirmax]

тут есть 2 подхода.

1 - дуал аксесс когда локальный траффик не маршрутизируется до шейпера.

2 - когда локальный траффик не шейпиться

 

Каждый из этих подходов имеет как плюсы так и минусы. Я стороник 1-го варианта, но еще лучше совсем отказаться от тунелей.