Solar Опубликовано 6 февраля, 2012 · Жалоба В сети планируется переход от dual access pppoe к так называемому ipoe, структура сети примерно следующая: на уровне доступа D-Link-и 3526, 3028, 3200, которые агрегируются на Cisco 6509, она же (циска) является default gateway-ем для абонентов, далее циска роутит внутрисетевой трафик, а всё что идёт по рррое туннелям попадает на BRAS по абонентским vlan-ам. Вопрос следующий: при использовании ipoe т.е. когда пользователю будет выдаваться только белый ip возможно ли будет часть трафика по прежнему роутить на циске или весь IPoE трафик будет идти по L2 до самого BRAS-a? P.S. Если вопрос дурацкий не бросайтесь ни чем, а помогите лучше понять механизм работы ipoe в такой схеме. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дятел Опубликовано 6 февраля, 2012 · Жалоба а какими средствами Ip будет выдаваться? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 6 февраля, 2012 · Жалоба В сети планируется переход от dual access pppoe к так называемому ipoe, структура сети примерно следующая: на уровне доступа D-Link-и 3526, 3028, 3200, которые агрегируются на Cisco 6509, она же (циска) является default gateway-ем для абонентов, далее циска роутит внутрисетевой трафик, а всё что идёт по рррое туннелям попадает на BRAS по абонентским vlan-ам. Вопрос следующий: при использовании ipoe т.е. когда пользователю будет выдаваться только белый ip возможно ли будет часть трафика по прежнему роутить на циске или весь IPoE трафик будет идти по L2 до самого BRAS-a? P.S. Если вопрос дурацкий не бросайтесь ни чем, а помогите лучше понять механизм работы ipoe в такой схеме. Вопрос непонятен, особенно в части "она же (циска) является default gateway-ем для абонентов, далее циска роутит внутрисетевой трафик, а всё что идёт по рррое туннелям попадает на BRAS по абонентским vlan-ам". Я так понимаю сейчас схема следующая абонент<=>DLink<=>Cat6509<=>BRAS От абнентов прокинуты до BRAS'а вланы, в которых живут PPPoE сесии. Что вы хотите получить взамен? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Shiva Опубликовано 6 февраля, 2012 · Жалоба Solar, можно сделать как угодно, было бы желание. Если оставлять текущую схему, просто заменив авторизацию и выдавать белые IP, то у вас общение внутри сети останется, в Интернет будут выпускать только тех, кто на BRAS авторизуется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 6 февраля, 2012 · Жалоба при использовании ipoe т.е. когда пользователю будет выдаваться только белый ip возможно ли будет часть трафика по прежнему роутить на циске или весь IPoE трафик будет идти по L2 до самого BRAS-a? Пока на Циске не убран IP, который для клиента является шлюзом, трафик от клиента на интернет-шлюз будет маршрутизироваться Циской. Если на Интернет-шлюз будут дотянуты клиентские vlan'ы и назначены IP-адреса из клиентских подсетей, то обратный трафик от шлюза к клиенту будет проходить через Циску как через layer2. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Solar Опубликовано 7 февраля, 2012 · Жалоба а какими средствами Ip будет выдаваться? ISC DHCP, планируется также использование opt82 Я так понимаю сейчас схема следующая абонент<=>DLink<=>Cat6509<=>BRAS От абнентов прокинуты до BRAS'а вланы, в которых живут PPPoE сесии. Что вы хотите получить взамен? Да, схема именно такая. Хотелось бы с одной стороны оставить разбиение пользовательской сети на vlan-ы, с дугой - иметь возможность маршрутизировать часть трафика (не только внутрисетевого, а, скажем еще и пиринг) до BRAS. Пока на Циске не убран IP, который для клиента является шлюзом, трафик от клиента на интернет-шлюз будет маршрутизироваться Циской. Если на Интернет-шлюз будут дотянуты клиентские vlan'ы и назначены IP-адреса из клиентских подсетей, то обратный трафик от шлюза к клиенту будет проходить через Циску как через layer2. Шлюзом циска является только для "серого" адреса клиента. Дело в том, что, как я понимаю, если оставить vlan-ы до BRAS и использовать 1 белый адрес, то _весь_ клиентский трафик будет проходить через циску по L2, что исключает возможность маршрутизации. Вопрос в том как построить сеть так, чтобы получить клиентский трафик на циске по L3. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 7 февраля, 2012 · Жалоба Шлюзом циска является только для "серого" адреса клиента. Дело в том, что, как я понимаю, если оставить vlan-ы до BRAS и использовать 1 белый адрес, то _весь_ клиентский трафик будет проходить через циску по L2, что исключает возможность маршрутизации. Вопрос в том как построить сеть так, чтобы получить клиентский трафик на циске по L3. Нет, если выдать BRAS адрес из клиентской сети, который не является для клиентов шлюзом. Тогда от клиента до БРАС Циска будет layer3, от БРАС к клиенту - layer2. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Solar Опубликовано 7 февраля, 2012 · Жалоба Нет, если выдать BRAS адрес из клиентской сети, который не является для клиентов шлюзом. Тогда от клиента до БРАС Циска будет layer3, от БРАС к клиенту - layer2. Как в таком случае быть с клиентскими vlan-ами? IP адреса клиентам планируется выдавать динамически (за исключением тех кто захочет статику). На сколько я понимаю, чтобы циске была L3 на ней должен быть IP из клиентской сети, точнее по одному IP на vlan? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 7 февраля, 2012 · Жалоба Как в таком случае быть с клиентскими vlan-ами? IP адреса клиентам планируется выдавать динамически (за исключением тех кто захочет статику). На сколько я понимаю, чтобы циске была L3 на ней должен быть IP из клиентской сети, точнее по одному IP на vlan? Можно делать на Циске и БРАСах ip unnumbered - общий IP на все vlan'ы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дятел Опубликовано 7 февраля, 2012 · Жалоба Что-то я нафик запутался в ваших построениях ))) Мне казалось, что схема должна работать так: vlan-per-user, влан терминится на сапе через ip unnumbered от абоненту по влану приходит запрос по opt82, циска запрашивает у DHCP-сервера реквизиты и отдает их абоненту сетка, из которой абонент получает адрес - прибита на циску, ессно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 7 февраля, 2012 · Жалоба в таком случае циска6509 и будет Bras, в таком варианте (как Дятел расписал) все работает очень хорошо Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IVB Опубликовано 16 февраля, 2012 · Жалоба На самом деле все очень просто. 0. BRAS'ом является RB SE100. 1. часть трафика должна идти через BRAS и этим BRAS'ом шейпиться. 2. другая часть трафика (ее шейпить не нужно) должна идти мимо BRAS'а. Сейчас такая схема реализуется при помощи Dual-Access PPPoE: у клиентов есть "серые" IP в vlan'ах, которые терминируются на Циске, и локальный трафик между этими vlan'ами бегает через Циску. BRAS (через PPPoE) выдает клиентам реальные IP, с которыми они выходят в "мир". Хочется что-то аналогичное реализовать через IPoE. При этом очень хочется выдавать клиенту адрес /32 (чтобы не дробить блок реальных IP на мелкие подсетки, в котрых больше половины адресов будет "висеть в воздухе"). Но, если выдавать клиенту /32 через IPoE на BRAS'е (коим, напомню, является не Циска, а РедБэк) - соответственно, весь клиентский трафик пойдет через РедБэк - а этого очень не хочется, т.к. 3Гб в СЕ100 очень быстро исчерпаются... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
biox Опубликовано 16 февраля, 2012 · Жалоба У нас на L3 агрегации прописан default гейтвеем IP бордера что в итоге как раз и даёт желаемый эффект: весь локальный трафик форвардит агрегация, а весь не локальный выкидывается на бордер и он уже шейпит и доступ ограничивает. Так же в агрегацию приходят линки от пиринг парнёров и по BGP маршруты от них что опять же позволяет не нагружать пиринговым трафом бордер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
D^2 Опубликовано 16 февраля, 2012 · Жалоба Но, если выдавать клиенту /32 через IPoE на BRAS'е (коим, напомню, является не Циска, а РедБэк) - соответственно, весь клиентский трафик пойдет через РедБэк - а этого очень не хочется, т.к. 3Гб в СЕ100 очень быстро исчерпаются... если использовать L3 connected DHCP subscriber - локальный трафик замкнется на первом L3 устройстве, коим может как раз быть 6500 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
