• Відкриті торги з особливостями
  • Однолотова
  • КЕП

Закупівля комплексу обладнання для побудови центру обробки даних

Завершена

70 007 000.00 UAH з ПДВ
мін. крок: 0.5% або 350 035.00 UAH
Період оскарження: 27.06.2025 15:11 - 02.07.2025 00:00
Скарга
Відхилено
КЕП

Щодо виявлених порушень законодавства у сфері публічних закупівель (встановлення замовником дискримінаційних вимог у тендерній документації)в порядку ст. 18 Закону України «Про публічні закупівлі»

Номер: 4e0a20e1c6134f678ab26d878d896782
Ідентифікатор запиту: UA-2025-06-27-008235-a.b1
Назва: Щодо виявлених порушень законодавства у сфері публічних закупівель (встановлення замовником дискримінаційних вимог у тендерній документації)в порядку ст. 18 Закону України «Про публічні закупівлі»
Скарга:
СКАРГА Щодо виявлених порушень законодавства у сфері публічних закупівель (встановлення замовником дискримінаційних вимог у тендерній документації)в порядку ст. 18 Закону України «Про публічні закупівлі» 27.06.2025року Замовником БЮРО ЕКОНОМІЧНОЇ БЕЗПЕКИ УКРАЇНИ (надалі – Замовник) було оголошено закупівлю товарів, на основі національного класифікатора України ДК 021:2015 «Єдиний закупівельний словник» ДК 021:2015: 32420000-3 — Мережеве обладнання, ідентифікатор закупівлі UA-2025-06-27-008235-a. Разом з оголошенням про проведення процедури закупівлі в електронній системі оприлюднено тендерну документацію. Товариство з обмеженою відповідальністю «АБКОММУНІКЕЙШЕН» код ЄДРПОУ 44286426 вважає умови процедури закупівлі, викладені в тендерній документації відкритих торгів з особливостями «Закупівля комплексу обладнання для побудови центру обробки даних» ідентифікатор закупівлі UA-2025-06-27-008235-a, такими, що суперечать нормам законодавства України у сфері публічних закупівель, зокрема Закону України «Про публічні закупівлі» (далі – Закон). Ми, як потенційний Учасник даної процедури закупівлі, переконані в тому, що вимоги, поставлені Замовником до потенційних учасників, є дискримінаційними та такими, що порушують права Скаржника на рівну конкуренцію з огляду на таке: 1) Щодо правильного вибору ДК класифікатора. Ознайомившись із закупівлею постало питання правильності вибору класифікатора ДК 021:2015: 32420000-3 — Мережеве обладнання - пункт 4.1. Розділ 1. Загальні положення. Згідно з даними в оприлюдненій тендерній документації в Додатку 5 до тендерної документації "ІНФОРМАЦІЯ ПРО НЕОБХІДНІ ТЕХНІЧНІ, ЯКІСНІ ТА КІЛЬКІСНІ ХАРАКТЕРИСТИКИ ПРЕДМЕТА ЗАКУПІВЛІ, У ТОМУ ЧИСЛІ ВІДПОВІДНА ТЕХНІЧНА СПЕЦИФІКАЦІЯ", предмет закупівлі включає: серверне обладнання (сервери, системи зберігання, контролери), ліцензійне програмне забезпечення (наприклад, ОС, віртуалізація, резервне копіювання тощо), послуги з встановлення, конфігурації та пусконаладки. Відповідно до Класифікатора ДК 021:2015 даній закупівлі обгрунтовано відповідає код ДК 30210000-4 – Машини для обробки даних (апаратна частина), який охоплює сервери, сховища, апаратні комплекси, а також дозволяє включати супутні послуги та ПЗ як частину постачання, що є предметом закупівлі UA-2025-06-27-008235-a. Даний факт вибору неправильного коду ДК класифікатору ДК 021:2015 є вагомою підставою для контролюючих органів визнати договір нікчемним. Підстави, за яких договір про закупівлю є нікчемним визначені пунктом 21 Особливостей, зокрема у разі, коли назва предмета закупівлі із зазначенням коду за Єдиним закупівельним словником не відповідає товарам, роботам чи послугам, що фактично закуплені замовником. Зауважимо, що згідно з пунктом 3 Порядку визначення предмета закупівлі, затвердженого Наказом Мінекономіки 15 квітня 2020 року № 708 предмет закупівлі товарів і послуг визначається замовником згідно з пунктами 21 і 34 частини першої статті 1 Закону та за показником четвертої цифри Єдиного закупівельного словника. Крім того, звертаємо увагу, що згідно з частиною другою статті 215 Цивільного кодексу України недійсним є правочин, якщо його недійсність встановлена законом (нікчемний правочин). У цьому разі визнання такого правочину недійсним судом не вимагається. Для наочності проблеми та можливих наслідків наводимо існуючу практику недавніх висновків моніторингу, де органами контролю було встановлено порушення в частині неправильного визначення предмета закупівлі за Єдиним закупівельним словником. Закупівля: Трактор колісний з навісним обладнанням / UA-2024-07-12-006518-a (зобов’язання: припинити зобов’язання за договором про закупівлю, в тому числі із застосуванням відповідних наслідків недійсності/нікчемності договору). Висновок від 11.09.2024; Закупівля: Гречка, рис, пшоно, крупа ячнева, крупа вівсяна, крупа пшенична, борошно пшеничне в/г, крупа кукурудзяна, крупа перлова, кус-кус, крупа арнаутка / UA-2023-12-28-005652-a (зобов’язання: розірвати договір про закупівлю, в тому числі із застосуванням відповідних наслідків недійсності/нікчемності договору). Висновок від 19.06.2024; Закупівля: Капітальний ремонт дороги по вулиці Шевченка від буд. №2 до буд №8 (біля парку Здебського) в с. Розвадів Стрийського району Львівської області / UA-2023-06-06-002016-a (зобов’язання: розірвати договір, враховуючи норми договору, Закону України «Про публічні закупівлі», Цивільного та Господарського кодексів України). Висновок від 11.10.2023. Зверніть увагу, що у всіх наведених висновках, аудитори зобов’язали замовників розірвати договір через невірно обраний замовником ДК класифікатор ДК 021:2015. Просимо зобов'язати Замовника враховуючи відсутність технічної можливості виправлення даних електронних полів закупівлі а саме - дані про Класифікатор та його відповідний код відмінити закупівлю - для уникнення потенційного визнання договору нікчемним. 2) Стосовно «Мережевий комутатор, тип 1 (Juniper QFX5120-48Y-AFO2), або еквівалент» (сторінка 30 Додатку 5) В Додатку 5 тендерної документації (сторінка 30) наявна вимога, що Операційна система комутатора має підтримувати: • Застосування перевіреної конфігурації в заздалегідь встановлений час. • Повернення на попередню працездатну конфігурацію у разі помилки адміністратора. Вимога щодо підтримки staged config з можливістю застосування перевіреної конфігурації у заздалегідь встановлений час та автоматичного повернення на попередню конфігурацію у разі помилки адміністратора є архітектурною особливістю Juniper Junos OS. Інші ОС реалізують стабільність конфігурації іншими методами (checkpoint, archive, зовнішній backup). Це штучно звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». 1. Це пряма реалізація commit-моделі (staged config + commit confirmed + commit at time), що є фірмовою архітектурною особливістю Juniper Junos OS. 2️. У більшості інших ОС: • Cisco IOS XE / NX-OS: немає повноцінної commit-моделі з відкладеним застосуванням. Є лише archive config або configure replace. • HPE Comware, Aruba, Dell OS10: аналогічно — staged config та commit confirmed не підтримуються в нативному вигляді. 3️. Це обмежує вибір тільки до виробників, що реалізують staged config, а таких немає, окрім Juniper. https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-configuration-commit.html Вимагаємо видалити цю вимогу або допустити еквівалентну реалізацію rollback механізмів. Дана вимога є дискримінаційною. 3) Стосовно «Мережевий комутатор, тип 1 (Juniper QFX5120-48Y-AFO2), або еквівалент» (сторінка 31 Додатку 5) В Додатку 5 тендерної документації ( сторінка 31 ) наявна вимога, що Функціональність 2-го рівня: • Підтримка технології агрегації Ethernet каналів з балансуванням за МАС-адресою джерела/призначення, IP-адресою джерела/призначення, TCP/UDP-портами джерела/призначення, полем Ethertype, VLAN ID, вхідним інтерфейсом. Вимога щодо обов’язкової підтримки балансування LAG за полем Ethertype, VLAN ID та вхідним інтерфейсом є вузькоспецифічною для окремих рішень (Juniper). Більшість виробників (Cisco, Arista, Dell, HPE) реалізують стандартне балансування LAG на рівні L2/L3/L4 (MAC, IP, TCP/UDP), що забезпечує рівнозначну ефективність. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». 1. Балансування по MAC, IP, TCP/UDP-портам — це стандартна функція LAG/LACP у всіх сучасних комутаторах (Cisco, Dell, Arista, HPE, Juniper). 2️. Балансування по полю Ethertype та вхідному інтерфейсу — це не галузевий стандарт: • Це реалізовано у Juniper як частина специфічного hash-policy. • Cisco, Arista, Dell — не мають granular hash по Ethertype та ingress interface. Вони використовують стандартні Layer2/3/4 хеш-поля. • IEEE 802.3ad (LACP) не визначає Ethertype як обов’язковий параметр балансування. 3️. VLAN ID — теж не завжди доступний як окремий хеш-параметр у всіх вендорів, бо звичайний ASIC хешує L2/3/4 поля. https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet/topics/concept/ethernet-link-aggregation-acx.html Вимагаємо видалити параметри «Ethertype», «VLAN ID» та «вхідний інтерфейс» або дозволити еквівалентні LAG hash алгоритми.   4) Стосовно «Мережевий комутатор, тип 1 (Juniper QFX5120-48Y-AFO2), або еквівалент» (сторінка 34 Додатку 5) В Додатку 5 тендерної документації (сторінка 34 ) наявна вимога, що Функціонал управляння має підтримувати: • Можливість написання та виконання скриптів SLAX, XSLT, Python. Вимога щодо обов’язкової підтримки скриптів SLAX та XSLT є специфічною для архітектури Juniper Junos OS і не реалізується іншими виробниками (Cisco, Dell, Arista, HPE). Більшість сучасних рішень підтримують Python або API-інтеграції. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». SLAX і XSLT — це специфічні мови для обробки XML конфігурацій у Juniper Junos OS. • Це фірмовий підхід до автоматизації конфігурацій у Junos. • Інші виробники таку архітектуру не використовують: Cisco IOS XE, NX-OS — підтримують тільки EEM, TCL або Python. Dell OS10, Arista EOS — Python, bash або API. HPE Comware/Aruba — аналогічно: Python, Ansible, REST API. SLAX і XSLT — унікальні для Juniper. https://www.juniper.net/documentation/product/us/en/junos-snapshot-administrator-slax/ https://www.juniper.net/documentation/us/en/software/junos/automation-scripting/topics/concept/junos-script-automation-xslt-overview.html Вимагаємо видалити «SLAX» та «XSLT», залишивши Python або еквівалентні механізми автоматизації. 5) Стосовно «Мережевий комутатор, тип 2 та тип 3 (Juniper EX4100-48T та Juniper EX4100-48P), або еквівалент» (сторінка 36 Додатку 5) В Додатку 5 тендерної документації (сторінка 36) наявна вимога, що Операційна система: • Пакетне застосування команд конфігурації (commit модель). • Можливість застосування нової конфігурації у заданий момент часу. • Можливість відкату на попередню конфігурацію (rollback). • Можливість автоматичного відкату на попередню конфігурацію через заданий інтервал часу. Вимоги щодо підтримки commit-моделі, відкладеного застосування конфігурації у заданий час, rollback та автоматичного rollback через commit confirmed є специфічною архітектурною особливістю Juniper Junos OS. Інші ОС (Cisco, Dell, Arista, HPE) реалізують аналогічну стабільність конфігурацій через checkpoint, archive, configure replace або зовнішній конфіг-менеджмент. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». 1. Повноцінна commit-модель у вигляді staged candidate config + timed commit + commit confirmed — це архітектурна особливість Juniper Junos OS. 2️. Інші ОС (Cisco IOS XE, NX-OS, Dell OS10, Aruba AOS-CX, HPE Comware): • Використовують інший підхід — конфігурація застосовується по мірі введення команд, немає окремого commit. • Rollback реалізується через checkpoint, archive config або configure replace. • Відкладене застосування конфігурації (scheduled commit) нативно відсутнє — це робиться через зовнішній скрипт/автоматизацію. Ця вимога прив’язує до єдиного виробника, що прямо обмежує ринок. Більшість виробників пропонують: Checkpoint. • Archive конфігурацій. • Ручний або скриптовий rollback. • Зовнішній конфіг-менеджмент (Ansible, GitOps, Python EEM). Це дозволяє досягти того ж рівня стабільності. https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-configuration-commit.html . Вимагаємо видалити ці вимоги або передбачити еквівалентну реалізацію через інші механізми. 6) Стосовно «Мережевий комутатор, тип 2 та тип 3 (Juniper EX4100-48T та Juniper EX4100-48P), або еквівалент» (сторінка 41 Додатку 5) В Додатку 5 тендерної документації (сторінка 41) наявна вимога, що Вимоги до функціональності 2-го рівня комутації: • Обмеження кількості MAC адрес на даному VLAN. Вимога щодо обмеження кількості MAC-адрес на рівні VLAN є специфічною для Carrier Ethernet/Metro Ethernet класу. Більшість виробників (Cisco, Dell, Arista, HPE) реалізують MAC limiting через Port Security на портах, що дозволяє досягти того ж ефекту. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». Глобальний MAC limit на VLAN — не є ринковим стандартом для L2-комутаторів Access/Leaf. • Вимога глобального VLAN limit штучно прив’язує до Metro Ethernet або Carrier Ethernet фіч, які є у вузького переліку платформ (наприклад, Juniper EX з PE-функціями). • Більшість Access/Leaf комутаторів такої функції не мають — тому це звужує вибір, суперечить принципу рівної участі. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/mac-limit-edit-vlans-qfx-series.html Вимагаємо видалити цю вимогу або дозволити еквівалентну реалізацію обмеження MAC-адрес на портах. ПРОСИМО: 1. Прийняти скаргу до розгляду. 2. Визнати умови, встановлені Тендерною документацією Процедури закупівлі, такими, що суперечать законодавству у сфері публічних закупівель. 3. Зобов’язати Замовника, з метою усунення порушень законодавства з питань публічних закупівель, внести зміни до Тендерної документації на підставах, наведених в описовій частині цієї скарги. Перелік документів (доказів), що підтверджують наявність у скаржника порушених прав та охоронюваних законом інтересів з приводу рішення, дії чи бездіяльності Замовника: 1) Тендерна документація 2) Додаток 5.
Дата розгляду скарги: 10.07.2025 10:00
Місце розгляду скарги: Антимонопольний комітет України
Дата прийняття рішення про прийняття скарги до розгляду: 03.07.2025 15:23
Дата прийняття рішення про відхилення скарги: 15.07.2025 11:59
Автор: ТОВАРИСТВО З ОБМЕЖЕНОЮ ВІДПОВІДАЛЬНІСТЮ "АБКОММУНІКЕЙШЕН", Хандога Микола 380663133076 Mykola.Khandoha@abcommunication.com.ua

