[cmhungry]

Вы имеете ввиду циску 4500 поддерживающую нетфлоу?

Нет, ASA55xx

оно нетфлоу не умеет

[jab]

оно нетфлоу не умеет

Для нетфлоу достаточно port mirror

[BudushiyISP]

Вы имеете ввиду циску 4500 поддерживающую нетфлоу?

Нет, ASA55xx

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

 

 

[jab]

 

В теории верно, пока не потребовался сквозной MVR.

[Stak]

В теории верно, пока не потребовался сквозной MVR.

А в чем проблема с MVR если он есть на свичах доступа? например на широкоизвестных дес-3028?

[BudushiyISP]

В теории верно, пока не потребовался сквозной MVR.

Чтобы по раз не менять концепцию сети могу ли я выбрать авторизацию PPPoE? только не понятна одна деталь: Допустим ну стоит у меня в ядре L3, статически я на каждого пользователя выделил VLAN, терминация VLAN-ов на L3. PPPoE сессии держит FreeBSD, это что получается запрос от пользователя пройдёт через L3, придёт на FreeBSD и весь локальный трафик будет бегать через FreeBSD ?

[jab]

А в чем проблема с MVR если он есть на свичах доступа? например на широкоизвестных дес-3028?

А еще ?

[Stak]

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

[jab]

В теории верно, пока не потребовался сквозной MVR.

Чтобы по раз не менять концепцию сети могу ли я выбрать авторизацию PPPoE? только не понятна одна деталь: Допустим ну стоит у меня в ядре L3, статически я на каждого пользователя выделил VLAN, терминация VLAN-ов на L3. PPPoE сессии держит FreeBSD, это что получается запрос от пользователя пройдёт через L3, придёт на FreeBSD и весь локальный трафик будет бегать через FreeBSD ?

Концентратор PPPoE придется включать в каждый vlan на L2. Если на клиентской стороне не прописать локальные рауты - все пойдет через PPPoE. Смысла в этом, при поднятых vlan на рыло нет никакого.

[Stak]

В теории верно, пока не потребовался сквозной MVR.

Чтобы по раз не менять концепцию сети могу ли я выбрать авторизацию PPPoE? только не понятна одна деталь: Допустим ну стоит у меня в ядре L3, статически я на каждого пользователя выделил VLAN, терминация VLAN-ов на L3. PPPoE сессии держит FreeBSD, это что получается запрос от пользователя пройдёт через L3, придёт на FreeBSD и весь локальный трафик будет бегать через FreeBSD ?

Уважаемый, PPPoE как бы через Л3 не работает ) В отличии от ППТП например)

[jab]

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

При чем тут количество пользователей ? Тут важнее ширина малтикаствого потока. Если у Вас сквозной поток малтикаста 300 мегабит по сети - то vlan на рыло убивают гигабитный линк насмерть.

[BudushiyISP]

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

Пока аплинки до зданий 100 мегабитные.

 

 

[Stak]

При чем тут количество пользователей ? Тут важнее ширина малтикаствого потока. Если у Вас сквозной поток малтикаста 300 мегабит по сети - то четыре vlan на рыло убивают гигабитный линк насмерть.

Это у Вас один тв канал 300 мегабит? тогда вы правы.

Однако обычно один пользователь более одного канала одновременно не смотрит, и его поток в худшем случае <10 мегабит. При этом на свиче агрегации, на котором все пользовательские вланы и заканчиваются, как бы есть igmp-snooping. И флудит он этим мультикастом только в определённые вланы и на определённых портах определёнными потоками, на которые запрос пришёл от пользователя.

[BudushiyISP]

http://www.telecor.ru/solutions/metroethernet/#name1

 

Тогда в решении по этой ссылке, все пользователи прописывают маршруты со своей стороны что ли ?

 

[jab]

Однако обычно один пользователь более одного канала одновременно не смотрит, и его поток в худшем случае <10 мегабит. При этом на свиче агрегации, на котором все пользовательские вланы и заканчиваются, как бы есть igmp-snooping. И флудит он этим мультикастом только в определённые вланы и на определённых портах определёнными потоками, на которые запрос пришёл от пользователя.

Я там подправил в исходном постинге, пардон. Грубо говоря - при vlan'на рыло, и оборудовании, отличном от связки cisco+dlink - проще пускать unicast IPTV.

[Stak]

