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

alexdirty

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

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

  • Посещение

Все публикации пользователя alexdirty


  1. Возможно это даёт отсрочку 60 дней на реализацию, после первого получения перечня. Постановление Правительства РФ от 29 декабря 2021 г. № 2531 “Об утверждении Правил ведения перечня отечественных социально значимых информационных ресурсов” - Федеральная служба по надзору в сфере связи, информационных технологий и массовых коммуникаций не позднее 7-го календарного дня со дня утверждения или актуализации перечня направляет его посредством информационной системы взаимодействия операторам связи, указанным в пункте 53 статьи 46 Федерального закона "О связи", для осуществления технических настроек, необходимых ввиду актуализации перечня, в течение 60 календарных дней со дня получения перечня.
  2. У меня по 221 приказу в ЛК единого портала пользователей ЦМУ ССОП вдруг пропала информация по ранее загруженным файлам. А так же, похоже, что появилась возможность передать информацию путём заполнения WEB форм.
  3. Да, спасибо. И правда. Сразу не проверил. 2020-10-17 11:00:14,705 New Item, IP, Domain, URL id: 2293300. 2020-10-22 16:57:22,954 Full delete Item, IP, Domain, URL id: 2293300. А пропуск зафиксирован 22.10.2020 в 23:38:29. Весело.
  4. А ни у кого нет пропусков от 22.10.2020 по https урлам смотретьвидео.рф ? Какие то непонятки. В реестре нет (который я получаю), в отчётах от ревизора есть.
  5. Интересно, а как понимать поле "Обяз" с пустым значением, т.е. не "0..." и не "1" ?
  6. Вопросы из опыта эксплуатации 1004 (не знаю на сколько сильно отличается от 1006): 1. В одно и тоже время, это в ЧНН? 2. Общий rate на вход и выход перед "падением" и после "восстановления" насколько отличается? 3. Нет ли ошибок/дропов на интерфейсах ASR и на железе до/после? 4. Жалобы от клиентов какого рода? 5. Начните "рисовать" график утилизации QFP. У меня на 1004 в CLI доступен по show platform hardware qfp active datapath utilization qfp 0 а по SNMP iso.3.6.1.4.1.9.9.715.1.1.6.1.14.9027.1 на одной и iso.3.6.1.4.1.9.9.715.1.1.6.1.14.9037.1 на другой. 6. Соответственно и графики трафика, cpu, количества трансляций в эти моменты может что-то подскажут.
  7. Да, верно, QFP. Кстати, как то раз после очередного Clear, QFP снова упал, и причём снова после того как clear был сделан для второго серого IP, а с первым всё было ОК. На Cisco Bug`e позже увидел несколько багов, которые описывают crash после Clear трансляций. Один из них https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvn49911, т.е. временное решение это не делать show ip nat tra в течении первых 20 секунд после clear... Весело.
  8. У меня это не SIP так чудит. У меня это GRE так чудит. Проверил, произвёл попытку поднять GRE туннель, освободил серый IP (т.е. на сером IP нет никакого хоста), и вот уже как месяц эта трансляция активна.   По таймауту трансляции сбрасываются, все, кроме проблемных с сессией GRE.
  9. Подскажите, как с аналогичной проблемой боритесь? Трансляции могут и больше недели висеть для протоколов отличных от icmp/tcp/udp (со стороны клиента и сервера активности никакой нет по этому соединению (это GRE)): --- *.*.*.* *.*.*.* --- --- create: 04/13/20 02:26:03, use: 04/21/20 09:44:10, timeout: 00:01:59 Map-Id(In): 1 Appl type: none Mac-Address: 0000.0000.0000 Input-IDB: Port-channel3.22 entry-id: 0x0, use_count:159 Более того, трансляция создаётся по любому порту при получении любого пакета из WAN. Таким образом nonpat трансляция никогда не освободится и исчерпание пула не за горами.
  10. Обновился на asr1000rp2-adventerprisek9.03.16.07b.S.155-3.S7b-ext.bin 1. ip nat translation max-entries all-host - заработал 2. crash с падением Etherchannel после clear трансляций - остался По второму пункту дополню: Clear трансляций на конкретном Inside не работает если в этот момент у клиента ходит трафик. Shutdown`ишь порт клиенту, что бы трафика не было, и тогда Clear работает. Clear трансляций на конкретном Inside c указанием протокола и портов - работает. После Clear трансляций у двух абонентов, как раз и произошёл снова crash с падением Etherchannel, через 7 минут линки поднялись. Sep 13 12:47:40: %CPPHA-3-FAULT: F0: cpp_ha: CPP:0.0 desc:DPE4_CPE_CPE_DPE_INT_SET_0_LEAF_INT_INT_S4_WPT_ERROR det:DRVR(interrupt) class:OTHER sev:FATAL id:1602 cppstate:RUNNING res:UNKNOWN flags:0x7 cdmflags:0x0 Sep 13 12:47:40: %CPPOSLIB-3-ERROR_NOTIFY: F0: cpp_ha: cpp_ha encountered an error -Traceback= 1#a987b1e8e3da18d823a6a09623b64c75 errmsg:7F3D12288000+121D cpp_common_os:7F3D15D98000+DA3C cpp_common_os:7F3D15D98000+1B5AE cpp_drv_cmn:7F3D155C3000+285B7 :400000+244A9 :400000+23F6C :400000+23993 :400000+1374D :400000+1272C cpp_common_os:7F3D15D98000+11C20 cpp_common_os:7F3D15D98000+12306 evlib:7F3D11202000+B937 evlib:7F3D11202000+E200 cpp_common_os:7F3D15D98000+13E42 :400000+DA85 c:7F3D09A74000+1E514 :4000 Sep 13 12:47:40: %CPPHA-3-FAULTCRASH: F0: cpp_ha: CPP 0.0 unresolved fault detected, initiating crash dump. Sep 13 12:47:40: %CPPHA-3-FAULTCRASH: F0: cpp_ha: CPP 0.0 unresolved fault detected, initiating crash dump. Sep 13 12:47:40: %CPPHA-3-FAULT: F0: cpp_ha: CPP:0.0 desc:INFP_INF_SWASSIST_LEAF_INT_INT_EVENT0 det:DRVR(interrupt) class:OTHER sev:FATAL id:2121 cppstate:RUNNING res:UNKNOWN flags:0x7 cdmflags:0x8 Sep 13 12:47:40: %CPPHA-3-FAULTCRASH: F0: cpp_ha: CPP 0.0 unresolved fault detected, initiating crash dump. Sep 13 12:47:40: %CPPHA-3-FAULTCRASH: F0: cpp_ha: CPP 0.0 unresolved fault detected, initiating crash dump. Sep 13 12:47:40: %CPPDRV-6-INTR: F0: cpp_driver-0: CPP10(0) Interrupt : Last 16 Interrupts Since Boot Sep 13 12:47:40: %CPPDRV-6-INTR: F0: cpp_driver-0: CPP10(0) Interrupt : 19-Sep-13 12:47:40.093120 UTC+0300:DPE4_CPE_CPE_DPE_INT_SET_0_LEAF_INT_INT_S4_WPT_ERROR Sep 13 12:47:40: %CPPDRV-6-INTR: F0: cpp_driver-0: CPP10(0) Interrupt : 19-Sep-13 12:47:40.093120 UTC+0300:INFP_INF_SWASSIST_LEAF_INT_INT_EVENT0 Sep 13 12:47:40: %CPPDRV-3-LOCKDOWN: F0: cpp_cp: QFP0.0 CPP Driver LOCKDOWN encountered due to previous fatal error (HW: QFP interrupt). Sep 13 12:47:40: %IOSXE_OIR-6-OFFLINECARD: Card (fp) offline in slot F0 Sep 13 12:47:40: %CPPOSLIB-3-ERROR_NOTIFY: F0: cpp_cp: cpp_cp encountered an error -Traceback= 1#3379fd703db39406a2190384a97f7318 errmsg:7FF0960E8000+121D cpp_common_os:7FF09956F000+DA3C cpp_common_os:7FF09956F000+1B5AE cpp_nat_svr_lib:7FF0A2DC3000+2E86D cpp_nat_svr_lib:7FF0A2DC3000+1C770 cpp_nat_svr_lib:7FF0A2DC3000+1CAFE cpp_nat_svr_smc_lib:7FF0A306A000+1B61 cpp_common_os:7FF09956F000+11C20 cpp_common_os:7FF09956F000+12306 evlib:7FF0982E1000+B937 evlib:7FF0982E1000+E200 cpp_common_os:7FF09956F000+13 Sep 13 12:47:41: %CPPDRV-3-LOCKDOWN: F0: fman_fp_image: QFP0.0 CPP Driver LOCKDOWN encountered due to previous fatal error (HW: QFP interrupt). Sep 13 12:47:47: %HSRP-5-STATECHANGE: Port-channel2.23 Grp 1 state Standby -> Active Sep 13 12:48:13: %CPPCDM-3-ERROR_NOTIFY: F0: cpp_cdm: QFP 0 thread 9 encountered an error -Traceback= 1#6df0c3e14153553c3f59b148c44ae86f 8035F39B 80347CB4 8035F3BC 8033B2B0 8033B35C 8033B4A6 8043B8B1 8043CBF2 Sep 13 12:48:13: %IOSXE-3-PLATFORM: F0: cpp_cdm: CPP crashed, core file /tmp/corelink/ASR1004-NEW_ESP_0_cpp-mcplo-ucode_091319124813.core.gz Sep 13 12:48:51: TenGigabitEthernet1/2/0 taken out of port-channel1 Sep 13 12:48:52: TenGigabitEthernet1/1/0 taken out of port-channel2 Sep 13 12:48:55: %EC-5-MINLINKS_NOTMET: Port-channel Port-channel2 is down bundled ports (0) doesn't meet min-links Sep 13 12:48:55: TenGigabitEthernet1/3/0 taken out of port-channel2 Sep 13 12:48:55: %EC-5-MINLINKS_NOTMET: Port-channel Port-channel1 is down bundled ports (0) doesn't meet min-links Sep 13 12:48:55: TenGigabitEthernet1/0/0 taken out of port-channel1 Sep 13 12:48:57: %LINK-3-UPDOWN: Interface Port-channel2, changed state to down Sep 13 12:48:57: %HSRP-5-STATECHANGE: Port-channel2.23 Grp 1 state Active -> Init Sep 13 12:48:57: %LINK-3-UPDOWN: Interface Port-channel1, changed state to down Sep 13 12:48:57: %HSRP-5-STATECHANGE: Port-channel1.22 Grp 1 state Active -> Init Sep 13 12:48:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel2, changed state to down Sep 13 12:48:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to down Sep 13 12:49:38: %CPPHA-3-FAULT: F0: cpp_ha: CPP:0.0 desc:CPP Client process failed: FMAN-FP det:HA class:CLIENT_SW sev:FATAL id:1 cppstate:RUNNING res:UNKNOWN flags:0x0 cdmflags:0x0 Sep 13 12:49:38: %CPPOSLIB-3-ERROR_NOTIFY: F0: cpp_ha: cpp_ha encountered an error -Traceback= 1#a987b1e8e3da18d823a6a09623b64c75 errmsg:7F3D12288000+121D cpp_common_os:7F3D15D98000+DA3C cpp_common_os:7F3D15D98000+1B5AE cpp_drv_cmn:7F3D155C3000+285B7 :400000+24438 :400000+23C1A :400000+14617 :400000+C0DE :400000+129AD :400000+F9E6 :400000+13B62 cpp_common_os:7F3D15D98000+1257F evlib:7F3D11202000+B937 evlib:7F3D11202000+E200 cpp_common_os:7F3D15D98000+13E42 :400000+DA85 c:7F3D09A74000+1E514 :400000+83E9 Sep 13 12:49:38: %PMAN-3-PROCHOLDDOWN: F0: pman.sh: The process fman_fp_image has been helddown (rc 134) Sep 13 12:49:38: %PMAN-0-PROCFAILCRIT: F0: pvp.sh: A critical process fman_fp_image has failed (rc 134) Sep 13 12:53:38: %IOSXE_OIR-6-ONLINECARD: Card (fp) online in slot F0 Sep 13 12:53:56: TenGigabitEthernet1/1/0 added as member-1 to port-channel2 Sep 13 12:53:57: TenGigabitEthernet1/2/0 added as member-1 to port-channel1 Sep 13 12:53:58: TenGigabitEthernet1/0/0 added as member-2 to port-channel1 Sep 13 12:53:58: %LINK-3-UPDOWN: Interface Port-channel2, changed state to up Sep 13 12:53:59: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up Sep 13 12:53:59: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel2, changed state to up Sep 13 12:54:00: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to up Sep 13 12:54:05: TenGigabitEthernet1/3/0 added as member-2 to port-channel2 Sep 13 12:54:21: %HSRP-5-STATECHANGE: Port-channel2.23 Grp 1 state Standby -> Active Sep 13 12:54:22: %HSRP-5-STATECHANGE: Port-channel1.22 Grp 1 state Standby -> Active Sep 13 12:54:27: %HSRP-5-STATECHANGE: Port-channel2.23 Grp 1 state Active -> Speak Sep 13 12:54:37: %HSRP-5-STATECHANGE: Port-channel2.23 Grp 1 state Speak -> Standby А теперь собственно, сама причина, зачем сбрасывал трансляции. sh ip nat statistics Total active translations: 365689 (0 static, 365689 dynamic; 365372 extended) .... [Id: 1] access-list NAT-USERS pool Pool-1 refcount 194255 pool Pool-1: id 1, netmask 255.255.255.0 start *.*.*.* end *.*.*.* type generic, total addresses 256, allocated 256 (100%), misses 10 [Id: 2] access-list NAT-USERS2 pool Pool-2 refcount 171434 pool Pool-2: id 2, netmask 255.255.255.0 start *.*.*.* end *.*.*.* type generic, total addresses 256, allocated 169 (66%), misses 0 ..... Из-за того что один из pool адресов на 100% был утилизирован из-за трансляций 1-to-1 по протоколам отличных от TCP/UDP/ICMP, и полетели тикеты на нерабочий GRE с вытекающей ошибкой Sep 13 09:57:40: %IOSXE-6-PLATFORM: F0: cpp_cp: QFP:0.0 Thread:128 TS:00013985005758018400 %NAT-6-ADDR_ALLOC_FAILURE: Address allocation failed; pool 1 may be exhausted Количество таких трансляций было = 330 (sh ip nat translations | exclude tcp|udp|icmp) Количество используемых адресов в PAP было всего 107. show platform hardware qfp active feature nat datapath pap laddrpergaddr | count gaddr Number of lines which match regexp = 107 Количество трансляций 1-to-1, отсутствующих по количеству используемых адресов в PAP, достигло 318 (256+169-107). Access листы для pool`ов были permit ip ..... any Теперь сделал permit tcp ..... any permit udp ..... any permit icmp ..... any permit gre ..... any Ну собственно после чистки трансляций и crash`a стало: Total active translations: 362963 (0 static, 362963 dynamic; 362960 extended) [Id: 1] access-list NAT-USERS pool Pool-1 refcount 187744 pool Pool-1: id 1, netmask 255.255.255.0 start *.*.*.* end *.*.*.* type generic, total addresses 256, allocated 42 (16%), misses 0 [Id: 2] access-list NAT-USERS2 pool Pool-2 refcount 175220 pool Pool-2: id 2, netmask 255.255.255.0 start *.*.*.* end *.*.*.* type generic, total addresses 256, allocated 36 (14%), misses 0 Посмотрим как много будет трансляций вне PAP с применёнными access листами permit tcp/udp/icmp/gre... Пока, всего 15.
  11. Коллеги, прошу подсказать, какой софт показал себя более стабильным и без багов для ASR1004 (RP2) на данный момент? На древнем софте 15.4(3)S1 после нескольких лет стабильности столкнулись с: - не работающим ip nat translation max-entries all-host; - %NAT-6-ADDR_ALLOC_FAILURE: Address allocation failed; - дропы GRE; - crash с падением Etherchannel после clear транслиций %CPPDRV-3-LOCKDOWN: F0: cpp_cp: QFP0.0 CPP Driver LOCKDOWN encountered due to previous fatal error (HW: QFP interrupt).
  12. А при этом в отчёте по пропускам в "Количество нарушений (записей реестра)" какая цифра стоит?
  13. Только что много чего убрали https://pastebin.com/66CUnCDD
  14. Пришло https://pastebin.com/nh2aWTDb И Яндекс с ВК под раздачу попали. Да и чего там только нет. Обновление дампа от 00:06. Записи в реестр добавлены между 15:00 и 00:06, а ревизор уже пропусков нафиксил. А чем им NTP сервер 194.190.168.1 то помешал от MSK-IX?
  15. А как у Вас отработается запрос, например cdn.samsungcloudsolution.com, если Авторитативным DNS сервером отдаются заблоченные из 52.192.0.0/11: 52.222.149.208 52.222.149.73 52.222.149.2 52.222.149.142 52.222.149.76 52.222.149.145 52.222.149.158 52.222.149.106 Но, мы знаем, что в интернете есть ещё другие авторитативные сервера которые отдают: 13.33.23.230 54.192.98.7 54.192.98.82 54.192.98.84 54.192.98.139 54.192.98.172 54.192.98.216 54.192.98.228 54.192.98.231 13.33.23.8 13.33.23.85 13.33.23.87 13.33.23.138 13.33.23.155 13.33.23.156 13.33.23.166 Но, Вашему DNS серверу авторитатативный всегда отдаёт из 52.192.0.0/11. Другое дело когда на запрос получаем список IP в котором часть заблочена, а другая часть нет.
  16. А как unbound по производительности в отличии от Bind себя поведёт при большом количестве юзеров >10k ?
  17. Умственные способности "блокировщиков" не перестают удивлять. Что они хотели добиться этими url`ами в ресеетре?: http://1000symbols.ru/?utm_source=google.ru http://1000symbols.ru/?utm_source=www.google.ru   Это они так детектят пропуски по IP. Ломятся на IP, а там редирект. И в пропуск пишут уже domain после редиректа.
  18. А, нашёл, это они так проверяют блокировку по подсетям. Ломанулись на http://18.197.0.0 и https://18.197.0.0 и получив редирект на www.mepin.com зафиксировали таким образом пропуск. Адрес перенаправления С: http://18.197.0.0 (18.197.0. 0), https://18.197.0.0/ (18. 197.0.0) Была необходимость на несколько секунд роуты погасить (((
  19. Ревизор нашёл пропуск в виде https://www.mepin.com Я в реестре не нашёл его. Есть ли такой в реестре?
  20. extFilter проработал почти сутки и упал. При запуске: Syntax error: Cannot convert to boolean: none Подскажите пожалуйста, куда смотреть. UPD1: сейчас пересмотрю конфиг, т.к. с дефолтным конфигом уже другие, соответствующие ошибки. UPD2: пардон, всё летатет ;) Сам в конфиг вписал none, там где должно быть false. max197616, спасибо огромное за твой труд!
  21. Тоже самое было на nfqfilter. Запустил extFilter, стало норм. Теперь оба молотят.