Пункт скарги

Порядковий номер пункту скарги: 1
Номер: 0bcc17f7c1b64a9288fa6700c5851ef7
Заголовок пункту скарги: 1) Щодо правильного вибору ДК класифікатора.
Тип пов'язаного елемента: Скарга на лот
Тип порушення: Порушення, пов'язані з вимогами законодавства
Ідентифікатор класифікації: Інші дії/бездіяльність замовника (у т.ч. ненадання роз’яснень тощо)
Тип порушення: Інші дії/бездіяльність замовника (у т.ч. ненадання роз’яснень тощо)
Опис суті пункту скарги: Ознайомившись із закупівлею постало питання правильності вибору класифікатора ДК 021:2015: 32420000-3 — Мережеве обладнання - пункт 4.1. Розділ 1. Загальні положення. Згідно з даними в оприлюдненій тендерній документації в Додатку 5 до тендерної документації "ІНФОРМАЦІЯ ПРО НЕОБХІДНІ ТЕХНІЧНІ, ЯКІСНІ ТА КІЛЬКІСНІ ХАРАКТЕРИСТИКИ ПРЕДМЕТА ЗАКУПІВЛІ, У ТОМУ ЧИСЛІ ВІДПОВІДНА ТЕХНІЧНА СПЕЦИФІКАЦІЯ", предмет закупівлі включає: серверне обладнання (сервери, системи зберігання, контролери), ліцензійне програмне забезпечення (наприклад, ОС, віртуалізація, резервне копіювання тощо), послуги з встановлення, конфігурації та пусконаладки. Відповідно до Класифікатора ДК 021:2015 даній закупівлі обгрунтовано відповідає код ДК 30210000-4 – Машини для обробки даних (апаратна частина), який охоплює сервери, сховища, апаратні комплекси, а також дозволяє включати супутні послуги та ПЗ як частину постачання, що є предметом закупівлі UA-2025-06-27-008235-a. Даний факт вибору неправильного коду ДК класифікатору ДК 021:2015 є вагомою підставою для контролюючих органів визнати договір нікчемним. Підстави, за яких договір про закупівлю є нікчемним визначені пунктом 21 Особливостей, зокрема у разі, коли назва предмета закупівлі із зазначенням коду за Єдиним закупівельним словником не відповідає товарам, роботам чи послугам, що фактично закуплені замовником. Зауважимо, що згідно з пунктом 3 Порядку визначення предмета закупівлі, затвердженого Наказом Мінекономіки 15 квітня 2020 року № 708 предмет закупівлі товарів і послуг визначається замовником згідно з пунктами 21 і 34 частини першої статті 1 Закону та за показником четвертої цифри Єдиного закупівельного словника. Крім того, звертаємо увагу, що згідно з частиною другою статті 215 Цивільного кодексу України недійсним є правочин, якщо його недійсність встановлена законом (нікчемний правочин). У цьому разі визнання такого правочину недійсним судом не вимагається. Для наочності проблеми та можливих наслідків наводимо існуючу практику недавніх висновків моніторингу, де органами контролю було встановлено порушення в частині неправильного визначення предмета закупівлі за Єдиним закупівельним словником. Закупівля: Трактор колісний з навісним обладнанням / UA-2024-07-12-006518-a (зобов’язання: припинити зобов’язання за договором про закупівлю, в тому числі із застосуванням відповідних наслідків недійсності/нікчемності договору). Висновок від 11.09.2024; Закупівля: Гречка, рис, пшоно, крупа ячнева, крупа вівсяна, крупа пшенична, борошно пшеничне в/г, крупа кукурудзяна, крупа перлова, кус-кус, крупа арнаутка / UA-2023-12-28-005652-a (зобов’язання: розірвати договір про закупівлю, в тому числі із застосуванням відповідних наслідків недійсності/нікчемності договору). Висновок від 19.06.2024; Закупівля: Капітальний ремонт дороги по вулиці Шевченка від буд. №2 до буд №8 (біля парку Здебського) в с. Розвадів Стрийського району Львівської області / UA-2023-06-06-002016-a (зобов’язання: розірвати договір, враховуючи норми договору, Закону України «Про публічні закупівлі», Цивільного та Господарського кодексів України). Висновок від 11.10.2023. Зверніть увагу, що у всіх наведених висновках, аудитори зобов’язали замовників розірвати договір через невірно обраний замовником ДК класифікатор ДК 021:2015. Просимо зобов'язати Замовника враховуючи відсутність технічної можливості виправлення даних електронних полів закупівлі а саме - дані про Класифікатор та його відповідний код відмінити закупівлю - для уникнення потенційного визнання договору нікчемним.
Вимоги: Зобов'язати замовника відмінити процедуру закупівлі