О, опять QTECH! Они в этой схеме Л2 тянут до браса)))))))) А некоторые это даже через опрную мплс сеть делают)))))))

[Stak]

Грубо говоря - при vlan'на рыло, и оборудовании, отличном от связки cisco+dlink - проще пускать unicast IPTV.

Да совсем не обязательно. Обосную - есть 1Г линк от агрегации на доступ. На доступе свич 24-48 портов (поддерживает ТОЛЬКО 802.1ку), 10 рыл смотрят тв; суммарная нагрузка от тв - 100Мбит.

 

 

Грубо говоря - при vlan'на рыло, и оборудовании, отличном от связки cisco+dlink - проще пускать unicast IPTV.

Да совсем не обязательно. Обосную - есть 1Г линк от агрегации на доступ. На доступе свич 24-48 портов (поддерживает ТОЛЬКО 802.1ку), 10 рыл смотрят тв; суммарная нагрузка от тв - 100Мбит.

 

[BudushiyISP]

О, опять QTECH! Они в этой схеме Л2 тянут до браса)))))))) А некоторые это даже через опрную мплс сеть делают)))))))

Я вот что подумал может быть применена смешенная схема PPPoE и DHCP авторизации, когда только платный трафик проходит через BRAS, который взаимодействуя с Radius определяет полосу пропускания внешнего трафика для каждой группы пользователей и ведет сбор предбиллинговой информации, а локальный трафик не требующий учета может направляться минуя BRAS по принципам IP маршрутизации, на основе локальных адресов.

В этом случае Свич-рутеры L3 в ядре осуществлять маршрутизацию и могут сами выступать в качестве DHCP серверов локальных адресов, с них можно собирать полную статистику по netflow Однако локальный трафик в этом случае можно ограничить только средствами CAR, предоставляя платному трафику приоритет средствами QoS. В случае DHCP схема становится значительно более сложной в настройках и эксплуатации, что существенно повышает эксплуатационные расходы. Для реальной управляемости сети требуются интеллектуальные коммутаторы доступа.

В случае полной авторизации по DCHP я думаю Option-82 на коммутаторах в стоящих в зданиях не нужен. Так как когда VLAN на юзера, то пофигу, что умеют свичи, так как выдача по op82 осуществляется по VLAN, а не по порту. Шейперов нормальных в L3 нет и соответственно и в этом случае олять придётся пускать трафик через FreeBSD ну или через BRAS. В свете уже проверенных вами уважаемые коллегки решений что же мне выбрать DHCP авторизация или PPPoE ?

 

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

[4vlad]

Здравствуйте!

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

Исходная сеть работает по схеме PPPOE туннелирования, с пробросом соответсвенно всего трафика (интернет/локал) через центр. На доступе - неуправляемые коммутаторы. VLAN на район.

Схему планируется переводить на VLAN до клиента, DCHP адресация, с маршрутизацией всего локального трафика на L3 терминаторах с4948 и выходом в интернет поднятием VPN соединения.

Но т.к. существует проблема быстрой замены коммутаторов на доступе, то предполагается проводить модернизацию с промежуточным этапом: сначала сеть переводится на VLAN до коммутатора доступа, в VLAN прописываются интерфейсы для всех пользователей в доме (соответственно - несколько секондари интерфейсов в VLAN ). Клиентам регистрируются MAC адреса, и по клиентским MAC DCHP сервер раздает IP-адреса (вся клиентская адресация серая).

Интересует вопрос : сможет ли с4948 корректно раздавать адреса через DCHP reley на secondary интерфейсы в VLAN ? Может быть кто-то уже применял такую схему?

[BudushiyISP]

Здравствуйте!

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

Исходная сеть работает по схеме PPPOE туннелирования, с пробросом соответсвенно всего трафика (интернет/локал) через центр. На доступе - неуправляемые коммутаторы. VLAN на район.

Схему планируется переводить на VLAN до клиента, DCHP адресация, с маршрутизацией всего локального трафика на L3 терминаторах с4948 и выходом в интернет поднятием VPN соединения.

Но т.к. существует проблема быстрой замены коммутаторов на доступе, то предполагается проводить модернизацию с промежуточным этапом: сначала сеть переводится на VLAN до коммутатора доступа, в VLAN прописываются интерфейсы для всех пользователей в доме (соответственно - несколько секондари интерфейсов в VLAN ). Клиентам регистрируются MAC адреса, и по клиентским MAC DCHP сервер раздает IP-адреса (вся клиентская адресация серая).

