6500/7600 egress policing
Hi! На 6500/sup720 часть трафика приходит через 10G-модуль, а часть через гигабитный. При прописывании egress policing на SVI, полисинг к этим частям трафика применяется независимо. Есть ли возможность ограничить суммарную полосу клиенту? Кто как решает эту проблему? Вот тут нагуглилось о том же, но без решения: http://puck.nether.net/pipermail/cisco-nsp/2008-March/thread.html#48364 -- Паша.
On Sun, Nov 30, 2008 at 02:42:54PM +0200, Pavel Gulchouck wrote: Собственно в cisco-nsp все честно расписано: - полисинг исхода исполняется на входящем/входящих EARL - состояния EARL'ов не синхронизируются Обходных путей несколько: - использовать в сторону клиента интерфейс реализующий полисинг на выхлопе. Соотвественно ES20 или же SIP+SPA - снести входящие аплинки на модули без DFC - вынести полисинг за пределы коробки - перестроить полисер из позы X в сторону клиента в позу не более чем Y с этого аплинка и не более чем Z c этого
На 6500/sup720 часть трафика приходит через 10G-модуль, а часть через гигабитный. При прописывании egress policing на SVI, полисинг к этим частям трафика применяется независимо.
Есть ли возможность ограничить суммарную полосу клиенту? Кто как решает эту проблему?
Вот тут нагуглилось о том же, но без решения: http://puck.nether.net/pipermail/cisco-nsp/2008-March/thread.html#48364
-- Паша.
-- ZA-RIPE||ZA1-UANIC
Добрый день! On Mon, Dec 01, 2008 at 03:13:26AM +0200, Andrey Zarechansky wrote:
Собственно в cisco-nsp все честно расписано:
- полисинг исхода исполняется на входящем/входящих EARL - состояния EARL'ов не синхронизируются
Эти особенности, собственно, вытекают из архитектуры нынешнего PFC3/DFC3 которая расчитана на навеску всех сервисов только на этапе ingress. По-другому это станет только в PFC4/EARL8 как обещают в 1HCY09. btw: расхваливаемый докой SCE чудненько сумеет зашейпить кого-угодно и на сколько угодно :)
Обходных путей несколько: - использовать в сторону клиента интерфейс реализующий полисинг на выхлопе. Соотвественно ES20 или же SIP+SPA - снести входящие аплинки на модули без DFC - вынести полисинг за пределы коробки - перестроить полисер из позы X в сторону клиента в позу не более чем Y с этого аплинка и не более чем Z c этого
На 6500/sup720 часть трафика приходит через 10G-модуль, а часть через гигабитный. При прописывании egress policing на SVI, полисинг к этим частям трафика применяется независимо.
Есть ли возможность ограничить суммарную полосу клиенту? Кто как решает эту проблему?
Вот тут нагуглилось о том же, но без решения: http://puck.nether.net/pipermail/cisco-nsp/2008-March/thread.html#48364
-- Dmitry Kiselev
Добрый день! On Mon, Dec 01, 2008 at 01:49:52PM +0200, Dmitry Kiselev wrote:
Собственно в cisco-nsp все честно расписано:
- полисинг исхода исполняется на входящем/входящих EARL - состояния EARL'ов не синхронизируются
Эти особенности, собственно, вытекают из архитектуры нынешнего PFC3/DFC3 которая расчитана на навеску всех сервисов только на этапе ingress. По-другому это станет только в PFC4/EARL8 как обещают в 1HCY09.
Очепяточка вышла, на год позже будет - 1HCY10 -- Dmitry Kiselev
On Mon, Dec 01, 2008 at 01:58:49PM +0200, Dmitry Kiselev wrote:
Эти особенности, собственно, вытекают из архитектуры нынешнего PFC3/DFC3 которая расчитана на навеску всех сервисов только на этапе ingress. По-другому это станет только в PFC4/EARL8 как обещают в 1HCY09.
Очепяточка вышла, на год позже будет - 1HCY10
Странно. У меня другая информация. Нам рассказывают, что активно будут развивать ASR9000, а EARL7.5 последний доступный для 7600/6500. -- ZA-RIPE||ZA1-UANIC
On Mon, Dec 01, 2008 at 03:25:52PM +0200, Andrey Zarechansky wrote:
On Mon, Dec 01, 2008 at 01:58:49PM +0200, Dmitry Kiselev wrote:
Эти особенности, собственно, вытекают из архитектуры нынешнего PFC3/DFC3 которая расчитана на навеску всех сервисов только на этапе ingress. По-другому это станет только в PFC4/EARL8 как обещают в 1HCY09.
Очепяточка вышла, на год позже будет - 1HCY10
Странно. У меня другая информация. Нам рассказывают, что активно будут развивать ASR9000, а EARL7.5 последний доступный для 7600/6500.
Похоже, у разных Business Units разные планы развития ;) Вот по этому документу: http://tinyurl.com/572mbc (рассчитанному именно на 6500 series) будет и EARL8 и EARL9...
Добрый день! On Mon, Dec 01, 2008 at 04:28:20PM +0300, Alexandre Snarskii wrote:
Эти особенности, собственно, вытекают из архитектуры нынешнего PFC3/DFC3 которая расчитана на навеску всех сервисов только на этапе ingress. По-другому это станет только в PFC4/EARL8 как обещают в 1HCY09.
Очепяточка вышла, на год позже будет - 1HCY10
Странно. У меня другая информация. Нам рассказывают, что активно будут развивать ASR9000, а EARL7.5 последний доступный для 7600/6500.
Это наверное что бы новую, более дорогую железку побыстрее продать ;)
Похоже, у разных Business Units разные планы развития ;)
Та не, для 7600 выход RSP-2T тоже есть в планах. Ориентировочно 2HCY10-1HCY11 Так что это наверняка просто маркетинг такой. В условиях кризиса :)
Вот по этому документу: http://tinyurl.com/572mbc (рассчитанному именно на 6500 series) будет и EARL8 и EARL9...
Да-да. Я удивляюсь почему на него Cisco Confidential не нацепили... -- Dmitry Kiselev
On Mon, Dec 01, 2008 at 04:28:20PM +0300, Alexandre Snarskii wrote:
Эти особенности, собственно, вытекают из архитектуры нынешнего PFC3/DFC3 которая расчитана на навеску всех сервисов только на этапе ingress. По-другому это станет только в PFC4/EARL8 как обещают в 1HCY09.
Очепяточка вышла, на год позже будет - 1HCY10
Странно. У меня другая информация. Нам рассказывают, что активно будут развивать ASR9000, а EARL7.5 последний доступный для 7600/6500.
Похоже, у разных Business Units разные планы развития ;)
Вот по этому документу: http://tinyurl.com/572mbc (рассчитанному именно на 6500 series) будет и EARL8 и EARL9...
Такие подозрения у меня тоже есть. К сожалению, местный офис больше ориентирован на SP. Правда, после просмотра документа, возник резонный вопрос: как быть с изначальной проблемой? Ведь никто не сказал, что полисеры разных EARL'ов будут сумироваться в будущих реализациях. Опять же, значимость данной функциональности для Campus Switching Systems Technology Group под сомненьем. Соотвественно вернулись к тому, что имеем: - менять производителя и наступать на другие грабли - менять схему предоставления услуги в ущерб стабильности и/или стоимости услуги P.S. Спасибо за ссылку. -- ZA-RIPE||ZA1-UANIC
On Mon, Dec 01, 2008 at 04:21:02PM +0200, Dmitry Kiselev wrote:
Эти особенности, собственно, вытекают из архитектуры нынешнего PFC3/DFC3 которая расчитана на навеску всех сервисов только на этапе ingress. По-другому это станет только в PFC4/EARL8 как обещают в 1HCY09.
Очепяточка вышла, на год позже будет - 1HCY10
Странно. У меня другая информация. Нам рассказывают, что активно будут развивать ASR9000, а EARL7.5 последний доступный для 7600/6500.
Это наверное что бы новую, более дорогую железку побыстрее продать ;)
А кто сомневается? ;-) Но с другой стороны, нам обещают набор книжек про реализацию в жизнь Science Fiction, когда сами доберутся до деталей.
Похоже, у разных Business Units разные планы развития ;)
Та не, для 7600 выход RSP-2T тоже есть в планах. Ориентировочно 2HCY10-1HCY11 Так что это наверняка просто маркетинг такой. В условиях кризиса :)
А это что за зверь?
Вот по этому документу: http://tinyurl.com/572mbc (рассчитанному именно на 6500 series) будет и EARL8 и EARL9...
Да-да. Я удивляюсь почему на него Cisco Confidential не нацепили...
Уcловия кризиса! -- ZA-RIPE||ZA1-UANIC
On Mon, Dec 01, 2008 at 11:59:47PM +0200, Andrey Zarechansky wrote:
Странно. У меня другая информация. Нам рассказывают, что активно будут развивать ASR9000, а EARL7.5 последний доступный для 7600/6500.
Похоже, у разных Business Units разные планы развития ;)
Вот по этому документу: http://tinyurl.com/572mbc (рассчитанному именно на 6500 series) будет и EARL8 и EARL9...
Такие подозрения у меня тоже есть. К сожалению, местный офис больше ориентирован на SP. Правда, после просмотра документа, возник резонный вопрос: как быть с изначальной проблемой? Ведь никто не сказал, что полисеры разных EARL'ов будут сумироваться в будущих реализациях. Опять же, значимость данной функциональности для Campus Switching Systems Technology Group под сомненьем. Соотвественно вернулись к тому, что имеем: - менять производителя и наступать на другие грабли
Не на другие, а, по крайней мере местами, на те же самые :) По крайней мере на M320 полисеры разных FPC тоже работают независимо... (На MX-series с DPCE-R проблем нет). PS: нам проще. От netflow мы уже давно отказались (все равно он даже на Cisco в non-sampled режимах на наших обьемах не работает), проблем с подготовленным персоналом нет (магистраль давно на juniper и только на juniper, кошки только в качестве свитчей), так что когда встает вопрос о установке на кошку DFC, SIP/SPA или ES-карт - c6500 меняется на MX :)
On Tue, Dec 02, 2008 at 06:59:24PM +0300, Alexandre Snarskii wrote:
On Mon, Dec 01, 2008 at 11:59:47PM +0200, Andrey Zarechansky wrote:
Странно. У меня другая информация. Нам рассказывают, что активно будут развивать ASR9000, а EARL7.5 последний доступный для 7600/6500.
Похоже, у разных Business Units разные планы развития ;)
Вот по этому документу: http://tinyurl.com/572mbc (рассчитанному именно на 6500 series) будет и EARL8 и EARL9...
Такие подозрения у меня тоже есть. К сожалению, местный офис больше ориентирован на SP. Правда, после просмотра документа, возник резонный вопрос: как быть с изначальной проблемой? Ведь никто не сказал, что полисеры разных EARL'ов будут сумироваться в будущих реализациях. Опять же, значимость данной функциональности для Campus Switching Systems Technology Group под сомненьем. Соотвественно вернулись к тому, что имеем: - менять производителя и наступать на другие грабли
Не на другие, а, по крайней мере местами, на те же самые :) По крайней мере на M320 полисеры разных FPC тоже работают независимо...
PS: тут я все-таки соврал. Похожая проблема на M320 наблюдалась в несколько более хитрой конфигурации - клиенты были подключены через aggregate ethernet (aka etherchannel), причем порты агрегата находились на разных FPC. В результате egress policer'ы "удваивались". После "сбора" агрегата на одной FPC проблема ушла...
participants (4)
-
Alexandre Snarskii -
Andrey Zarechansky -
Dmitry Kiselev -
Pavel Gulchouck