Порядковий номер пункту скарги: 2
Номер: 34defbb0f26544eb93217921aa3994de
Заголовок пункту скарги: 2) Стосовно «Мережевий комутатор, тип 1 (Juniper QFX5120-48Y-AFO2), або еквівалент» (сторінка 30 Додатку 5)
Тип пов'язаного елемента: Скарга на лот
Тип порушення: Порушення, пов'язані з вимогами законодавства
Ідентифікатор класифікації: Технічна специфікація предмета закупівлі
Тип порушення: Технічна специфікація предмета закупівлі
Опис суті пункту скарги: В Додатку 5 тендерної документації (сторінка 30) наявна вимога, що Операційна система комутатора має підтримувати:
• Застосування перевіреної конфігурації в заздалегідь встановлений час.
• Повернення на попередню працездатну конфігурацію у разі помилки адміністратора.
Вимога щодо підтримки staged config з можливістю застосування перевіреної конфігурації у заздалегідь встановлений час та автоматичного повернення на попередню конфігурацію у разі помилки адміністратора є архітектурною особливістю Juniper Junos OS. Інші ОС реалізують стабільність конфігурації іншими методами (checkpoint, archive, зовнішній backup). Це штучно звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі».
1. Це пряма реалізація commit-моделі (staged config + commit confirmed + commit at time), що є фірмовою архітектурною особливістю Juniper Junos OS.
2️. У більшості інших ОС:
• Cisco IOS XE / NX-OS: немає повноцінної commit-моделі з відкладеним застосуванням. Є лише archive config або configure replace.
• HPE Comware, Aruba, Dell OS10: аналогічно — staged config та commit confirmed не підтримуються в нативному вигляді.
3️. Це обмежує вибір тільки до виробників, що реалізують staged config, а таких немає, окрім Juniper.
https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-configuration-commit.html
Вимагаємо видалити цю вимогу або допустити еквівалентну реалізацію rollback механізмів. Дана вимога є дискримінаційною.
Вимоги: Зобов'язати замовника внести зміни до тендерної документації