Интересует вопрос : сможет ли с4948 корректно раздавать адреса через DCHP reley на secondary интерфейсы в VLAN ? Может быть кто-то уже применял такую схему?

Вообще я лично думаю если У вас нет необходимости отключать клиентов от локалки при неуплате абон. платы, то схема вполне рабочая. То есть до того как клиент открыл PPPoE тунель он будет сидеть в локалке. Если же Вы полностью хотите перейти на DHCP - то тут встаёт вопрос о корректном использовании Option-82. Ориентироваться можно не по порту, а по IP интерфейсу с которого пришёл запрос. Но это всё в теории - у меня нет практики. А как видите никто еще не ответил мне точно :)

[Stak]

Здравствуйте!

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

Исходная сеть работает по схеме PPPOE туннелирования, с пробросом соответсвенно всего трафика (интернет/локал) через центр. На доступе - неуправляемые коммутаторы. VLAN на район.

Схему планируется переводить на VLAN до клиента, DCHP адресация, с маршрутизацией всего локального трафика на L3 терминаторах с4948 и выходом в интернет поднятием VPN соединения.

Но т.к. существует проблема быстрой замены коммутаторов на доступе, то предполагается проводить модернизацию с промежуточным этапом: сначала сеть переводится на VLAN до коммутатора доступа, в VLAN прописываются интерфейсы для всех пользователей в доме (соответственно - несколько секондари интерфейсов в VLAN ). Клиентам регистрируются MAC адреса, и по клиентским MAC DCHP сервер раздает IP-адреса (вся клиентская адресация серая).

Интересует вопрос : сможет ли с4948 корректно раздавать адреса через DCHP reley на secondary интерфейсы в VLAN ? Может быть кто-то уже применял такую схему?

По поводу вашего вопроса - нужно протестировать, вряд ли где-то применялось подобное.

А в целом - ваши планы несколько странно выглядят - зачем вам в случае влана до абонента ещё и впн? Притом пптп, ибо пппое работать через маршрутизируемую сеть не будет (хотя конечно можно на пппое шлюзе создать по интерфейсу в каждом клиентском влане). Более разумным для вас выглядит переход на ип сессии, без впн.

 

П.С учтите что на с4948 2К svi)

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

[4vlad]

По поводу вашего вопроса - нужно протестировать, вряд ли где-то применялось подобное.

А в целом - ваши планы несколько странно выглядят - зачем вам в случае влана до абонента ещё и впн? Притом пптп, ибо пппое работать через маршрутизируемую сеть не будет (хотя конечно можно на пппое шлюзе создать по интерфейсу в каждом клиентском влане). Более разумным для вас выглядит переход на ип сессии, без впн.

планируется вместо PPPOE поднимать у клиентов VPN туннель , т.е. PPPOE в новой схеме заменяется на VPN (что логично, если появляется локальная IP-адресация).

Авторизация пользователей в схеме с VLAN до дома нужна обязательно (я написал, что т.к. на домах неуправляемые свичи, то сразу схему VLAN до клиента мы применить не можем, поэтому на промежуточном этапе VLAN до узла доступа)

 

Вообще я лично думаю если У вас нет необходимости отключать клиентов от локалки при неуплате абон. платы, то схема вполне рабочая. То есть до того как клиент открыл PPPoE тунель он будет сидеть в локалке. Если же Вы полностью хотите перейти на DHCP - то тут встаёт вопрос о корректном использовании Option-82. Ориентироваться можно не по порту, а по IP интерфейсу с которого пришёл запрос. Но это всё в теории - у меня нет практики. А как видите никто еще не ответил мне точно :)

от локалки в данной схеме отключать можно навешивание ACL на терминирующем интерфейсе с4948 , или выдачей клиенту по DHCP локального адреса из другой IP-сети

[Stak]

Но это всё в теории - у меня нет практики. А как видите никто еще не ответил мне точно :)

А на что Вам точно ответить? На это например:

Так как когда VLAN на юзера, то пофигу, что умеют свичи, так как выдача по op82 осуществляется по VLAN, а не по порту. Шейперов нормальных в L3 нет и соответственно и в этом случае олять придётся пускать трафик через FreeBSD ну или через BRAS. В свете уже проверенных вами уважаемые коллегки решений что же мне выбрать DHCP авторизация или PPPoE ?

