Davion

Активный участник
  • Публикаций

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

  • Посещение

1 Подписчик

Информация о Davion

  • Звание
    Аспирант
  • День рождения

Контакты

  • ICQ
    0

Информация

  • Пол
    Не определился

Посетители профиля

2 591 просмотр профиля
  1. Коллеги! Подскажите на Extreme есть аналог user-defined ACL (http://www.dlink.ru/ru/faq/62/954.html), в доке найти не могу...
  2. Конфигурацию NAT покажите пожалуйста.
  3. Я мучался с этим sandbox, даже писал в рассылку... Попробуйте это решение: https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP Сейчас тестирую роутер на DPDK, по результатам автор напишет статью)
  4. Ну в принципе ничего страшного, просто маршруты массово на карту добавляются, из-за того что происходит медленно система об этом рапортует Спасибо, примерно такое объяснение и нашел на форумах джунипера)
  5. Коллеги подскажите пожалуйста в логи при поднятие bgp сессий вываливаются Jul 19 02:06:04 mx480 /kernel: rt_pfe_veto: Possible slowest client is sampled. States processed - 493811958. States to be processed - 84942 Jul 19 02:06:04 mx480 rpd[1786]: RPD_KRT_Q_RETRIES: Route Update: No buffer space available Jul 19 02:06:04 mx480 rpd[1786]: bgp_listen_accept: Connection attempt from unconfigured neighbor: xxxxx::1+54456 Jul 19 02:06:04 mx480 rpd[1786]: bgp_listen_accept:4587: NOTIFICATION sent to xxxx::1+54456 (proto): code 6 (Cease) subcode 5 (Connection Rejected), Reason: Connection attempt from unconfigured neighbor: xxxx::1+54456 Jul 19 02:06:23 mx480 /kernel: rt_pfe_veto: Too many delayed route/nexthop unrefs. Op 2 err 55, rtsm_id 5:-1, msg type 2 Jul 19 02:06:23 mx480 /kernel: rt_pfe_veto: Memory usage of M_RTNEXTHOP type = (0) Max size possible for M_RTNEXTHOP type = (8307957760) Current delayed unref = (40000) Max delayed unref on this platform = (40000) curproc = rpd Jul 19 02:06:23 mx480 /kernel: rt_pfe_veto: Possible slowest client is xdpc2. States processed - 494101874. States to be processed - 60819 Jul 19 02:06:23 mx480 /kernel: rt_pfe_veto: Possible second slowest client is xdpc0. States processed - 494101875. States to be processed - 60818 Jul 19 02:06:27 mx480 /kernel: rt_pfe_veto: Too many delayed route/nexthop unrefs. Op 2 err 55, rtsm_id 5:-1, msg type 2 Jul 19 02:06:27 mx480 /kernel: rt_pfe_veto: Memory usage of M_RTNEXTHOP type = (0) Max size possible for M_RTNEXTHOP type = (8307957760) Current delayed unref = (40000) Max delayed unref on this platform = (40000) curproc = rpd Jul 19 02:06:27 mx480 /kernel: rt_pfe_veto: Possible slowest client is xdpc1. States processed - 494227376. States to be processed - 85 Jul 19 02:06:27 mx480 /kernel: rt_pfe_veto: Possible second slowest client is xdpc2. States processed - 494227376. States to be processed - 85 Jul 19 02:06:32 mx480 /kernel: rt_pfe_veto: Too many delayed route/nexthop unrefs. Op 2 err 55, rtsm_id 5:-1, msg type 2 Jul 19 02:06:32 mx480 /kernel: rt_pfe_veto: Memory usage of M_RTNEXTHOP type = (0) Max size possible for M_RTNEXTHOP type = (8307957760) Current delayed unref = (40000) Max delayed unref on this platform = (40000) curproc = rpd Jul 19 02:06:32 mx480 /kernel: rt_pfe_veto: Possible slowest client is sampled. States processed - 494308069. States to be processed - 700 Jul 19 02:06:37 mx480 /kernel: rt_pfe_veto: Too many delayed route/nexthop unrefs. Op 2 err 55, rtsm_id 5:-1, msg type 2 Jul 19 02:06:37 mx480 /kernel: rt_pfe_veto: Memory usage of M_RTNEXTHOP type = (0) Max size possible for M_RTNEXTHOP type = (8307957760) Current delayed unref = (40000) Max delayed unref on this platform = (40000) curproc = rpd Model: mx480 Junos: 13.3R9.13
  6. Где вы там поддержку DPDK увидели? Suricata работает хорошо но не умеет заглушку слать... Есть соответствующие патчи. Можно ссылку на DPDK патч и заглушку? AF_PACKET и RST работает отлично
  7. Где вы там поддержку DPDK увидели? Suricata работает хорошо но не умеет заглушку слать...
  8. Тоже интересует сколько реальный выхлоп от общей полосы.
  9. не утрируйте. Пишете заявление, скан на почту, сутки и работайте без фильтрации "Прошу не осуществлять фильтрацию трафика, производимую во исполнение требований, установленных статьями 15.1-15.4 Федерального закона от 27.07.2006 N 149-ФЗ `Об информации, информационных технологиях и о защите информации` на канале, предоставляемом по Договору о присоединении N___ от `___` __________ 20__г. в виду самостоятельного исполнения требований законодательства ООО `___________________` на своей сети связи. " Ну учитывая что на офф. письмо вообще не отвечают... Информация от коллег по цеху, кому ответили...
  10. Трэш... Чтобы отключить их блокировку, необходимо внести изменения в договор... А это ещё та эпопея. Увел трафик на другие аплинки.
  11. Да это-то понятно. Просто клиенту фиг объяснишь, почему вчера работало, а сегодня - "не шмагла я". Мы вот тут с размахну на днях на аналогичные грабли наступили, но там оно хоть оттрассировалось на уровне IPCP. (Не в пятницу помянутый Upvel) И железки были новые - легко решается возвратом продавцу с матерным приветствием. IPCP?
  12. Проблема, на единичных D-link видимр с определенной версией прошивки
  13. нет с теста сняли вернули
  14. Коллеги подскажите начали небольшое раследование... Связанное с потерями и ретрансмишенами Проводили следующий тест, если на субскрайбере есть QoS то присутствуют потери. Если QoS снимаем с субскрайбера то все нормально. Как выяснили.. Iperf3 + подавали udp поток с тв каналом(битрейт 3 мбит) и принимали рассыпушки. Тип подключения PPPoE на BRAS от 3000-4000 клиентов. Есть подозрения что уперлись в апаратнные ограничения p.s. netflow нет
  15. Гуру suricat, а выдергивать и логировать как то данные из трафика можно? из документации понятно что логировать можно только http и dns