Порядковий номер пункту скарги: 3
Номер: 3e3c376b144a4fc5b8e5312b82afa4a9
Заголовок пункту скарги: 3) Стосовно «Мережевий комутатор, тип 1 (Juniper QFX5120-48Y-AFO2), або еквівалент» (сторінка 31 Додатку 5)
Тип пов'язаного елемента: Скарга на лот
Тип порушення: Порушення, пов'язані з вимогами законодавства
Ідентифікатор класифікації: Технічна специфікація предмета закупівлі
Тип порушення: Технічна специфікація предмета закупівлі
Опис суті пункту скарги: В Додатку 5 тендерної документації ( сторінка 31 ) наявна вимога, що Функціональність 2-го рівня:
• Підтримка технології агрегації Ethernet каналів з балансуванням за МАС-адресою джерела/призначення, IP-адресою джерела/призначення, TCP/UDP-портами джерела/призначення, полем Ethertype, VLAN ID, вхідним інтерфейсом. Вимога щодо обов’язкової підтримки балансування LAG за полем Ethertype, VLAN ID та вхідним інтерфейсом є вузькоспецифічною для окремих рішень (Juniper). Більшість виробників (Cisco, Arista, Dell, HPE) реалізують стандартне балансування LAG на рівні L2/L3/L4 (MAC, IP, TCP/UDP), що забезпечує рівнозначну ефективність. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі».
1. Балансування по MAC, IP, TCP/UDP-портам — це стандартна функція LAG/LACP у всіх сучасних комутаторах (Cisco, Dell, Arista, HPE, Juniper).
2️. Балансування по полю Ethertype та вхідному інтерфейсу — це не галузевий стандарт:
• Це реалізовано у Juniper як частина специфічного hash-policy.
• Cisco, Arista, Dell — не мають granular hash по Ethertype та ingress interface. Вони використовують стандартні Layer2/3/4 хеш-поля.
• IEEE 802.3ad (LACP) не визначає Ethertype як обов’язковий параметр балансування.
3️. VLAN ID — теж не завжди доступний як окремий хеш-параметр у всіх вендорів, бо звичайний ASIC хешує L2/3/4 поля.
https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet/topics/concept/ethernet-link-aggregation-acx.html
Вимагаємо видалити параметри «Ethertype», «VLAN ID» та «вхідний інтерфейс» або дозволити еквівалентні LAG hash алгоритми.
Вимоги: Зобов'язати замовника внести зміни до тендерної документації

