Перейти к содержимому
Калькуляторы

Frau

Активный участник
 Просмотреть профиль  Активность

  • Публикации

    105

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем Frau

  2. Опубликовано · Жалоба на ответ

    Да, мне б тоже. Особенно если есть для SP что-нить. Взамен могу прислать последнее руководство CCIE-RS =)

    у меня к сожалению по SP ничего нет, но есть контакт чела одного который материалы SP с доступом к сайту обновлений продает за 3 килорубля :) вчера по объявлению написал, могу поделится его почтой если нужно..

  3. Опубликовано · Жалоба на ответ

    Доброго времени суток,

    собственно сабж. Интересуют тексты written и labs для RS. Хотя бы сравнить нужные тексты были найдены или нет..

    пишите плз на почту fr221a[at]gmail.com ну или сюда

    заранее спасибо

  6. Опубликовано · Жалоба на ответ

    а можно пример пакетов которые вы ловите?

    Я могу предположить что это upnp multicast(ssdp), torrent,ipv6 multicast и прочая ботва генерируемая виндами и некоторыми приложениями. Она проявляется лавинно.

    в зависимости с тем что у вас на доступе можно это вырезать.

  7. Опубликовано · Жалоба на ответ

    ICMPv6 и DHCPv6 - от этих пакетов заполняются таблицы MAC адресов в коммутаторах доступа. Для DES 3028 - крайне актуально.
    для 3028 это актуально, да, но таким образом вы проблему не решите, надо уменьшать размеры броадкаст-доменов, а не фильтровать, даже если у вас и получится это сделать на 65-ом, то количество маков на 3028 не уменьшится

    У нас впринципе та же ситуация и теже коммутаторы доступа, на которых этот мусор не блокируется.

    Поэтому вам проще в таком случае 1 порт 65 - 1 вилан. особенно если на каждый порт приходится 100-500 маков..

  9. Опубликовано · Жалоба на ответ

    А тогда вопрос. Это что, можно настроить IPv6 сеть и спокойно гонять трафик ч-з 65 каталист?

    Если кто в курсе - просветите по вопросу, пожалуйста. Очень интересно.

    нет так не получится

    именно поэтому я и спрашиваю у автора зачем ему блокировать это на каталисте если трафик дальше него все равно не уйдет

     

  10. Опубликовано · Жалоба на ответ

    В ядре стоит 6506 (SUP720)

    Выяснилось, что от абонентов массово сыпется ICMPv6 и DHCPv6.

    Заблокировать это на доступе - не могу.

    Можно ли порезать это в ядре ?

    а смысл блокировать это на каталисте? оно же в пределах одного широковещательного домена. Надо именно на доступе.. И причем не конкретно эти протоколы, а левый мультикаст, на основании которого клиентские машины договариваются о настройках ipv6.

    Тоже интересуюсь этой темой, там еще такие вещи можно с виндами вытворять с клиентскими...

  11. Опубликовано · Жалоба на ответ

    Доброго времени суток всем,

    интересует вопрос про nat на 7604.

    Есть pat с таймаутами и ограничениями по количеству трансляций, но при любой "нестандартной" активности (DoS и т/д) роутеры укладываются. Трафика натится немного, суммарно может 500-600 мбит в пике. Карты WS-X6708-10GE, WS-X6748-GE-TX.

    Кто нибуть натит на 76-х? Как решаете проблемы? Есть ли какие нибуть карты для них с функционалом IDS?

     

    Заранее спасибо.

  12. Опубликовано · Жалоба на ответ

    Странно, у меня есть кольцо из цисок, в т.ч. и me3400 и там pim работает, нигде не отключал его. Как балансируется - не знаю, но работает :)
    ну кольцо это да) у меня получаецца треугольник))

    и возможно у вас pim не sm

    Какая разница кольцо или треугольник? :) Главное, что два пути есть. Использую pim-sm.

    А где вы прочитали про неработающую балансировку? Интересно было бы изучить этот вопрос.

    разница между кольцом и треугольником большая)) в кольце нет equal-path путей до соседнего узла

    статью которая первоночально попалась - найти не могу

    но вот в траблшутинге это обсуждается http://www.cisco.com/en/US/tech/tk828/tech...ml#whynoloadbal

  14. Опубликовано · Изменено пользователем Frau · Жалоба на ответ

    балансировка у вас на 7600 на основе src-dst IP ?

    Вы говорили в начале, что видели на гигабитном порту 7600, 250 пакетов в спане, т.е трафик разложился в одно плечо, по второму не тек, так ?

    Тогда на одном из 3400, который обсуждался, каким образом трафик пришел по двум путям ?

    имеется ввиду балансировка cef на основе BGP multipath, а не в порт-чэнелах

    у меня 2 equal-cost путей для передачи мультикаста на узел, оно начинает балансировать их и по bgp multipath и по etherchannel load-balancing, проблема именно в первом случае

     

    а про span даже хз, возможно он где-то раньше срабатывает, незнаю, у меня особо нет инфы по этому вопросу, могу только догадываться по общим схемам

  15. Опубликовано · Жалоба на ответ

    Странно, у меня есть кольцо из цисок, в т.ч. и me3400 и там pim работает, нигде не отключал его. Как балансируется - не знаю, но работает :)
    ну кольцо это да) у меня получаецца треугольник))

    и возможно у вас pim не sm

  16. Опубликовано · Жалоба на ответ

    Непосредственно на железе уже такое кто-нибудь проверял?

    использую балансировку src-dst-ip + dst-mac(ip)

    вы когда будете включать src-mac балансировку совместно с src-dst-ip, можете сталкнуться с эффектом поляризации в сети

    вы просто когда сделаете etherchannel не забудьте графики прикрутить, и тогда уже определитесь с балансировкой глядя на статистику

  17. Опубликовано · Изменено пользователем Frau · Жалоба на ответ

    Правильно ли я понимаю, что при указании load-balance src-mac на 3550, балансировка будет работать, как на 6509 при load-balance src-dst-ip ?
    правильно

    ..хотя не знаю так же ли как на 6509

    но там написано что для пары src-dst ip будет всегда выбираться один линк, если на 65 также, значит правильно

  18. Опубликовано · Жалоба на ответ

    Можете подробнее пояснить ?

    Чтоб в голове отложилось, а то незавершенным процесс остался )

    Да могу подробнее))

     

    У меня 7604 имеет equal-cost пути до узла (2 штуки), т/е она соединена с 2-умя 3400, и обе они маршрутизировали мультикаст.

    Я читала до этого что мультикаст в pim-sm не балансируется cef, "не балансируется" нужно было понимать как "балансируется, но не работает". Потому что rpf-check выбирает только 1 маршрут, и следовательно вторую ветку отсекает, поэтому получилось что до клиента приходила половина потока. Я отключила маршрутизацию на одной из 3400 и теперь все работает верно.

  20. Опубликовано · Жалоба на ответ

    Остался 3400.

    Вот здесь посмотрите, люди пишут, что можно глянуть дропы на 3400 - http://www.gossamer-threads.com/lists/cisco/nsp/80758

    Что значит не разгоняются интерфейсы, может проблема в малой выходной очереди, в ссылке тоже есть про это.

    Выложите конфиги 3400 по поводу коса.

    по ссылке там очереди output, я знаю как управлять output-очередями на 3400.

    конфиг у меня касаемо qos на 3400:

     service-policy input PL-TAC
