Блог

  • Помилка обробки пакета BGP призводить до тривалого простою мережі

    Помилка обробки пакета BGP призводить до тривалого простою мережі

    BGP – це магістральний протокол та «клей» Інтернету, який розсилає інформацію про маршрути між мережами провайдерів. Коротше кажучи, цей протокол BGP є дуже важливим елементом, необхідним для правильної роботи глобальної мережі в цілому.

    Програмне забезпечення маршрутизаторів, що реалізує BGP, не є ідеальним, оскільки як комерційні, так і версії з відкритим вихідним кодом мають проблеми в реалізації цього протоколу маршрутизації.

    У той час як багато недоліків незначні і пов’язані з проблемами маршрутизації, помилка обробки пакета BGP, що розглядається, викликає особливе занепокоєння, так як може поширюватися як комп’ютерний черв’як.

    Власник BGP[.] Бен Картрайт-Кокс виявив цей недолік; Це компанія, яка пропонує послуги моніторингу BGP для виявлення та вирішення проблем.

    Помилковий атрибут

    2 червня 2023 року невелика бразильська мережа повторно анонсувала маршрут із пошкодженим атрибутом у пакеті, що потенційно вплинуло на транзитні маршрутизатори.
    Багато маршрутизаторів ігнорували цей атрибут, але приймаючи його маршрутизатори Juniper, і відповідь на помилку в пакеті закривали сесії BGP, тим самим порушуючи пов’язаність своїх мереж з глобальною мережею Інтернет.
    Крім того, така помилка в пакеті BGP перериває сесію, припиняючи перетікання клієнтського трафіку доти, доки не буде виконано автоматичний перезапуск маршрутизатора, який зазвичай займає від декількох секунд до декількох хвилин.
    Завершення сесії BGP внаслідок отримання пакету з помилковим атрибутом
    Завершення сесії BGP внаслідок отримання пакету з помилковим атрибутом

    Це торкнулося багатьох операторів, таких як COLT, збій у роботі яких і привернув увагу до цієї проблеми.

    Помилка, пов’язана з обробкою помилок BGP

    Кожен атрибут пакета оновлень BGP починається з прапорів, включаючи ключовий ‘транзитивний біт’:
    Транзитивний біт у пакеті оновлень BGP
    Транзитивний біт у пакеті оновлень BGP
    Якщо транзитивний біт атрибута встановлений, а маршрутизатор його не розуміє, він копіюється на інший маршрутизатор, що може призвести до сліпого розповсюдження невідомої маршрутної інформації.
    Завершення роботи сесії BGP порушує перетікання трафіку між автономними системами і може поширюватися як черв’як. У той час як атрибути, невідомі однієї реалізації, можуть призвести до завершення роботи іншої, створений BGP UPDATE може бути націлений на постачальника певного обладнання та вивести мережу постачальника з ладу цілком.
    Поширення помилки в пакеті BGP через мережу
    Поширення помилки в пакеті BGP через мережу
    Ефект від атаки зберігається досить довгий час, оскільки анонсований маршрут все залишається в одноранговому маршрутизаторі, навіть після його перезапуску, при передачі нового пакета оновлень BGP він ініціює ще одне скидання сесії, що призводить до тривалих простоїв.
    Більше того, щоб перевірити, які реалізації протоколу BGP схильні до цієї вразливості можна використовувати просту утиліту для тестування.

    Незачеплені постачальники обладнання

    Далі наводимо список постачальників, які не торкнулися цієї вразливості:
    • MikroTik RouterOS 7+
    • Ubiquiti EdgeOS
    • Arista EOS
    • Huawei NE40
    • Cisco IOS-XE / «Classic» / XR
    • Bird 1.6, All versions of Bird 2.0
    • GoBGP

    Піддані версії обладнання або ПЗ

    • Juniper Networks Junos OS
    • Nokia’s SR-OS
    • Extreme Networks’ EXOS
    • OpenBSD’s OpenBGPd
    • OpenBSD’s FRRouting

    Питання та відповіді

    Раніше було повідомлено про ці вразливості всім схильним до неї постачальникам обладнання та програмного забезпечення. Після отримання повідомлення було отримано такі відповіді від порушених постачальників:
    • OpenBSD випустила патч
    • Компанії Juniper надали CVE
    • FRR також привласнив CVE
    • У Nokia проблему не вирішили
    • Extreme також не вирішив цієї проблеми
    Крім того, незважаючи на відсутність відповідей деяких постачальників обладнання, провайдери послуг інтернету самі можуть вжити заходів щодо запобігання потенційній експлуатації цієї вразливості.
  • Обработка bgp маршрутов при подключении клиентов Internet

    Обработка bgp маршрутов при подключении клиентов Internet

    Соединения с клиентами по протоколу BGP описываются в блоке конфигурации protocols bgp group INET_Customers, если соединение производится по протоколу IPv4 и в блоке конфигурации protocols bgp group IPv6_Customers.
       
      

        В целях уменьшения влияния анонсов отдельных клиентов на ресурсы маршрутизаторов Сети ограничивается количество префиксов, получаемых от клиентов, значением 1000 для префиксов IPv4 и 100 для IPv6 (это значение может быть изменено для отдельного клиента или пересмотрено для всей Сети при изменении общей ситуации в сети Internet). При превышении 80% от этого значения генерируется сообщение в журнале событий syslog, а при превышении 100% сессия BGP разрывается и может быть установлена вновь через 30 минут.

          С целью использования нескольких равноценных маршрутов в настройки добавляется команда multipath.

          Пример настройки bgp group для подключения клиентов:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                family inet {

                    unicast {

                        prefix-limit {

                            maximum 1000;

                            teardown 80 idle-timeout 30;

                        }

                    }

                }

                multipath;

            }

            group IPv6_Customers {

                type external;

                family inet6 {

                    unicast {

                        prefix-limit {

                            maximum 100;

                            teardown 80 idle-timeout 30;

    strong>                    }

                    }

                }

                multipath;

            }

        }

    }

          Для клиентов, подключающихся к услугам доступа в Internet, необходимо исключить анонс так называемых приватных автономных систем из атрибута AS_PATH. 

    Список приватных AS приведен по адресу: http://www.iana.org/assignments/as-numbers и составляет диапазон: AS64512 AS65535. 

    Несмотря на то, что архитектура сети IP/MPLS ПАО «Ростелеком» не подразумевает использование приватных номеров автономных систем, фильтрация таких AS при передаче маршрута в другие AS позволит избежать их анонсирования вследствие ошибки в настройке или злонамеренных действий внутри Сети.

          Пример фильтрации приватных AS для маршрутизатора Juniper:

    protocols {

        bgp {

            group INET_Customers {

                neighbor 4.3.2.1 {

                    remove-private;

                }

            }

        }

    }

          При приёме маршрутов от клиента необходима, прежде всего, фильтрация префиксов, приходящих от BGP маршрутизаторов сторонних сетей с целью недопущения попадания некорректной маршрутной информации, анонсируемой маршрутизаторами сторонних сетей в результате ошибки или умышленно. Фильтрация префиксов IPv4 осуществляется на базе списка, приведённого в [RFC6890]. Данный список содержит адреса следующих зарезервированных IETF и не подлежащих выделению сетей:

    • 0.0.0.0/8;
    • 0.0.0.0/1 – 0.0.0.0/32;
    • 10.0.0.0/8;
    • 100.64.0.0/10;
    • 172.16.0.0/12;
    • 192.168.0.0/16;
    • 127.0.0.0/8;
    • 192.0.0.0/24;
    • 192.0.2.0/24;
    • 169.254.0.0/16;
    • 192.88.99.0/24;
    • 198.18.0.0/15;
    • 198.51.100.0/24;
    • 203.0.113.0/24;
    • 224.0.0.0/4;
    • 240.0.0.0/4;

          Фильтрация префиксов IPv6 также осуществляется на базе списка, указанного в [RFC6890] и содержащего следующие префиксы:

    • ::/128;
    • ::1/128;
    • 64:ff9b::/96;
    • ::ffff:0:0/96;
    • 100::/64;
    • 2001::/23;
    • 2001:2::/48;
    • 2001:10::/28;
    • 2001:DB8::/32;
    • 2002::/16;
    • FF00::/8;
    • FE80::/10;
    • FEC0::/10;
    • FC00::/7;

          Помимо этого, с целью уменьшения общего числа префиксов в глобальной таблице маршрутизации фильтруются все префиксы с маской, длина которой превышает 24 бита для IPv4 и 48 бит для IPv6.
          Такая же фильтрация применяется и при передаче префиксов за пределы автономной системы Ростелеком.

          Пример политики для фильтрации неиспользуемых в сети Internet префиксов:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                family inet {

                    unicast;

                }

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    import sanity-check;

                    export sanity-check;

                    peer-as 65432;

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast;

                }

                neighbor 1::2 {

                    description «### Test IPv6 Client ###»;

                    import v6-sanity-check;

                    export v6-sanity-check;

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement sanity-check {

            term reject-bogons {

                from policy bogons;

                then reject;

            }

            term accept-blackhole {

                from community type_blackhole_route;

                then next policy;

            }

            term reject-long-prefixes {

                from {

                    route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;

                }

            }

        }

        policy-statement bogons {

            term rfc6890 {

                from {

                    route-filter 10.0.0.0/8 orlonger accept;

                    route-filter 172.16.0.0/12 orlonger accept;

                    route-filter 192.168.0.0/16 orlonger accept;

                    route-filter 0.0.0.0/1 through 0.0.0.0/32 accept;

                    route-filter 0.0.0.0/8 orlonger accept;

                    route-filter 100.64.0.0/10 orlonger accept;           

                    route-filter 127.0.0.0/8 orlonger accept;

                    route-filter 192.0.0.0/24 orlonger accept;

                    route-filter 192.0.2.0/24 orlonger accept;

                    route-filter 169.254.0.0/16 orlonger accept;

                    route-filter 192.88.99.0/24 orlonger accept;

                    route-filter 224.0.0.0/4 orlonger accept;

                    route-filter 240.0.0.0/4 orlonger accept;

                    route-filter 198.18.0.0/15 orlonger accept;

                    route-filter 198.51.100.0/24 orlonger accept;

                    route-filter 203.0.113.0/24 orlonger accept;            

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement v6-sanity-check {

            term reject-bogons {

                from policy v6-bogons;

                then reject;

            }

            term reject-long-prefixes {

                from {

                    route-filter ::/0 prefix-length-range /48-/128 reject;

                }

            }

        }

        policy-statement v6-bogons {

            term rfc6890 {

                from {

                    route-filter ::/128 exact accept;

                    route-filter ::1/128 exact accept;

                    route-filter ::/1 through ::/128 accept;

                    route-filter ::ffff:0:0/96 orlonger accept;

                    route-filter 100::/64 orlonger accept;           

                    route-filter 2001::/23 orlonger accept;

                    route-filter 2001:2::/48 orlonger accept;           

                    route-filter 2001:DB8::/32 orlonger accept;

                    route-filter 2001:10::/28 orlonger accept; 

                    route-filter 2002::/16 orlonger accept;

                    route-filter 64:ff9b::/32 orlonger accept;

                    route-filter FC00::/7 orlonger accept;

                    route-filter FE80::/10 orlonger accept;

                    route-filter FEC0::/10 orlonger accept;

                    route-filter FF00::/8 orlonger accept;

                 }

            }

            term reject-others {

                then reject;

            }

        }

    }

          После проверки разрешённой длины префиксов и принадлежности публичным диапазонам адресов производятся следующие операции с полученными от клиента маршрутами:

    • запрет приёма префиксов Ростелеком;
    • запрет приёма маршрута по умолчанию;
    • запрет приёма служебных и зарезервированных BGP Community;
    • установка параметров по умолчанию;
    • установка BGP Community, соответствующих данному региональному филиалу и МРФ;
    • проверка наличия BGP Community для сброса, назначение нового BGP NextHop;
    • проверка наличия BGP Community, изменяющих Local Preference, установка запрошенного значения.

          Пример обработки маршрутов при приёме от клиента на RGR:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                family inet {

                    unicast;

                }

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    local-address  1.1.1.1;

                    import [ sanity-check INET_CUSTOMER_in mark-routes-sib mark-region-routes-NVSK ];

                    peer-as 65432;

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast;

                }

                neighbor 1::2 {

                    description «### Test IPv6 Client ###»;

                    import [ v6-sanity-check INET_v6_CUSTOMER_in mark-routes-sib mark-region-routes-NVSK ];

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement sanity-check {

            term reject-bogons {

                from policy bogons;

                then reject;

            }

            term accept-blackhole {

                from community type_blackhole_route;

                then next policy;

            }

            term reject-long-prefixes {

                from {

                    route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;

                }

            }

        }

        policy-statement bogons {

            term rfc6890 {

                from {

                    route-filter 10.0.0.0/8 orlonger accept;

                    route-filter 172.16.0.0/12 orlonger accept;

                    route-filter 192.168.0.0/16 orlonger accept;

                    route-filter 0.0.0.0/1 through 0.0.0.0/32 accept;

                    route-filter 0.0.0.0/8 orlonger accept;

                    route-filter 100.64.0.0/10 orlonger accept;           

                    route-filter 127.0.0.0/8 orlonger accept;

                    route-filter 192.0.0.0/24 orlonger accept;

                    route-filter 192.0.2.0/24 orlonger accept;

                    route-filter 169.254.0.0/16 orlonger accept;

                    route-filter 192.88.99.0/24 orlonger accept;

                    route-filter 224.0.0.0/4 orlonger accept;

                    route-filter 240.0.0.0/4 orlonger accept;

                    route-filter 198.18.0.0/15 orlonger accept;

                    route-filter 198.51.100.0/24 orlonger accept;

                    route-filter 203.0.113.0/24 orlonger accept;           

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement v6-sanity-check {

            term reject-bogons {

                from policy v6-bogons;

                then reject;

            }

            term reject-long-prefixes {

                from {

                    route-filter ::/0 prefix-length-range /48-/128 reject;

                }

            }

        }

        policy-statement v6-bogons {

            term rfc6890 {

                from {

                    route-filter ::/128 exact accept;

                    route-filter ::1/128 exact accept;

                    route-filter ::/1 through ::/128 accept;

                    route-filter ::ffff:0:0/96 orlonger accept;

                    route-filter 100::/64 orlonger accept;           

                    route-filter 2001::/23 orlonger accept;

                    route-filter 2001:2::/48 orlonger accept;           

                    route-filter 2001:DB8::/32 orlonger accept;

                    route-filter 2001:10::/28 orlonger accept; 

                    route-filter 2002::/16 orlonger accept;

                    route-filter 64:ff9b::/32 orlonger accept;

                    route-filter FC00::/7 orlonger accept;

                    route-filter FE80::/10 orlonger accept;

                    route-filter FEC0::/10 orlonger accept;

                    route-filter FF00::/8 orlonger accept;

                 }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_CUSTOMER_in {

            term reject-RT-aggregate {

                from policy RT-aggregate;

                then reject;

            }

            term reject-RT-longer-prefixes {

                from policy RT-longer-prefixes;

                then reject;

            }

            term reject-default-route {

                from {

                    route-filter 0.0.0.0/0 exact;

                }

                then reject;

            }

            term remove-12389-communities {

                then {

                    community delete 12389:1-3X;

                    community delete 12389:1UZZ;

                }

            term remove-Well-Known-communities

                then {

                    community delete WellKnown0;

                    community delete WellKnown65535;

                }

            }

            term set-parameters {

                then {

                    metric 0;

                    local-preference 850;

                    community add type_Customer;

                }

            }

            term blackhole-route {

                from community type_blackhole_route;

                then {

                    next-hop discard;

                    community add NO_EXPORT;

                    next policy;

                }

            }

            term backup-route {

                from community type_customer_backup_route;

                then {

                    local-preference 800;

                }

            }

            term full-backup-route {

                from community type_full_backup_route;

                then {

                    local-preference 100;

                }

            }

        }

        policy-statement RT-aggregate {

            term match-RT-aggregate-networks {

                from {

                    route-filter 87.226.128.0/17 exact accept;

                    route-filter 79.133.64.0/19 exact accept;

                    route-filter 92.50.192.0/18 exact accept;

                    route-filter 94.25.0.0/17 exact accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement RT-longer-prefixes {

            term match-RT-longer-prefixes {

                from {

                    route-filter 87.226.128.0/17 longer accept;

                    route-filter 79.133.64.0/19 longer accept;

                    route-filter 92.50.192.0/18 longer accept;

                    route-filter 94.25.0.0/17 longer accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_CUSTOMER_in {

            term reject-RT-v6-aggregate {

                from policy RT-v6-aggregate;

                then reject;

            }

            term reject-RT-v6-longer-prefixes {

                from policy RT-v6-longer-prefixes;

                then reject;

            }

            term reject-default-route {

                from {

                    route-filter ::/0 exact;

                }

                then reject;

            }

            term remove-12389-communities {

                then {

                    community delete 12389:1-3X;

                    community delete 12389:1UZZ;

                }

            }

            term remove-Well-Known-communities

                then {

                    community delete WellKnown0;

                    community delete WellKnown65535;

                }

            }

            term set-parameters {

                then {

                    metric 0;

                    local-preference 850;

                    community add type_Customer;

                }

            }

            term blackhole-route {

                from community type_blackhole_route;

                then { 

                    next-hop discard;

                    community add NO_EXPORT;

                    next policy;

                }      

            }   

            term backup-route {

                from community type_customer_backup_route;

                then {

                    local-preference 800;

                }

            }

            term full-backup-route {

                from community type_full_backup_route;

                then {

                    local-preference 100;

                }

            }

        }

        policy-statement RT-v6-aggregate {

            term match-RT-v6-aggregate-networks {

                from {

                    route-filter 2A01:620::/32 exact accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement RT-v6-longer-prefixes {

            term match-RT-v6-longer-prefixes {

                from {

                    route-filter 2A01:620::/32 longer accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement mark-routes-sib {

            term 1 {

                then {

                    community add routes-SIB;

                    next policy;

                }

            }

        }

        policy-statement mark-region-routes-NVSK {

            term 1 {

                then {

                    community add routes-region-NVSK;

                    next policy;

                }

            }

        }

        community 12389:1-3X members «^12389:.{1,3}$»;

        community 12389:1UZZ members «^12389:1…$»;

        community type_Customer members 12389:1;

        community type_Upstream members 12389:6;

        community type_blackhole_route members 12389:55555;

        community type_customer_backup_route members 12389:2800;

        community type_full_backup_route members 12389:2100;

        community NO_EXPORT members no-export;

        community WellKnown0 members ^0:*;

        community WellKnown65535 members 65535:*;

        community routes-SIB members «12389:1101$»;

        community routes-region-NVSK members 12389:1254;

    }

          Для корректной реализации пиринговой политики в сети при приёме маршрутов от клиентов на сервисных маршрутизаторах BPE устанавливается значение Local Pereference, равное 950. Для сервисных маршрутизаторов Juniper вместо политики INET_CUSTOMER_in можно использовать политику INET_BPE_CUSTOMER_in, пример которой приведён далее.

          Пример политики INET_BPE_CUSTOMER_in:

    policy-options {

        policy-statement INET_BPE_CUSTOMER_in {

            term reject-RT-aggregate {

                from policy RT-aggregate;

                then reject;

            }

            term reject-RT-longer-prefixes {

                from policy RT-longer-prefixes;

                then reject;

            }

            term reject-default-route {

                from {

                    route-filter 0.0.0.0/0 exact;

                }

                then reject;

            }

            term remove-12389-communities {

                then {

                    community delete 12389:1-3X;

                    community delete 12389:1UZZ;

                }

            term remove-Well-Known-communities

                then {

                    community delete WellKnown0;

                    community delete WellKnown65535;

                }

            }

            term set-parameters {

                then {

                    metric 0;

                    local-preference 950;

                    community add type_Customer;

                }

            }

            term blackhole-route {

                from community type_blackhole_route;

                then {

                    next-hop discard;

                    community add NO_EXPORT;

                    next policy;

                }

            }

            term backup-route {

                from community type_customer_backup_route;

                then {

                    local-preference 800;

                }

            }

            term full-backup-route {

                from community type_full_backup_route;

                then {

                    local-preference 100;

                }

            }

        }

        policy-statement RT-aggregate {

            term match-RT-aggregate-networks {

                from {

                    route-filter 87.226.128.0/17 exact accept;

                    route-filter 79.133.64.0/19 exact accept;

                    route-filter 92.50.192.0/18 exact accept;

                    route-filter 94.25.0.0/17 exact accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement RT-longer-prefixes {

            term match-RT-longer-prefixes {

                from {

                    route-filter 87.226.128.0/17 longer accept;

                    route-filter 79.133.64.0/19 longer accept;

                    route-filter 92.50.192.0/18 longer accept;

                    route-filter 94.25.0.0/17 longer accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_BPE_CUSTOMER_in {

            term reject-RT-v6-aggregate {

                from policy RT-v6-aggregate;

                then reject;

            }

            term reject-RT-v6-longer-prefixes {

                from policy RT-v6-longer-prefixes;

                then reject;

            }

            term reject-default-route {

                from {

                    route-filter ::/0 exact;

                }

                then reject;

            }

            term remove-12389-communities {

                then {

                    community delete 12389:1-3X;

                    community delete 12389:1UZZ;

                }

            }

            term remove-Well-Known-communities

                then {

                    community delete WellKnown0;

                    community delete WellKnown65535;

                }

            }

            term set-parameters {

                then {

                    metric 0;

                    local-preference 950;

                    community add type_Customer;

                }

            }

            term blackhole-route {

                from community type_blackhole_route;

                then { 

                    next-hop discard;

                    community add NO_EXPORT;

                    next policy;

                }      

            }   

            term backup-route {

                from community type_customer_backup_route;

                then {

                    local-preference 800;

                }

            }

            term full-backup-route {

                from community type_full_backup_route;

                then {

                    local-preference 100;

                }

            }

        }

        policy-statement RT-v6-aggregate {

            term match-RT-v6-aggregate-networks {

                from {

                    route-filter 2A01:620::/32 exact accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement RT-v6-longer-prefixes {

            term match-RT-v6-longer-prefixes {

                from {

                    route-filter 2A01:620::/32 longer accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        community 12389:1-3X members «^12389:.{1,3}$»;

        community 12389:1UZZ members «^12389:1…$»;

        community type_Customer members 12389:1;

        community type_Upstream members 12389:6;

        community type_blackhole_route members 12389:55555;

        community type_customer_backup_route members 12389:2800;

        community type_full_backup_route members 12389:2100;

        community NO_EXPORT members no-export;

        community WellKnown0 members ^0:*;

        community WellKnown65535 members 65535:*;

    }

          В сети ПАО «Ростелеком» для защиты от некорректных маршрутов применяется фильтрация на основе информации Routing Arbiter Database (раздел «Принципы защиты оборудования регионального уровня»). Для формирования имени фильтра используется форма CUSTOMER:<ASN>, где <ASN> – номер автономной системы клиента или название AS-SET, AS-NUM или AUT-NUM, зарегистрированные в RIR. Такой фильтр добавляется в настройки после фильтра INET_CUSTOMER_in (или INET_BPE_CUSTOMER_in).

          Пример дополнительного фильтра при приёме маршрутов от клиента:

    protocols {

        bgp {

            group INET_Customers {

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    import CUSTOMER:65432;

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement CUSTOMER:65432 {

            term rtbh {

                from {

                    community type_blackhole_route;

                    route-filter 2.1.0.0/16 orlonger;

                    route-filter 1.2.3.0/24 orlonger;

                }

                then {

                    community add NO_EXPORT;

                    next-hop discard;

                    accept;        

                }

            }

            term prefixes {

                from {

                    route-filter 2.1.0.0/16 upto /24;

                    route-filter 1.2.3.0/24 exact;

                }

                then next policy;

            }

            then reject;

        }

        community NO_EXPORT members no-export;

        community type_blackhole_route members 12389:55555;

    }

          При передаче префиксов клиенту передаются в зависимости от типа клиента:

    • агрегированные префиксы Ростелеком и маршрут по умолчанию;
    • только агрегированные префиксы Ростелеком;
    • только маршрут по умолчанию;
    • все префиксы от апстримов и агрегированные префиксы Ростелеком;

          BGP Community Ростелеком удаляются, за исключением 12389:X.

          Пример политики анонсирования маршрутов клиенту для маршрутизаторов Juniper:

    protocols {

        bgp {

            group INET_Customers {

                type external;

                neighbor 1.1.1.2 {

                    description «### Test Client ###»;

                    local-address  1.1.1.1;

                    export [ sanity-check INET_CUSTOMER_RT_and_default_out remove-communities ];

                    peer-as 65432;

                }

            }

            group INET_v6_Customers {

                type external;

                family inet6 {

                    unicast;

                }

                neighbor 1::2 {

                    description «### Test Client ###»;

                    local-address 1::1;

                    export [ v6-sanity-check INET_v6_CUSTOMER_RT_and_default_out remove-communities ];

                    peer-as 65432;

                }

            }

        }

    }

    policy-options {

        policy-statement sanity-check {

            term reject-bogons {

                from policy bogons;

                then reject;

            }

            term accept-blackhole {

                from community type_blackhole_route;

                then next policy;

            }

            term reject-long-prefixes {

                from {

                    route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;

                }

            }

        }

        policy-statement bogons {

            term rfc6890 {

                from {

                    route-filter 10.0.0.0/8 orlonger accept;

                    route-filter 172.16.0.0/12 orlonger accept;

                    route-filter 192.168.0.0/16 orlonger accept;

                    route-filter 0.0.0.0/1 through 0.0.0.0/32 accept;

                    route-filter 0.0.0.0/8 orlonger accept;

                    route-filter 100.64.0.0/10 orlonger accept;           

                    route-filter 127.0.0.0/8 orlonger accept;

                    route-filter 192.0.0.0/24 orlonger accept;

                    route-filter 192.0.2.0/24 orlonger accept;

                    route-filter 169.254.0.0/16 orlonger accept;

                    route-filter 192.88.99.0/24 orlonger accept;

                    route-filter 224.0.0.0/4 orlonger accept;

                    route-filter 240.0.0.0/4 orlonger accept;

                    route-filter 198.18.0.0/15 orlonger accept;

                    route-filter 198.51.100.0/24 orlonger accept;

                    route-filter 203.0.113.0/24 orlonger accept;           

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement v6-sanity-check {

            term reject-bogons {

                from policy v6-bogons;

                then reject;

            }

            term reject-long-prefixes {

                from {

                    route-filter ::/0 prefix-length-range /48-/128 reject;

                }

            }

        }

        policy-statement v6-bogons {

            term rfc6890 {

                from {

                    route-filter ::/128 exact accept;

                    route-filter ::1/128 exact accept;

                    route-filter ::/1 through ::/128 accept;

                    route-filter ::ffff:0:0/96 orlonger accept;

                    route-filter 100::/64 orlonger accept;           

                    route-filter 2001::/23 orlonger accept;

                    route-filter 2001:2::/48 orlonger accept;           

                    route-filter 2001:DB8::/32 orlonger accept;

                    route-filter 2001:10::/28 orlonger accept; 

                    route-filter 2002::/16 orlonger accept;

                    route-filter 64:ff9b::/32 orlonger accept;

                    route-filter FC00::/7 orlonger accept;

                    route-filter FE80::/10 orlonger accept;

                    route-filter FEC0::/10 orlonger accept;

                    route-filter FF00::/8 orlonger accept;

                 }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_CUSTOMER_RT_and_default_out {

            term accept-RT-v6-aggregate {

                from policy RT-v6-aggregate;

                then next policy;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term remote-static-tag_1002 {

                from {

                    protocol bgp;

                    community from_static_tag_1002;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term accept-default-route {

                from {

                    route-filter ::/0 exact;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_CUSTOMER_RT_only_out {

            term accept-RT-v6-aggregate {

                from policy RT-v6-aggregate;

                then next policy;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term remote-static-tag_1002 {

                from {

                    protocol bgp;

                    community from_static_tag_1002;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_CUSTOMER_default_out {

            term accept-default-route {

                from {

                    route-filter ::/0 exact;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_v6_CUSTOMER_full_out {

            term reject-RT-longer-prefixes {

                from policy RT-v6-longer-prefixes;

                then reject;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term accept-routes {

                from { 

                    protocol bgp;

                    community [ to_INET_Customer from_FED_Peer type_REG_Peer type_MRF_Peer ];

                }

                then next policy;

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement RT-v6-aggregate {

            term match-RT-v6-aggregate-networks {

                from {

                    route-filter 2A01:620::/32 exact accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement RT-v6-longer-prefixes {

            term match-RT-v6-longer-prefixes {

                from {

                    route-filter 2A01:620::/32 longer accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_CUSTOMER_RT_and_default_out {

            term accept-RT-aggregate {

                from policy RT-aggregate;

                then next policy;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term remote-static-tag_1002 {

                from {

                    protocol bgp;

                    community from_static_tag_1002;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term accept-default-route {

                from {

                    route-filter 0.0.0.0/0 exact;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_CUSTOMER_RT_only_out {

            term accept-RT-aggregate {

                from policy RT-aggregate;

                then next policy;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term remote-static-tag_1002 {

                from {

                    protocol bgp;

                    community from_static_tag_1002;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_CUSTOMER_default_out {

            term accept-default-route {

                from {

                    route-filter 0.0.0.0/0 exact;

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement INET_CUSTOMER_full_out {

            term reject-RT-longer-prefixes {

                from policy RT-longer-prefixes;

                then reject;

            }

            term static-tag_1002 {

                from {

                    protocol [ static aggregate ];

                    tag [ 1002 1003 1031 1032 ];

                }

                then {

                    metric 0;

                    accept;

                }

            }

            term accept-routes {

                from {

                    protocol bgp;

                    community [ to_INET_Customer from_FED_Peer type_REG_Peer type_MRF_Peer ];

                }

                then next policy;

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement remove-communities {

            term Clients {

                from community 12389:1X;

                then {

                    community delete 12389:2-5X;

                    next policy;

                }

            }

            term Community_12389 {

                from community 12389;

                then {

                    community delete 12389;

                }

            }

        }

        policy-statement RT-aggregate {

            term match-RT-aggregate-networks {

                from {

                    route-filter 87.226.128.0/17 exact accept;

                    route-filter 79.133.64.0/19 exact accept;

                    route-filter 92.50.192.0/18 exact accept;

                    route-filter 94.25.0.0/17 exact accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        policy-statement RT-longer-prefixes {

            term match-RT-longer-prefixes {

                from {

                    route-filter 87.226.128.0/17 longer accept;

                    route-filter 79.133.64.0/19 longer accept;

                    route-filter 92.50.192.0/18 longer accept;

                    route-filter 94.25.0.0/17 longer accept;

                }

            }

            term reject-others {

                then reject;

            }

        }

        community 12389 members 12389:*;

        community to_Upstream members «^12389:1$»;

        community 12389:1X members «^12389:.$»;

        community 12389:2-5X members «^12389:.{2,5}$»;

        community to_INET_Customer members «^12389:[16]$»;

        community from_FED_Peer members «^12389:[57]$»;

        community type_REG_Peer members 12389:9;

        community type_MRF_Peer members 12389:8;

        community from_static_tag_1002 members «12389:1 12389:4»;

    }

          В ряде случаев необходимо передавать маршрут по умолчанию клиентам, которым передаётся полная таблица маршрутизации. В этом случае вместе с политиками INET_CUSTOMER_full_out и INET_v6_CUSTOMER_full_out применяются политики announce-default и announce-v6-default соответственно.

    Обработка маршрутов при подключении клиентов Internet

          Пример политики анонсирования маршрута по умолчанию:

    policy-options {
        policy-statement {
            announce-default {
                term accept-default-route {
                    from {
                        route-filter 0.0.0.0/0 exact;
                    }
                    then {
                        metric 0;
                        accept;
                   }
                }
        }
            announce-v6-default {
                term accept-default-route {
                    from {
                        route-filter ::/0 exact;
                    }
                    then {
                        metric 0;
                        accept;
                   }
                }
        }
    }
    }

          При подключении некоторых клиентов может потребоваться передача им community, описывающих источник маршрута (номер upstream или peer: 12389:15ZZ, 12389:16ZZ и 12389:17ZZ. 

    В этом случае вместо policy-statement remove-communities применяется policy-statement remove-communities-except-sources.

          Пример политики анонсирования маршрутов клиенту для маршрутизаторов Juniper:

    policy-options {   

        policy-statement remove-communities-except-sources {

            term Delete_Community_12389 {

                then community delete 12389_Except_1X_and_Sources;

            }

        }

        community 12389_Except_1X_and_Sources {

            invert-match;

            members «^12389:((.)|(1[567]..))$»;

        }

    }

  • Download Cisco Works • Cisco Prime LAN Management Solution 4.1

    Download Cisco Works • Cisco Prime LAN Management Solution 4.1

    Cisco Prime LAN Management Solution (LMS) delivers powerful network security management by simplifying the configuration, administration, monitoring, and troubleshooting of Cisco networks. 

    Cisco Prime 4.1

    This innovative solution offers end-to-end security management for business critical technologies and services, such as, medianet, TrustSec, and EnergyWise. Cisco Prime LMS 4.1 improves the overall user experience, providing new workflows that are built on functional partitioning and that align the product with the way network operators do their jobs.

    Once installed, prepackaged security and troubleshooting dashboards provide actionable information to quickly isolate and fix network problems before they affect services.

    Configuring and deploying updates to the network has never been easier with the Template Center, which now incorporates Cisco Smart Business Architecture (SBA) templates that are based upon Cisco Validated Designs, simplifying platform and technology rollout and reducing the chance for errors.

    Work Centers provide a single area where guided workflows give step-by-step instructions to help operators quickly provision, monitor, and manage new Cisco value-added technologies and solutions, such as medianet, EnergyWise, TrustSec/Identity, Auto Smartports, and Smart Install.

    Download Cisco Prime 4.1 
  • Cyber war with Russia heating up

    Cyber war with Russia heating up

    If you think the crisis in the Ukraine is limited just to being on the ground, think again. A cyberwar is flaring up between Ukraine and Russia and it looks like this is only the beginning.

    The first blow came on 28 February when a group of unidentified men took control of several communications centres in Crimea, which are maintained by Ukraine’s telecom provider Ukrtelecom JSC. They wrecked cables and knocked out almost all landline, mobile and internet services in the region.

    Cyber War with Russia map

    It is now believed that the communications centres were attacked so that wireless equipment could be illegally installed in order to spy on the mobile phones of Ukrainian MPs.

    «I confirm that an IP-telephonic attack is under way on mobile phones of members of Ukrainian parliament for the second day in row,» Valentyn Nalivaichenko, the head of SBU, Ukraine’s’ security service, said.

    «At the entrance to [telecoms firm] Ukrtelecom in Crimea, illegally and in violation of all commercial contracts, was installed equipment that blocks my phone as well as the phones of other deputies, regardless of their political affiliation,» he said.

    Ukrainian hackers or sympathisers have been getting busy themselves, hacking the website of Russian state-funded news channel RT on Sunday and changing all references to «Russia» and «Russians» in headlines to «Nazi» and «Nazis». The attack lasted only 20 minutes and the RT was quick to respond.

    A group of hackers in Ukraine who call themselves «Cyber-Berkut» have boasted about defacing at least 40 Russian news websites on their Facebook page with the image above, which shows a Nazi Swastika over Crimea.

    A post on the page (translated from Russian) warns: «Today, the «KiberBerkut» countdown begins. Traitors of Ukraine who have transgressed the laws of our homeland, you have nine days to voluntarily surrender to the prosecuting authorities or the Kharkov Simferopol.»

    The post states that the «imposters», presumably the Russians, «have no right» to control Ukraine and must surrender to Ukraine.

    Censoring pro-Ukraine content

    On the Russian social network Vkontakte, 13 community groups set up in support of the new interim government in Kiev have had access to Russian IP addresses blocked. According to Moscow-based news website Lenta, a page appears when users try to access the groups, stating that the groups have been locked down by «the Russian Federation».

    A press spokesperson for Vkontakte said that the blocking lasted only a few minutes and was due to an error made by moderators but the Federal Service for the Supervision of Communications, known as the Roskomnadzor, said it would continue to block Ukrainian community groups and any other IP addresses that might be displaying «extremist content».

    While this is the extent of the cyber-attacks that we have learned of so far, the worry is that Russia could expand its military activity to include distributed-denial-of-service (DDoS) attacks to bring down crucial Ukrainian servers, the way they have done during other conflicts.

    In April 2007, Russian hackers from Nashi, Vladimir Putin’s political youth movement, targeted the websites of Estonia’s parliament, banks, ministries, newspapers and broadcasters amid a diplomatic row with Russia.

    During the 2008 South Ossetia war with Georgia, DDoS attacks were used to bring down numerous South Ossetian, Georgian, and Azerbaijani organisations.

  • Google AdSense полностью отключил монетизацию всем российским пользователям

    Сервис таргетированной рекламы Google AdSense полностью деактивировал аккаунты пользователей из России. «Это означает, что получать доход от монетизации блогов и YouTube через такие аккаунты на счета в российских банках будет нельзя», — говорится в заявлении компании. Там уточнили, что заработок пользователей за июль сервис выплатит между 21 и 26 августа.

    Ютуберы из России активно переезжают в другие страны на постсоветском пространстве

    Рекламный сервис Google AdSense деактивировал аккаунты пользователей из России, следует из рассылки компании пользователям. Скриншот письма опубликовал портал 3dnews. «Мы деактивируем все аккаунты AdSense, страной местоположения которых указана Россия. Это означает, что получать доход от монетизации через такие аккаунты будет нельзя», — говорится в сообщении. Заработок за июль сервис выплатит между 21 и 26 августа, если в аккаунте не приостановлено получение платежей и достигнуты пороги оплаты, уточнили там. Остаток по балансу российским пользователям Google планирует выплатить в течение 60 дней. 

    В марте 2022-го Google запретила продажи любой онлайн-рекламы в России «в свете чрезвычайных обстоятельств». До этого, в феврале того же года, Роскомнадзор потребовал от компании прекратить показывать рекламу, содержащую неточную информацию о ходе СВО на Украине. Позже он потребовал от Google прекратить показывать рекламу YouTube с «ложной политической информацией» об Украине, которая направлена на «дезинформацию российской аудитории». 

    В июле глава думского комитета по информационной политике Александр Хинштейн заявил, что скорость работы YouTube в России снизится сначала на 40%, а затем — на 70%. По его словам, эта мера направлена не против российских пользователей, «а против администрации иностранного ресурса, который по-прежнему считает, что может безнаказанно нарушать и игнорировать наше законодательство». Ухудшение качества загрузки видео на YouTube связано с действиями российских властей и является следствием того, что хостинг удаляет каналы российских журналистов, артистов и блогеров, пояснил он.

    До этого Роскомнадзор направил гендиректору Google Сундару Пичаи требование разблокировать более 200 YouTube-аккаунтов российских СМИ, органов власти и общественных деятелей. С 2020 года видеохостинг ограничил 207 российских ресурсов, при этом 83 из них — в 2024 году, отметили тогда в ведомстве. 

    Российские операторы, в том числе МТС и билайн, в конце июля начали предупреждать об ухудшении работы YouTube по независящим от них причинам. «Сейчас во многих регионах именно YouTube плохо работает, так как у них устарело оборудование», — заявили тогда в техподдержке билайна. В начале августа платформа DownRadar зафиксировала резкий рост жалоб российских пользователей на проблемы с доступом к YouTube. «Тут я ничего не могу сказать. В телефоне работает нормально, все грузится», — заявил на это пресс-секретарь президента Дмитрий Песков.

    Однако, после «замедления» YouTube 8 августа операторы связи отметили скачок общего объема трафика на 5-10%. В сетях региональных операторов он достигает и 20%. Они объясняют это использованием VPN для получения доступа к популярному видеосервису, а также активным копированием видео из YouTube на конкурирующие с ним российские ресурсы. Это грозит операторам, особенно региональным, дополнительными затратами на приобретение трафика у магистральных операторов, так как отечественные замены YouTube не имеют достаточно кеширующих серверов, особенно в регионах, поясняют операторы.

    Скачок трафика

    В пресс-службе крупнейшей российской точки обмена интернет-трафиком MSK-IX нам рассказали, что зафиксировали рост трафика за последнюю неделю на 5,6%, если сравнивать с обычными значениями, — до 3509 Гбит/с. В компании отметили, что мобильный трафик отдельно от общего не отслеживают. Генеральный директор оператора IT-решений «Обит» Андрей Гук оценил рост общего трафика российских операторов на 5-10% за последнюю неделю. 

    Напомним, что 8 августа в работе YouTube произошел масштабный «сбой», который длится до сих пор, хотя проблемы с доступом к видеосервису наблюдаются уже месяц. Российские власти, в том числе Роскомнадзор, поясняли ухудшение качества работы YouTube прекращением поддержки инфраструктуры кеширующих серверов Google в России. Хотя эксперты не сомневаются, что это дело рук Роскомнадзора, который блокирует видеосервис с помощью технических средств противодействия угрозам (ТСПУ), установленных на сетях всех российских операторов связи. В одном из своих постов глава комитета по информполитике Госдумы Александр Хинштейн туманно отмечал, что «деградация» YouTube — «вынужденный шаг, направленный не против российских пользователей, а против администрации иностранного ресурса». 

    Под инфраструктурой кеширующих серверов имеют в виду собственную CDN-сеть американской компании, так называемую Google Global Cache (GGC). Google развивает её во многих странах присутствия, в том числе и в России. Сервис позволяет загружать востребованный контент не с центрального сервера, который может быть расположен за тысячи километров, а с ближайшего сервера CDN (content delivery network, сеть распределенных по стране серверов, установленных на сетях операторов связи). В данный момент российская «дочка» Google в России проходит процедуру банкротства и CDN-сеть не поддерживает. Свои CDN-сети имеют и российские видеосервисы, например «VK Видео». 

    Поиск альтернатив 

    По словам президента ассоциации «Ростелесеть» Олега Грищенко, за последнюю неделю трафик в сетях российских региональных операторов вырос примерно на 10-20%. «Если говорить точнее, то, в целом, уровень трафика сохранился, но раньше его часть проходила через кеш-сервера и была во внутренней сети оператора. Теперь абоненты уходят искать информацию на внешние каналы связи, увеличивая закупаемый трафик», — пояснил он. 

    «Абоненты начинают больше искать нужную им информацию на альтернативных YouTube платформах. Однако наблюдается недостаток кеширующих серверов у отечественных видеоплатформ. Они поставили кеш-сервера у федеральных операторов, а у региональных провайдеров кеш-серверов установлено существенно меньше», — разъяснил Олег Грищенко. По его словам, операторы готовы к подобным скачкам с технической точки зрения. Но возрастают затраты на трафик, хотя пока рано судить, в какие суммы они выльются, добавил глава ассоциации «Ростелесеть».

    По данным «ТМТ Консалтинг» за I квартал этого года, первая пятерка федеральных провайдеров («Ростелеком», МТС, «ЭР-Телеком» (бренд «Дом.ру»), «Вымпелком» (бренд билайн) и ТТК) занимают 71%, еще 29% приходится на локальных игроков рынка. Президент ассоциации операторов кабельного телевидения «Макател» Алексей Амелькин рассказал, что, исходя из статистики одного из операторов, входящих в ассоциацию, за 5-11 августа трафик вырос на 5,5%, если сравнивать с неделей 22-27 июля. «Ростелеком», «Мегафон», МТС, «Вымпелком» и «ЭР-Телеком» отказались от комментариев. В пресс-службах Минцифры и ТТК не ответили на наш запрос. 

    Оди источник одного из крупных региональных операторов не зафиксировал аномального роста общего трафика, хотя и отмечает, что наблюдается увеличение трансграничного трафика. Очевидно, это результат более активного использования VPN-сервисов, пояснил он. При этом он отметил, что трафик YouTube с 1 августа просел примерно в полтора-два раза, а VK — вырос на треть в тот же день. «Можно наблюдать тенденцию перетока аудитории YouTube в «VK Видео», однако только части трафика», — сделал вывод он. В пресс-службе VK сообщили, что объем загрузок видеоконтента на сервис «VK Видео» за неделю с 5 по 11 августа вырос в 1,5 раза в сравнении со среднемесячными показателями июля. А количество авторов, впервые загрузивших видео на платформу, за эту же неделю увеличилось в 1,7 раза.

    YouTube на дисках

    Рост трафика может быть связан с тем, что ряд пользователей воспользовались опциями скачивания видео из YouTube на российские видеоплатформы, пояснил автор Telegram-канала abloud62 Алексей Бойко. Некоторые скачивают ценные для них видео и на жесткие диски, добавил он. Кто-то использует VPN-сервисы, чтобы получить доступ к YouTube, а такого рода шифрование формирует трафик повышенного объема, отметил эксперт. «Кроме того, десятки миллионов людей периодически пробуют получить доступ к сервису в обычном режиме, надеясь, что «замедления» наконец прекратили. Все это создает основания для роста трафика», — пояснил Бойко.

    Если ситуация с «замедлением» YouTube сохранится или ухудшится, то, по самым негативным прогнозам, от трафика видеосервиса останется не более 10%, которые будут ходить через VPN-сервисы. Это в свою очередь приведет к общему падению трафика в сетях операторов на 15-20%, рассказал наш источник в одном из крупных операторов связи, добавив, что нужно не меньше шести месяцев, чтобы увидеть картину целиком и понять последствия «замедления». Также, по его словам, многое будет зависеть от того, какие альтернативные YouTube видеосервисы смогут предложить российские ресурсы. «Если будет достойная замена YouTube, то трафик просто перераспределится в её пользу и месяцев через шесть про американский видеосервис забудут. Если достойной альтернативы не будет, нужно будет смотреть на трафик: он либо упадет, либо действительно перераспределится через VPN. Будет ли замещен чем-нибудь трафик YouTube, чем, как и когда, сейчас предсказать невозможно», — заключил он.

    Ну а сами ютуберы, ранее полуавшие вознаграждение на карты и счета в российских банках, дружной гурьбой ринулись в казахские и киргизские банки открывать себе новые счета и регистрировать новые учётные записи в сервисе Google AdSense с указанием страны платёжного профиля при регистрации, отличной от России. Для этих целей вполне подойдёт любая страна на постсоветском пространстве.