Порядковий номер пункту скарги: 4
Номер: 41293a511a4f41c0882dc119cd8051d1
Заголовок пункту скарги: 4) Стосовно 4) «Мережевий комутатор, тип 1 (Juniper QFX5120-48Y-AFO2), або еквівалент» (сторінка 34 Додатку 5)
Тип пов'язаного елемента: Скарга на лот
Тип порушення: Порушення, пов'язані з вимогами законодавства
Ідентифікатор класифікації: Технічна специфікація предмета закупівлі
Тип порушення: Технічна специфікація предмета закупівлі
Опис суті пункту скарги: В Додатку 5 тендерної документації (сторінка 34 ) наявна вимога, що Функціонал управляння має підтримувати:
• Можливість написання та виконання скриптів SLAX, XSLT, Python. Вимога щодо обов’язкової підтримки скриптів SLAX та XSLT є специфічною для архітектури Juniper Junos OS і не реалізується іншими виробниками (Cisco, Dell, Arista, HPE). Більшість сучасних рішень підтримують Python або API-інтеграції. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі».
SLAX і XSLT — це специфічні мови для обробки XML конфігурацій у Juniper Junos OS.
• Це фірмовий підхід до автоматизації конфігурацій у Junos.
• Інші виробники таку архітектуру не використовують:
Cisco IOS XE, NX-OS — підтримують тільки EEM, TCL або Python.
Dell OS10, Arista EOS — Python, bash або API.
HPE Comware/Aruba — аналогічно: Python, Ansible, REST API.
SLAX і XSLT — унікальні для Juniper.
https://www.juniper.net/documentation/product/us/en/junos-snapshot-administrator-slax/
https://www.juniper.net/documentation/us/en/software/junos/automation-scripting/topics/concept/junos-script-automation-xslt-overview.html
Вимагаємо видалити «SLAX» та «XSLT», залишивши Python або еквівалентні механізми автоматизації.
Вимоги: Зобов'язати замовника внести зміни до тендерної документації

