Tag: Транстелеком

  • Виртуальная сеть на платформе Cisco 7200

    Виртуальная сеть на платформе Cisco 7200

    После просмотра видеоуроков по курсу CCNA решил провести маленький эксперимент и собрать виртуальный DATA CENTER на своём ноутбуке. Для большей доступности и простоты не стал связываться с Cisco CSR 1000v Cloud Services Router, а ограничился эмулятором сетевых устройств Dynagen.  Топология простая, но в тоже время дает возможность протестировать много интересных вещей вплоть до Frame Relay Traffic shaping.

    Виртуальная сеть Cisco 7200 с выходом в интернет

    Итак, для сборки виртуального маршрутизатора Cisco с подключением его к реальной сети нам понадобится образ Cisco IOS, лучше взять какой-нибудь из серии 7200 подборки Cisco IOS, выберем от туда, например c7200-spservicesk9-mz.152-4.S.bin. Лучше всего его распаковать при помощи WinRAR перед использованием – меньше времени будет тратиться на запуск виртуальной машины.

    При первом запуске виртуальной машины Dynagen с Cisco IOS для её корректной работы необходимо получить значение задержки процессора для работы этой машины, для возьмём самую простую конфигурацию без подключения к сетевым ресурсам, этого вполне достаточно, чтобы получить значение idlepc для этой машины и выбранного вами образа Cisco IOS:

    # Cisco 7200 with 2 FE interfaces
    [localhost]

        [[7200]]
        image = C:Program FilesDynamipsimagesc7200-spservicesk9-mz.152-4.S.bin
        sparsemem = True
             
        [[ROUTER R1]]
        slot0 = C7200-IO-FE
        slot1 = PA-FE-TX

    Для того, чтобы Dynagen правильно посчитал значение idlepc нужно дождаться полной загрузки и запуска виртуальной машины с образом Cisco IOS. Для этого, прежде чем получать idlepc, нужно подключиться к виртуальной машине Cisco 7200 через консоль, и только дождавшись приглашения Router> следует выполнять команду idlepc get R1

    выполнить команду idlepc get R1

    Для подключения виртуальной машины Cisco к реальной сети, нужно узнать идентификаторы сетевых карт ноутбука, делается это очень просто запускаем ярлык «Network device list» и видим список наших сетевых карт с их идентификаторами (надеюсь, что необходимый для работы с реальной сетью драйвер WinPCAP вы уже установили):

    WinPCAP needed

    Копируем идентификаторы наших сетевых карт и прописываем их в конфигурационном файле Dynagen, в моем случае конфигурация виртуальной машины Cisco 7200 выглядит так:

    # Cisco 7200 with 2 FE interfaces
    [localhost]

        [[7200]]
        image = C:Program FilesDynamipsimagesc7200-spservicesk9-mz.152-4.S.bin
        idlepc =  0x60688d8c
        sparsemem = True
             
        [[ROUTER R1]]
        slot0 = C7200-IO-FE
        slot1 = PA-FE-TX
        cnfg = startup.cfg
        mac = 00:20:0C:1C:AB:EF
        F0/0 = NIO_gen_eth:DeviceNPF_{A0CCCD9D-7176-4294-91E9-AA05B740D2E8}
        F1/0 = NIO_gen_eth:DeviceNPF_{5465CB24-835B-44CA-B91E-2D1E12B4B35B}

    Как видно из файла конфигурации я ассоциировал Fast Ethernet адаптер моего ноутбука с интерфейсом fa1/0 маршрутизатора R1, это необходимо для подключения нашего DATA CENTER к внешнему миру, теперь можно начинать тестирование.

    Если у вас возникли вопросы по поводу конфигурации Dynagen то стоит прочесть Dynagen Tutorial или пообщаться со мной в ICQ.

    Попробуем теперь выйти в Интернет с виртуальной машины Cisco 7200:

    Router>trace ya.ru
    Translating “ya.ru”…domain server (8.8.8.8) [OK]

    Type escape sequence to abort.
    Tracing the route to ya.ru (213.180.193.3)
    VRF info: (vrf in name/id, vrf out name/id)
      1 192.168.4.100 16 msec 8 msec 8 msec
      2 192.168.0.100 12 msec 272 msec 8 msec
      3 10.0.0.1 12 msec 8 msec 8 msec
      4  *  *  *
      5  *  *  *
      6 10.63.176.34 [MPLS: Label 16432 Exp 0] 8 msec 116 msec 16 msec
      7 10.63.130.134 156 msec 204 msec *
      8 10.255.63.29 72 msec 128 msec 224 msec
      9 yota.ru (94.25.130.250) 132 msec
        ya.ru (213.180.193.3) 136 msec 156 msec
    Router>

    Как видим – все работает. Подключив мой любимый iPod touch через свободный интерфейс fa0/0 я имел возможность также легко читать любимые странички, слушать музыку и качать файлы со скоростью до 1 МБит/С.

    Кроме образа Cisсo IOS модели 7200 можно использовать образы 1710, 1720, 1721, 1750, 1751, 1760, 2610, 2611, 2620, 2621, 2610XM, 2611XM, 2620XM, 2621XM, 2650XM, 2651XM, 2691, 3725, 3745, 3620, 3640, 3660 моделей для создания виртуальной машины. Скажу честно, они более легкие и запускаются быстрее, однако самые новые версии IOS 15.0 и выше Cisco в настоящий момент выпускает только для модели 7200, потому как остальные перечисленые в этом списке, морально устарели.

    Думаю, что нашу задачу создать виртуальный DATA CENTER в домашних условиях  на простом ноутбуке можно считать выполненной.

  • Employing a BGP hijack against BitCoin miners

    Employing a BGP hijack against BitCoin miners

    A few days ago researchers at Dell SecureWorks published the details of an attacker repeatedly hijacking BGP prefixes for numerous large providers such as Amazon, OVH, Digital Ocean, LeaseWeb, Alibaba and more. The goal of the operation was to intercept data between Bitcoin miners and Bitcoin mining pools. They estimated that $83,000 was made with this attack in just four months. Let’s take a closer look at  the BGP details of this specific attack.

    BGP hijack details
    Our friends at Dell SecureWorks decided not to name the network from which the hijacks originated. As a result we won’t name the exact Autonomous System either, instead we will suffice by saying that the originator of this hijack is a network operating in Eastern Canada.

    BGP hijack against BitCoin market
    Initial experiment
    BGPmon detected the first BGP attack by this Canadian Autonomous System on October 8th 2013. For about 14 minutes a more specific /24 IP prefix for a Palestinian network was hijacked. Looking at geographical scope of the announcements and the probes that saw this route, we believe that in this case the route was only announced over the Toronto Internet Exchange.

    Bitcoin hijack
    On Feb 3rd 2014, the first targeted Bitcoin hijacks took place, this affected more specific prefixes for AS 16509 (Amazon). Starting Feb 4th the BGP attack appears to be originating from one of the downstream customers of the attacker. We believe this may have been an attempt to hide the actual Origin AS.

    As of February 6th the finger print changes slightly again and the same more specific announcement for Amazon now appears to be announced by Amazon directly; i.e. the most right AS in the AS path is the Amazon AS. Looking at the data we believe that part of the ASpath is spoofed and that Amazon did not actually announce this prefix, instead it was announced by the Canadian attacker who tried to hide itself using AS path prepending. 

    Interestingly this specific case looks a lot like the ‘stealing the Internet’ attack as presented at Defcon a few years ago, including ASpath poisoning where some of the attackers upstream providers were included in the spoofed part of the ASpath.

    We then observe a large gap between February 8th and March 22 where we don’t see any attacks involving this particular AS. On March the 22nd the BGP attacks return. In this case largely with the same fingerprint: mostly more specific (/24) announcements with the same spoofed ASpaths.
    Finally May 13, 2014 is the last day these BGP attacks have been observed and it’s been quiet since.

    Filters to limit the Scope and impact
    It appears that all the BGP announcements related to the Bitcoin hijack attacks were only visible via peers of this Canadian network via the Internet Exchange. This means that the attacker either did not announce these hijacked blocks to their transit providers, or the transit providers did a good job in filtering these announcements.

    Most network operators do not have prefix filters on BGP peering sessions at Internet Exchanges. Instead they often only have Max-Prefix filters in place. These Max-Prefix filters are intended to protect against large leaks, or a sudden increase in announced prefixes by these peers. In this scenario the BGP attacker would only announce a few new prefixes at any given time, this prevented Max-Prefix filters to trip.

    Collateral damage
    The BGP attacker appears to have known exactly what IP addresses are Bitcoin miners and as a result knew who to target. However, because many network operators filter out prefixes longer than a /24, the BGP attacker chose to announce a /24 in order to increase the chances of the prefix being accepted. This means that other machines in the same hijacked /24 prefix that have nothing to do with Bitcoin mining were also affected. Because of the nature of the providers affected, primarily cloud providers offering VM hosting (AWS, OVH, Digital Ocean, ServerStack, Choopa, LeaseWeb and more), it is not unlikely that traffic for machines (VMs) of hundreds of organizations worldwide may have been redirection to the BGP attacker.

    Not the first time
    This incident follows numerous similar BGP hijacks that happened recently. Just last year networks of several Credit Card companies were attacked

    Another example is the hijack of multiple Government departments of one specific European country. More recently Turkey hijacked the IP addresses of several well-known DNS providers

    These recent examples demonstrate that BGP attack is indeed being used for financial gain, Intelligence collection as well as Censorship.
  • Схемы работы на площадке процессинга с офшором

    Схемы работы на площадке процессинга с офшором

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

    Уклонение от уплаты налогов

    Использование офшорных юрисдикций — один из наиболее распространенных и вполне законных способов налоговой оптимизации. Другое дело, когда в налоговых декларациях намеренно не указывают уже полученную прибыль, которая, как правило, скрывается в заокеанских фондах. Существует множество различных способов выстраивания схем ухода от налогов с использованием «налоговых убежищ», но их объединяет одна общая черта — несоответствие документально оформленной информации фактической экономической деятельности.

    обнальные схемы Darkmoney

    Кейс: ненадлежащее трансфертное ценообразование


    Эта схема обычно используется компаниями, входящими в одну и ту же группу, но расположенными в разных странах. При выборе данного сценария товары компании А, которые в стандартном варианте должны быть проданы непосредственно компании В, вместо этого реализуются через офшорную компанию X.

    Компания A продает товары в пользу офшорной компании X по очень низким ценам, после чего компания X перепродает эти товары в пользу компании В по гораздо более высоким ценам.

    В результате компания X получает более высокую прибыль от своей торговой деятельности, тогда как компания B не получает практически никакой прибыли. Такая схема позволяет аккумулировать всю прибыль в офшорных налоговых убежищах, где не предусмотрена уплата налога на прибыль.

    К числу тревожных признаков, сигнализирующих о возможном уклонении от уплаты налогов в офшорах, относятся:

    — привлечение офшорных компаний в качестве сторон договора;
    — невозможность оценки и подтверждения стоимости услуг офшорных компаний;
    — отсутствие фактической хозяйственной деятельности в офшорных юрисдикциях;
    — нечеткое и неоднозначное описание услуг в документации;
    — ненадлежащее документальное сопровождение оказываемых услуг.

    Взяточничество и коррупция

    Офшоры позволяют скрыть связь между коррупционной стороной сделки и самой сделкой, что обеспечивает анонимность бенефициаров, скрывающихся под масками номинальных директоров, применять облегченный режим контроля при открытии банковских счетов (без проведения проверок типа AML KYC – «знай своего клиента»), а также переводить денежные средства без необходимости отвечать на неудобные вопросы.

    Кейс: денежные переводы коррупционного характера

    Международными нефтяными компаниями было создано крупное совместное предприятие (СП) для целей подачи заявки на участие в тендере на строительство завода по производству сжиженного природного газа (СПГ) в одной из африканских стран. Для получения от местного правительства данного заказа СП привлекло британского консультанта. Платежи, помеченные как оплата «маркетинговых услуг», поступали от португальской компании специального назначения, созданной СП, в пользу гибралтарской корпорации, учрежденной консультантом. Затем эти платежи переводились на банковские счета в Голландии, Монако и Швейцарии и, наконец, передавались африканским государственным служащим. С помощью ряда денежных переводов через офшоры СП и консультант попытались скрыть фактический характер платежей.

    Кейс: создание фонда для дачи взяток

    Компания по производству медицинского оборудования решила расширить свои каналы поставок в Азию. После нескольких неудачных попыток заключения договоров поставки компания привлекла стороннего агента для взаимодействия с крупными местными поставщиками, которые в основном находятся в государственной собственности. Сторонний агент был зарегистрирован в качестве компании на Британских Виргинских островах (BVI) и имел банковские счета на Кипре. Не будучи знакомым с деятельностью компании по производству медицинского оборудования, сторонний агент не имел достаточных знаний отраслевого характера и не обладал приемлемым профессиональным опытом для оказания договорных услуг. Посредством данной платежной схемы сторонний агент создал фонд для дачи взяток местным государственным служащим в обмен на заключение и сохранение в действии договоров поставки с государственными компаниями.

    К тревожным признакам потенциально коррупционной схемы можно отнести:

    — привлечение сторонних офшорных поставщиков услуг (например, маркетинговых агентов, представителей или посредников);
    — требования поставщика о внесении платежей на офшорные счета;
    — отсутствие послужного списка поставщика услуг;
    — слишком обобщенное описание оказываемых услуг;
    — отсутствие подтверждений фактического оказания услуг;
    — жестко зарегулированные операции (например, получение одобрений, лицензий, разрешений, сертификатов и таможенная очистка).

    Незаконная перевозка и торговля

    Наиболее распространенные схемы транспортировки товаров, сбыт которых осуществляется на нелегальном рынке (наркотики, оружие, произведения искусства, драгоценные камни и ювелирные изделия), предполагают привлечение офшорных компаний.

    Дилеры и посредники предпочитают оставаться инкогнито, поэтому требуют, чтобы подставные компании действовали от своего имени.

    Чтобы еще больше затруднить отслеживание подобных операций сотрудниками таможни или правоохранительных органов, сделки по продаже могут многократно проводиться между различными офшорными компаниями в различных юрисдикциях, прежде чем поставляемая продукция достигнет конечного заказчика.

    Кейс: алмазы из Южной Африки

    Сеть офшорных компаний активно применяла многоступенчатую схему секретного экспорта алмазов из Южной Африки. Центральным звеном схемы было частное воздушное судно, зарегистрированное на Бермудских островах и используемое в различных регионах мира. Базируясь в ЮАР, данное воздушное судно совершало полеты в Зимбабве, Сингапур, Гонконг, Танзанию, Анголу и перевозило VIP-пассажиров и незаконные грузы – алмазы, добываемые в зоне ведения боевых действий в Южной Африки. Офшорная регистрация самолета позволила выгодоприобретателям по данной схеме оставаться неузнанными на протяжении многих лет.

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

    Подозрения в незаконной перевозке и торговле должны вызывать:

    — привлечение офшорных компаний к совершению сделок купли-продажи;
    — отсутствие информации о конечных выгодоприобретателях по сделкам;
    — офшорная регистрация воздушных и морских судов для перевозки товаров;
    — отсутствие надлежащей документации по транспортируемым товарам, например, таможенной документации;
    — нестандартные условия совершения платежей (например, платежи из банков, расположенных в юрисдикциях с неоднозначным нормативно-правовым регулированием).

    Уклонение от уплаты таможенных платежей

    В целях таможенной очистки импортеры часто привлекают таможенных брокеров, которые пользуются услугами ассоциированных офшорных и фиктивных компаний. Как правило, офшорные компании используются в качестве номинальных продавцов в рамках сделок по импорту продукции и могут указываться на всех документах вместо настоящего продавца/производителя. На другой стороне такой сделки в качестве зарегистрированного импортера могут быть указаны фиктивные компании (вместо фактического заказчика). После завершения таможенной очистки эти фиктивные компании осуществляют сбыт продукции фактическому заказчику и вскоре ликвидируются.

    Кейс: таможенная очистка

    Крупный российский дистрибьютор осуществлял таможенную очистку импортных товаров с помощью фиктивных компаний («компаний-однодневок»), выступающих в качестве официального зарегистрированного импортера. Компанией-однодневкой был заключен фиктивный договор с компанией BVI, выполняющей функции продавца для таможенных целей. На счетах-фактурах, выставляемых компанией BVI, промышленное оборудование (насосы) было заведомо искажено и указано как потребительские товары (обувь) – эта мера потребовалась для снижения ставки таможенной пошлины. Компания BVI также переводила платежи в пользу производственной компании. Транспортировка товаров осуществлялась производственной компанией непосредственно в адрес дистрибьютора, тогда как все посреднические сделки были совершены исключительно с целью уклонения от уплаты таможенных пошлин.

    К числу тревожных признаков, указывающих на применение схем ухода от таможенных выплат, относятся следующие:

    — передача задач по таможенной очистке на аутсорсинг малоизвестным таможенным брокерам;
    — включение офшорных посредников в цепочку поставок;
    — участие офшорных посредников в совершении расчетов;
    — отсутствие однозначной коммерческой цели привлечения офшорных посредников;
    — недостаточность документации (например, таможенных деклараций).

  • Обработка 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]..))$”;

        }

    }