service-policy output PL-OUT

policy-map PL-TAC
class class-default
  set cos cos

policy-map PL-OUT
class CM-7
    bandwidth 200000
    queue-limit 544
class CM-5
    bandwidth 600000
    queue-limit 544
class CM-0
    bandwidth 200000
    queue-limit 48

     

    2mschedrin Вы выложили как можно посмотреть дропы на output, а я говорила об input дропах

    Service-policy input: PL-TAC

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any 
    Set cos cos

     

    статистика по input-очередям тут впринципе не отображается

     

    Поток не поднимается выше 1600kbps, самое странное что если запрашивают несколько потоков, то суммарная скорость их также не превышает 1600 kbps

    Дело не в QoS, т/к если бы было в qos, то проблема бы не проявлялась при низкой нагрузке, получается где стоит rate-limit на 3400..

     

  21. Опубликовано · Жалоба на ответ

    ...

    Я не очень здорово знаю циску, можно ли в лан картах посмотреть счетчики на егресс по каждой очереди раздельно ?

    На ингресс точно нельзя.

     

    Какая у вас версия PFC (результирующая, наименьший деноминатор в понятии циски) и IOS ?

    Что значит принимающая сторона не успевает разгребать очередь ?

    (Какую коробку имеете в виду)

    Вы сказали, что делали спан на гигабитном порту 7600 и количество пакетов соответствовало норме

    т.е. подозреваете 3400 ?

    Может действительно сделать qos в траст на нем и настроить очереди.

    на егресс тоже нельзя смотреть счетчики по каждой очереди

     

    PFC operating mode : PFC3C

    Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVENTERPRISEK9-M), Version 12.2(33)SRD4, RELEASE SOFTWARE (fc2)

     

    в спане с гигабитного порта уходил поток соответствующий норме, но я видела схемку, и там после момента заворота в спан, впринципе есть еще места где может дропнуться поток

     

    Уже подозреваю 3400 то что она не может разгрести входящую очередь, т.к. вторая 76-я, которая тоже стоит на приеме, на ней потоки тоже соответствуют норме.

    На 3400 нельзя посмотреть статистику по очереди и дропам, у нее есть такой глюк - она ее не показывает. И к тому же, интерфейсы на 3400 1G не "разгоняются" до предела - полка 800 мбит/c.

    Получается в сторону 3400 у меня идет 1гбит/c, обратно 800 мбит/c, вот и думаю может у 3400 предел и она не разгребает уже пакеты?

     

    qos в trust на 10G порту я сделать не могу, т.к. это то место где я маркирую пакеты, раньше маркировать нельзя

    >>Попробуйте в policy-map на входе ставить DSCP а не precedence

    не помогает. Да и по докам поидее это одно и тоже

  22. Опубликовано · Жалоба на ответ

    так, я окончательно запуталась в qos'е ))

     

    должно наследоваться во внутренний dscp в этих случаях:

    1. когда пришло с dscp и порт в состоянии trust dscp

    2. когда пришло с tos и порт в trust ip-prec

    3. когда пришел заранее установленный cos в dot1q трафике, или, если cos не промаркирован, то выставляется дефолтное значение cos (как понимаю порт в trust cos)

    4. service-policy на порту

     

    у меня 4-й случай, порт в режиме untrust && service-policy на порту

    trust на порту дает 0 tos на выходе

    либо я не так мониторю, т/к в неинкапсулированный спан завернут транковый порт-чэнел, и я вижу dscp в мониторинге..

    с трастами я экспериментировала, все метки сбрасываются и на скорость мультикаст-потока это никак не отразилось

     

    уже не знаю, может принимающая сторона не успевает разгребать входящую очередь?

     

    с другой стороны есть картинка (в аттаче)

    по которой видно, что по первому же ответвлению выставится "внутренний CoS" в default port cos, в моем случае он нулевой и передасться с нулевым внутренним cos в switching engine

     

    как связать внутренние метки с "не внутренними"?

     

    post-69247-1274431440_thumb.png

  23. Опубликовано · Жалоба на ответ

    Ясно.

    Пока не понимаю, почему у вас не срабатывает дефолтная карта ipp-cos.

    Попробуйте зайти с другой стороны, поставьте set на egress порту.

    спасибо за советы, но походу у меня проблема аналогичная описанной в теме http://forum.nag.ru/forum/index.php?showtopic=55680

  24. Опубликовано · Жалоба на ответ

    Мне тут коллеги подсказывают, что set cos 7 для вашего случая не будет идиотизмом )

    т.е. это внутренний cos, он дойдет до гигабитного порта и правильно разложиться в 4-ю очередь.

     

    У вас ситуация просто не тривиальная, гигабитная карта не имеет режима для очередей dscp-mode.

    не срабатывает назначение политики

     

    set cos cannot be configured on input direction for this interface

    Configuration failed!

     

    политика вида

    service-policy input PLC-C

    Policy Map PLC

    Class CM7

    set cos 7

    Class CM0

    set cos 0

    Class class-default

    set cos 5

  25. Опубликовано · Жалоба на ответ

    Вы ставите преседенс в service-policy, а порт Gi3/24 у вас в mode-cos, поставьте cos.

    С номерами очередей ясно, цискины нюансы, все ок.

    а как я могу выставить cos если там routed-порт? Там нет тегов