Порядковий номер пункту скарги: 5
Номер: 2e5aad64f9bd41b5a1acab805ed764fb
Заголовок пункту скарги: 5) Стосовно «Мережевий комутатор, тип 2 та тип 3 (Juniper EX4100-48T та Juniper EX4100-48P), або еквівалент» (сторінка 36 Додатку 5)
Тип пов'язаного елемента: Скарга на лот
Тип порушення: Порушення, пов'язані з вимогами законодавства
Ідентифікатор класифікації: Технічна специфікація предмета закупівлі
Тип порушення: Технічна специфікація предмета закупівлі
Опис суті пункту скарги: В Додатку 5 тендерної документації (сторінка 36) наявна вимога, що Операційна система:
• Пакетне застосування команд конфігурації (commit модель).
• Можливість застосування нової конфігурації у заданий момент часу.
• Можливість відкату на попередню конфігурацію (rollback).
• Можливість автоматичного відкату на попередню конфігурацію через заданий інтервал часу.
Вимоги щодо підтримки commit-моделі, відкладеного застосування конфігурації у заданий час, rollback та автоматичного rollback через commit confirmed є специфічною архітектурною особливістю Juniper Junos OS. Інші ОС (Cisco, Dell, Arista, HPE) реалізують аналогічну стабільність конфігурацій через checkpoint, archive, configure replace або зовнішній конфіг-менеджмент. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». 1. Повноцінна commit-модель у вигляді staged candidate config + timed commit + commit confirmed — це архітектурна особливість Juniper Junos OS.
2️. Інші ОС (Cisco IOS XE, NX-OS, Dell OS10, Aruba AOS-CX, HPE Comware):
• Використовують інший підхід — конфігурація застосовується по мірі введення команд, немає окремого commit.
• Rollback реалізується через checkpoint, archive config або configure replace.
• Відкладене застосування конфігурації (scheduled commit) нативно відсутнє — це робиться через зовнішній скрипт/автоматизацію.
Ця вимога прив’язує до єдиного виробника, що прямо обмежує ринок.
Більшість виробників пропонують:
Checkpoint.
• Archive конфігурацій.
• Ручний або скриптовий rollback.
• Зовнішній конфіг-менеджмент (Ansible, GitOps, Python EEM).
Це дозволяє досягти того ж рівня стабільності. https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-configuration-commit.html . Вимагаємо видалити ці вимоги або передбачити еквівалентну реалізацію через інші механізми.
Вимоги: Зобов'язати замовника внести зміни до тендерної документації

