Author: Nikolay Pleshakov

  • Виртуальная сеть на платформе 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 в домашних условиях  на простом ноутбуке можно считать выполненной.

  • Sự khác biệt giữa rò rỉ tuyến BGP và tấn công chiếm quyền điều khiển tuyến BGP là gì?

    Sự khác biệt giữa rò rỉ tuyến BGP và tấn công chiếm quyền điều khiển tuyến BGP là gì?

    Một trong những tính năng chính của dịch vụ giám sát và phân tích BGP là theo dõi các bất thường cụ thể có thể dẫn đến sự cố mà chúng ta gọi là rò rỉ tuyến BGP hoặc chiếm quyền điều khiển BGP.

    Cả hai đều chuyển hướng lưu lượng truy cập đến bên thứ ba, so với trạng thái không có bất thường, nhưng theo cách khác nhau. Trong vài năm qua, rất nhiều nỗ lực đã được đầu tư vào việc giải quyết những vấn đề này, nhưng vẫn còn những hiểu lầm về bản chất của từng vấn đề và cách các công cụ khác nhau giúp giải quyết các vấn đề khác nhau.

    Chúng tôi bắt đầu thu thập mô hình mối quan hệ BGP vài năm trước khi RFC 7908 xuất hiện, cố gắng định nghĩa rò rỉ tuyến BGP là gì. Hai điểm khác biệt chính giữa hai thời điểm đó được mô tả như sau:

    • Các tuyến được chuyển hướng qua các ASN/liên kết sai (Rò rỉ tuyến), được mô tả là loại 1-4 trong RFC 7908
    • Các tuyến được chuyển hướng đến các ASN sai (Chiếm đoạt), được mô tả là loại 5 và 6 trong RFC 7908

    Trong trường hợp rò rỉ tuyến BGP, lưu lượng truy cập hướng đến mạng của bạn rất có thể sẽ chảy một cách không hiệu quả, dẫn đến tăng độ trễ mạng và mất gói tin. Tuy nhiên, nó vẫn sẽ đến được mạng của bạn gần như chắc chắn nếu không có tắc nghẽn mạng nghiêm trọng vì lý do nào đó (như ý đồ xấu của kẻ gây hại). Trong trường hợp chiếm quyền kiểm soát tuyến BGP, lưu lượng truy cập hướng đến mạng của bạn bị chuyển hướng đến bên thứ ba và ở lại đó. Hơn nữa, cơ chế tạo ra các loại bất thường này cũng khác nhau. Để tạo ra rò rỉ tuyến, bạn cần chuyển một tuyến đường tốt đến một nhà cung cấp dịch vụ Internet (ISP) lân cận không phù hợp. Để tạo ra chiếm quyền kiểm soát, bạn cần thông báo một tuyến đường với tiền tố phụ/cụ thể hơn của một tiền tố hợp lệ (để thu hút tất cả lưu lượng truy cập từ các ISP đã nhận được thông báo đó với bất kỳ AS_PATH nào bạn muốn) hoặc tạo một thông báo tuyến đường với tiền tố của bên thứ ba từ mạng của bạn. Vì cơ chế tạo ra các bất thường định tuyến khác nhau, nên cơ chế phát hiện sự cố và phòng ngừa/giảm thiểu cũng cần khác nhau.

    Để phát hiện nguyên nhân rò rỉ tuyến đường, bạn cần tìm hiểu mối quan hệ giữa hai nhà mạng được kết nối và tìm ra các tuyến BGP (từ bộ thu thập BGP) vi phạm mô hình chính thức Gao-Rexford; để biết thêm thông tin, vui lòng tham khảo tài liệu “Mối quan hệ AS” của CAIDA. Để phát hiện các vụ chiếm đoạt tuyến đường, bạn cần có thông tin chính xác về việc tiền tố nào thuộc về nhà cung cấp dịch vụ Internet (ISP) nào, và trong hầu hết các trường hợp, khi xuất hiện một cặp ISP có tiền tố chưa được đăng ký – hãy tạo cảnh báo hoặc thực hiện hành động.

    Để ngăn chặn/giảm thiểu các vụ chiếm đoạt tuyến đường, có hai phương pháp tiêu chuẩn trong khuôn khổ Xác thực Nguồn gốc Tiền tố (Prefix Origin Validation – ROA) duy nhất. Bạn có thể đăng ký một đối tượng Tuyến đường (Route) trong IRR của mình hoặc tạo một đối tượng ROA. Nhóm của chúng tôi đã mô tả sự khác biệt giữa các phương pháp này trong RIPE79. Tuy nhiên, điểm chung là cả hai đều nêu rõ tiền tố nào thuộc về nhà mạng nào (do chính các nhà mạng cung cấp) và cố gắng chặn các tuyến đường từ một ISP có tiền tố chưa được đăng ký (do các ISP trung chuyển). Để ngăn chặn/giảm thiểu rò rỉ tuyến đường thuần túy, chúng tôi tham gia vào việc tạo ra một chính sách mở BGP. Một cách tiếp cận khác là khóa ngang hàng – chặn các tuyến đường có các láng giềng/ISP không mong muốn trong AS_PATH. Bản dự thảo ASPA IETF hơi khác so với việc ngăn chặn chiếm đoạt/rò rỉ tuyến đường thuần túy vì nó tập trung hơn vào việc chặn các AS_PATH xấu (các trường hợp rò rỉ tuyến đường và chiếm đoạt có/không có thao tác AS_PATH xấu).

    ROA so với rò rỉ định tuyến

    Vậy, mạng của bạn có an toàn không nếu bạn triển khai cả chữ ký ROA và lọc ROA? Không, bởi vì nếu không có ASPA hoặc bất kỳ giao thức tương đương nào, bản thân ROA sẽ không ngăn chặn được việc rò rỉ định tuyến từ bên ngoài. Chúng tôi hy vọng rằng giờ đây bạn đã thấy vấn đề này phức tạp như thế nào, cần có các phương pháp riêng biệt để bảo mật nền tảng của định tuyến liên miền hiện đại – Giao thức Cổng Biên (Border Gateway Protocol).

    Chữ ký ROA so với lọc ROA

    Một quan niệm sai lầm phổ biến khác liên quan đến ROA. Có hai bên trong thuật toán ROA: bên ký – nhà điều hành, cung cấp thông tin xác thực về các tiền tố mà họ sở hữu; và có một bên lọc – nhà điều hành trung chuyển, lọc ra các tuyến đường xấu dựa trên thông tin do bên ký cung cấp.

    Là một nhà điều hành nhánh (nghĩa là một AS chỉ có một nhà cung cấp đường lên), bạn bị hạn chế về số lượng cách bạn có thể tác động đến số lượng các bên lọc. Càng nhiều bên lọc, tiền tố của bạn càng an toàn hơn (càng ít vùng bị ảnh hưởng nếu kẻ tấn công quyết định tấn công tiền tố của bạn). Nếu bạn quyết định ký tiền tố của mình, bạn có thể sử dụng cơ sở hạ tầng lọc hiện có, và cơ sở hạ tầng này sẽ chỉ phát triển hơn nữa trong tương lai gần. Hơn nữa, chúng tôi khuyến khích bạn vẫn nên làm như vậy, bất kể quy mô mạng lưới phía sau ASN của bạn lớn đến đâu.

    Bài viết này vẫn sẽ kết thúc bằng một lời cảnh báo: cơ sở hạ tầng lọc hiện tại vẫn có thể chưa hoàn hảo, và trong một số trường hợp, bạn không thể chuyển hướng lưu lượng truy cập từ khu vực bị ảnh hưởng do tùy chọn độ dài tối đa đã chọn và việc lọc ROA ở phía nhà cung cấp dịch vụ Internet của bạn.

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

        }

    }

  • Как отозвать платеж при помощи МТ192 SWIFT message

    Как отозвать платеж при помощи МТ192 SWIFT message

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

    Возвращать средства после МТ192 никто не будет, пока сам клиент не даст на то распоряжение, а распоряжения такого как вы понимаете может и не поступить. Блокировать средства на счете клиента на основании МТ192 ни один банк тоже не может.

    Обычно клиент сам распоряжается полученной суммой и банк дает ответ МТ196 банку плательщика, о том что отзыв по МТ192 противоречит условиям экспортного контракта…