[Cr_net]

в презентухе в проблемах написано неполная L2 прозрачность (cdp и lacp)

 

то есть схему 7600-sce-7600 c L3 портченнел (LACP) на 7600 нельзя поднять?

 

в доках как то невнятно написано про mgscp режим.

[b2ron]

видео есть выступления?

[cmhungry]

в презентухе в проблемах написано неполная L2 прозрачность (cdp и lacp)

 

то есть схему 7600-sce-7600 c L3 портченнел (LACP) на 7600 нельзя поднять?

 

в доках как то невнятно написано про mgscp режим.

Нельзя поднять портченнел через нее.

[D^2]

http://www.cisco.com/en/US/docs/cable/serv....html#wp1051270

это не поможет?

[Cr_net]

http://www.cisco.com/en/US/docs/cable/serv....html#wp1051270

это не поможет?

у этого есть существенное ограничение

 

LIC Bypass not supported - Translation is done in the transmission. Therefore, in LIC bypass, where there is no transmission, there is also no translation.

This means that in general, installations using the VLAN translation feature should rely on cutoff on failure and at upgrade (use redundant SCE platform).

[Stak]

емнип, remapping вполне можно делать и не на SСЕ, а на порту коммутатора к которому он подключен...

[snark]

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

после "бесплатно гигабит анлима на белой статике не дашь" Вы забыли дописать "и будешь доплачивать за пользование инетом" -) но, IMHO, и в этом случае они будут недовольны суммой доплаты ...

 

ув. господа, подскажите, пожалуйста, как можно более оптимально использовать железку в РРРоЕ/РРТР сетях? то что в кота можно залить подписчиков - это здорово, но это, IMHO, оптимальнее всего подходит при использовании IPoE, а вот как быть при РРРоЕ/РРТР где адреса, в большинстве случаев, выдаются динамикой? можно конечно расковырять биллинг и научить его заливать юзеров в кота, но может есть более изящные решения? если Вы подумали про интеграцию с ISG, то скажу сразу - увы и ах, этот вариант хоть и имеет место быть, но не про нас :( в конце концов, если это нереально и SCE с РРРоЕ/РРТР не подружить, меня вполне устроит ответ на вопрос - можно ли создать на SCE несколько профилей для различных типов трафика, например "голос", "http, почта, онлайн видео и т.п. критичные к "не грузится!" вещи", "р2р" и "все остальное" и приоритетами разрулить кому какой процент полосы можно занимать, дабы оптимальнее ее (полосу) утилизировать? проще говоря - не дать р2р забить весь канал и "зажимать" его когда есть более приоритетный трафик, а когда его нет - пусть уж берет свое, всеравно от него никуда не денешься

[zzeka]

ув. господа, подскажите, пожалуйста, как можно более оптимально использовать железку в РРРоЕ/РРТР сетях? то что в кота можно залить подписчиков - это здорово, но это, IMHO, оптимальнее всего подходит при использовании IPoE, а вот как быть при РРРоЕ/РРТР где адреса, в большинстве случаев, выдаются динамикой?

Она умеет accounting слушать и брать из него привязки адресов к подписчикам.

[snark]

можно с этого места поподробнее? или по своему опыту скажите или носом в доку ткните ;)

[jama]

в презентации красным выделено NetFlow v5

 

так SCE все-таки его умеет или приходится сливать RDR и анализировать его?

[photon]

можно ли создать на SCE несколько профилей для различных типов трафика, например "голос", "http, почта, онлайн видео и т.п. критичные к "не грузится!" вещи", "р2р" и "все остальное" и приоритетами разрулить кому какой процент полосы можно занимать, дабы оптимальнее ее (полосу) утилизировать? проще говоря - не дать р2р забить весь канал и "зажимать" его когда есть более приоритетный трафик, а когда его нет - пусть уж берет свое, всеравно от него никуда не денешься

Да, было бы интересно узнать, насколько введение таких профилей снизит производительность SCE.

[exeyp]

можно с этого места поподробнее? или по своему опыту скажите или носом в доку ткните ;)

Есть встроенный инструмент в Subscriber Manager - Radius Listener LEG

[exeyp]

в презентации красным выделено NetFlow v5

 

так SCE все-таки его умеет или приходится сливать RDR и анализировать его?

Про поддержку NetFlow v5 ни в каких презентациях не видел..Но вот в доке:

 

Cisco Service Control is able to deliver gathered reporting data to an external application for collecting, aggregation, storage and processing over two protocols:

•RDRv1: the Service Control proprietary export protocol

•NetFlow V9: an industry standard export protocol

---------------

These two protocols can be used simultaneously in the same deployment. However, any specific destination (external collector) to which data is sent can be configured with only one protocol.

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

[KoloBok]