Так ведь что для себя выбирать каждый проектировщик сам решает, сообразно ТЗ и местным реалиям. А если не хватает квалификации, то её нужно либо повышать самостоятельно, либо обращаться к специалистам, за денежку)))

 

Пы Сы: в дхцп опции 82 присутствует обычно не только VLAN) Но и порт, и модуль, и мак коммутатора. А иногда это вообще произвольно конфигурируемая строка)

 

планируется вместо PPPOE поднимать у клиентов VPN туннель , т.е. PPPOE в новой схеме заменяется на VPN (что логично, если появляется локальная IP-адресация).

Авторизация пользователей в схеме с VLAN до дома нужна обязательно (я написал, что т.к. на домах неуправляемые свичи, то сразу схему VLAN до клиента мы применить не можем, поэтому на промежуточном этапе VLAN до узла доступа)

На период перехода тяните все вланы до пппое браса, потом переходите к авторизации по дхцп.

[BudushiyISP]

Но это всё в теории - у меня нет практики. А как видите никто еще не ответил мне точно :)

А на что Вам точно ответить? На это например:

Так как когда VLAN на юзера, то пофигу, что умеют свичи, так как выдача по op82 осуществляется по VLAN, а не по порту. Шейперов нормальных в L3 нет и соответственно и в этом случае олять придётся пускать трафик через FreeBSD ну или через BRAS. В свете уже проверенных вами уважаемые коллегки решений что же мне выбрать DHCP авторизация или PPPoE ?

Так ведь что для себя выбирать каждый проектировщик сам решает, сообразно ТЗ и местным реалиям. А если не хватает квалификации, то её нужно либо повышать самостоятельно, либо обращаться к специалистам, за денежку)))

 

Пы Сы: в дхцп опции 82 присутствует обычно не только VLAN) Но и порт, и модуль, и мак коммутатора. А иногда это вообще произвольно конфигурируемая строка)

 

планируется вместо PPPOE поднимать у клиентов VPN туннель , т.е. PPPOE в новой схеме заменяется на VPN (что логично, если появляется локальная IP-адресация).

Авторизация пользователей в схеме с VLAN до дома нужна обязательно (я написал, что т.к. на домах неуправляемые свичи, то сразу схему VLAN до клиента мы применить не можем, поэтому на промежуточном этапе VLAN до узла доступа)

На период перехода тяните все вланы до пппое браса, потом переходите к авторизации по дхцп.

Как перебрасывать VLAN-ы до BRAS и пускать через него локалку и Интернет - оно понятно. Только не ясно а зачем тогда в схеме с BRAS применяют L3 коммутатор, если он просто собирает оптику? смысл

 

Тут обсуждалась данная схемка вот тут http://forum.nag.ru/forum/index.php?showto...46413&st=20 и на этой странице и там я заметил ключевую фразу "Sergey_Taurus, вы плохо слушаете. Option 82 вам использовать не нужно! Вы будете использовать опцию DHCP Relay т.е. роутер сам будет запрашивать у DHCP сервера какой IP выдать абоненту на данном IP интерфейсе. Никакие VID вам анализировать не нужно." Всё это вводить меня в тупик не ясен процесс организации DHCP авторизации и его связи с биллингом без Option 82? как?

 

[4vlad]

Как перебрасывать VLAN-ы до BRAS и пускать через него локалку и Интернет - оно понятно. Только не ясно а зачем тогда в схеме с BRAS применяют L3 коммутатор, если он просто собирает оптику? смысл

 

Тут обсуждалась данная схемка вот тут http://forum.nag.ru/forum/index.php?showto...46413&st=20 и на этой странице и там я заметил ключевую фразу "Sergey_Taurus, вы плохо слушаете. Option 82 вам использовать не нужно! Вы будете использовать опцию DHCP Relay т.е. роутер сам будет запрашивать у DHCP сервера какой IP выдать абоненту на данном IP интерфейсе. Никакие VID вам анализировать не нужно." Всё это вводить меня в тупик не ясен процесс организации DHCP авторизации и его связи с биллингом без Option 82? как?

мы используем DHCP relay в схеме с VLAN до дома и одним SVI на VLAN.

А для чего используется DCHP option 82 ?