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

exeyp

Пользователи
  • Публикации

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

  • Посещение

1 подписчик

О exeyp

  • Звание
    Абитуриент
    Абитуриент

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Пол
    Array
  1. Можно, но не все: Зеркалится только классифицированный тафик, поэтому не будут зеркалится первые пакеты UDP и TCP handshake. Привязываем нужный тип трафика через SCA-BB rule к VAS server group. (mirror trafic to server group). далее вся остальная настройка проводится через CLI на SCE. Причем входящий из инета трафик будет зеркалится в subscriber port, а исходящий от абонентов в network port. Трафик метится нужным VLAN ID. Грузит эта штука SCE не хило - тестировал загрузка CPU's возросла приблизительно на 30%.
  2. Посмотри в конфиге SM секцию [sM-LEG Failure Handling] # The following parameter defines the behavior of the SM in case of LEG-SM connection failure. # This parameter is relevant only for cases SM and LEG are running on different machines. # Note that this parameter defines a behavior that is similar for ALL connected LEGs. # If the parameter is set to true then in case of LEG-SM connection failure that is not # recovered within the defined timeout, the mappings of all subscribers in the domains # defined in the 'LEG-Domains Association' section for the LEG that was disconnected, # will be removed # # IMPORTANT: LEG Domains must be defined in the following section in case this parameter is set to 'true' # # Optional values: [true/false]. Default: false. clear_all_mappings=false
  3. Я бы рад добить snmp... только спустя несколько дней, на железке через которую проходит больше гигабита траффика, и которую я пару раз ребутил, snmp показывает все те же волшебные цифры: # snmpget -v 2c -c *** sce2 .1.3.6.1.4.1.5655.4.2.2.1.1.2.1.1.3 SNMPv2-SMI::enterprises.5655.4.2.2.1.1.2.1.1.3 = Counter32: 62041114 которые совсем не хотят инкрементироваться! Попробуйте через CLI на LineCard сказать no accelerate-packet-drops и потом проверьте цифры. Хотя сейчас проверил, никак не влияет на этот counter. P/S. У нас значения по SNMP отдает и они изменяются.
  4. Судя по опыту использования SCE2020/SCE8000, версии SCOS у которой стоит на конце ноль (3.5.0, 3.6.0, и т.д.) крайне не стабильны и в них, как правило, добавляется новый функционал. Через короткий промежуток времени выходят обновления, латающие дыры. Попробуйте установить версию 3.7.5 или 3.7.2.
  5. Это нормальное поведение. Как только будут приходить RDR, обрывы соединения прекратятся. Была такая проблема, приложению SCA-BB "не нравится" записи о версии в конфигурационном файле. Решил правкой версии в текстовом редакторе xml (pqb) файла.
  6. Была похожая проблема на SCE8000, но мы используем Subscriber Manager. При синхронизации абонентов на SM "вылазили" ошибки: <...> "18-Oct 2011", "14:09:09.203 IRKST","[mcn.SM[async-dispatcher]]",INFO,"com.pcube.logger.userlog.UserLog","SM: 176905 - operation failure (IP resource shortage) on SCE8000 (domain: subscribers)." <...> Переписывались с cisco TAC по этому вопросу - ничего внятного от них не услышали. Помогла перезагрузка SCE. На момент проблемы версия софта была: SCE8000 Version 3.6.5 Build 489, SM Version: 3.6.5 Build 300.
  7. Попробуйте обновить время в java-машине на CM Timezone Updater Tool.
  8. Ни разу такие логи не вылазили. Но судя по логам можно предположить, что сыпется много пакетов на MGMT интерфейс SCE (досят?) с IP адреса 534559cc (83.69.89.204) и SCE , чтобы не забивать CPU их ограничивает.
  9. По сути да. Я даже как-то разархивировал и правил в нем поля, а потом загружал на SCE.
  10. Для заливки конфига(PQB) требуется время, и чем конфиг больше, тем больше времени надо. Во время применения конфига трафик абонентов перестает классифицироваться и ограничиваться. Таким образом сразу после применения получаем "горку" в виде OTHER TCP/UDP.
  11. Чтобы не создовать новую тему, напишу здесь. Друзья, прошу помощи в реализации политик управления абонентами при помощи SCE Quota Manager. Нужен совет тех кто пробовал использовать QM в конфигурации с пенальти профилями (базовый профиль и несколько пенальти профилей). Если есть такие, то прошу откликнуться и я опишу проблему.
  12. У нас на SCE SCOS 3.7.2, а Collection Manager стоит Version 3.6.5 Build 301. Никаких проблем не возникает. Обновлять CM до версии 3.7.X смысла не увидел.
  13. Адаптер не может вставить данные из RDR в таблицу. Чтобы дальше не углубляться в диагностику/отладку, можно попробовать пересоздать таблицу RPT_LUR.
  14. Проверь, что все RDR отправляются (не происходит дропов на SCE): SCE#>sh RDR-formatter | inc RDR RDR: queued: 0 ,sent:1043750184, thrown: 0, format-mismatch: 0 Далее проверь, чтобы RDR-tag ,был замаплен корректно (к нужной категории): SCE#>sh RDR-formatter rdr-mapping 0xf0f0f005 Mapping for tag 0xf0f0f005 is: 1 Чтобы увидеть, что нужные RDR "улетают" с SCE замапь их другой категориии (по-умолчанию категориия = 1) и настрой отправку только этой категории на CM. На CM можешь посмотреть tcpdamp'ом. Посмотри логи на CM. Попробуй пересоздать таблицу (дропни таблицу и перезапусти CM). Проверь чтобы была пуста вот эта директория на CM: ~cm/adapters/JDBCAdapter/ Проверь настройки в файле ~cm/config/queue.conf