Порядковий номер пункту скарги: 6
Номер: 960a69cf6e8f436da95daf0bda0786ae
Заголовок пункту скарги: 6) Стосовно «Мережевий комутатор, тип 2 та тип 3 (Juniper EX4100-48T та Juniper EX4100-48P), або еквівалент» (сторінка 41 Додатку 5)
Тип пов'язаного елемента: Скарга на лот
Тип порушення: Порушення, пов'язані з вимогами законодавства
Ідентифікатор класифікації: Технічна специфікація предмета закупівлі
Тип порушення: Технічна специфікація предмета закупівлі
Опис суті пункту скарги: В Додатку 5 тендерної документації (сторінка 41) наявна вимога, що Вимоги до функціональності 2-го рівня комутації:
• Обмеження кількості MAC адрес на даному VLAN.
Вимога щодо обмеження кількості MAC-адрес на рівні VLAN є специфічною для Carrier Ethernet/Metro Ethernet класу. Більшість виробників (Cisco, Dell, Arista, HPE) реалізують MAC limiting через Port Security на портах, що дозволяє досягти того ж ефекту. Це звужує конкуренцію, що суперечить ч. 4 ст. 5 ЗУ «Про публічні закупівлі». Глобальний MAC limit на VLAN — не є ринковим стандартом для L2-комутаторів Access/Leaf.
• Вимога глобального VLAN limit штучно прив’язує до Metro Ethernet або Carrier Ethernet фіч, які є у вузького переліку платформ (наприклад, Juniper EX з PE-функціями).
• Більшість Access/Leaf комутаторів такої функції не мають — тому це звужує вибір, суперечить принципу рівної участі.
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/mac-limit-edit-vlans-qfx-series.html
Вимагаємо видалити цю вимогу або дозволити еквівалентну реалізацію обмеження MAC-адрес на портах.
Вимоги: Зобов'язати замовника внести зміни до тендерної документації