ув. господа, подскажите, пожалуйста, как можно более оптимально использовать железку в РРРоЕ/РРТР сетях? то что в кота можно залить подписчиков - это здорово, но это, IMHO, оптимальнее всего подходит при использовании IPoE, а вот как быть при РРРоЕ/РРТР где адреса, в большинстве случаев, выдаются динамикой? можно конечно расковырять биллинг и научить его заливать юзеров в кота, но может есть более изящные решения? если Вы подумали про интеграцию с ISG, то скажу сразу - увы и ах, этот вариант хоть и имеет место быть, но не про нас :( в конце концов, если это нереально и SCE с РРРоЕ/РРТР не подружить, меня вполне устроит ответ на вопрос - можно ли создать на SCE несколько профилей для различных типов трафика, например "голос", "http, почта, онлайн видео и т.п. критичные к "не грузится!" вещи", "р2р" и "все остальное" и приоритетами разрулить кому какой процент полосы можно занимать, дабы оптимальнее ее (полосу) утилизировать? проще говоря - не дать р2р забить весь канал и "зажимать" его когда есть более приоритетный трафик, а когда его нет - пусть уж берет свое, всеравно от него никуда не денешься

Я планирую так сделать. Предполагаю есть два варианта:

1. Сделать несколько пулов по тарифам (ну или классам) и на SCE для этих пулов сделать соответствующие политики.

2. После авторизации для каждого IP назначать на SCE свою политику.

 

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

[cmhungry]

в презентации красным выделено NetFlow v5

 

так SCE все-таки его умеет или приходится сливать RDR и анализировать его?

Про поддержку NetFlow v5 ни в каких презентациях не видел..Но вот в доке:

 

Cisco Service Control is able to deliver gathered reporting data to an external application for collecting, aggregation, storage and processing over two protocols:

•RDRv1: the Service Control proprietary export protocol

•NetFlow V9: an industry standard export protocol

---------------

These two protocols can be used simultaneously in the same deployment. However, any specific destination (external collector) to which data is sent can be configured with only one protocol.

RDRv1 конвертируется в Netflow5 у нас

[rus-p]

в презентухе в проблемах написано неполная L2 прозрачность (cdp и lacp)

 

то есть схему 7600-sce-7600 c L3 портченнел (LACP) на 7600 нельзя поднять?

 

в доках как то невнятно написано про mgscp режим.

Нельзя поднять портченнел через нее.

Вы какую sce обсуждаете ?

На 8000 lacp пакетики бегают прозрачно, etherchannel работает.

Софт последний 3.6.0

Две SCM-E запрягались одновременно для формирования 2*10GE транка.

Изменено 12 мая, 2010 пользователем rus-p

[exeyp]

RDRv1 конвертируется в Netflow5 у нас

А какой коллектор используйте для приема и конвертации RDR?

Просто сейчас возникла ситуация, что необходимо принять определенный тип RDR и выдернуть из него определенные поля.

Изменено 13 мая, 2010 пользователем exeyp

[shicoy]

в презентухе в проблемах написано неполная L2 прозрачность (cdp и lacp)

 

то есть схему 7600-sce-7600 c L3 портченнел (LACP) на 7600 нельзя поднять?

 

в доках как то невнятно написано про mgscp режим.

Нельзя поднять портченнел через нее.

Вы какую sce обсуждаете ?

На 8000 lacp пакетики бегают прозрачно, etherchannel работает.

Софт последний 3.6.0

Две SCM-E запрягались одновременно для формирования 2*10GE транка.

потестил на SCE2020, не захотел portchannel работать :( софт 3.6.5

[anix]

в презентухе в проблемах написано неполная L2 прозрачность (cdp и lacp)

 

то есть схему 7600-sce-7600 c L3 портченнел (LACP) на 7600 нельзя поднять?

 

в доках как то невнятно написано про mgscp режим.

Нельзя поднять портченнел через нее.

Вы какую sce обсуждаете ?

На 8000 lacp пакетики бегают прозрачно, etherchannel работает.

Софт последний 3.6.0

Две SCM-E запрягались одновременно для формирования 2*10GE транка.

потестил на SCE2020, не захотел portchannel работать :( софт 3.6.5

Работает, как раз на SCE2020 проверено, на железках настраивается обычный etherchannel, а на SCE главное активировать порты, чтобы линки поднялись :)

[Vadic]

Тоже думал, что не будет работать. Настроил port-channel и работает отлично.

[shicoy]

Стоп, мы говорим об LACP (IEEE P802.3ad) или Static Trunk

У меня LACP не захотел работать.

Изменено 28 апреля, 2011 пользователем shicoy

[Vadic]

А может тогда просто покажите настройки port-channel с привязанными интерфейсами к ним на обоих 7600?

[darkagent]

port-channel между цисками на lacp ?! месье знает толк в изращениях.

Почему не pagp (channel-group ? mode desirable)?

[smile_2008]

а вот если у меня есть dlink3612 и sce2020 , и со стороны инета и юзеров по 2 гбит\сек... в sce 2 порта на вход и два на выход... что настраивать на dgs3612? LACP? sce2020 MM - это мультимод тип порта, я так понял)?

[vurd]

Я бы конечно начал с выбрасывания 3612, но в принципе, вы правильно говорите, нужно настраивать (3612-LACP->SCE->LACP-Uplink). Оно нормально работает с агрегированными портами.

MM - multimode. Вам нужны модули соответсветсвующие с обратной стороны, на 3612 это будет какой-то двуглазый LC SFP.