Bộ lọc lỗ đen kích hoạt từ xa (RTBH) của BGP cho Juniper

Tôi đang cố gắng tìm cách thanh lịch nhất để triển khai bộ lọc RTBH cho các tuyến nhận được từ khách hàng.

Bộ lọc nên:

1. Chỉ chấp nhận tiền tố của khách hàng từ danh sách tiền tố
2. Chỉ chấp nhận / 32 tiền tố
3. Chỉ các tiền tố với cộng đồng hố đen
4. Đặt hop kế tiếp thành RTBH next-hop (192.0.2.1)

Để bắt đầu, tôi đã xem tài liệu " Định cấu hình điều kiện đối sánh trong Điều khoản chính sách định tuyến " từ Juniper.

Đầu tiên tôi nghĩ đến việc kết hợp một prefix-list-filtertuyến chỉ khớp với danh sách tiền tố của khách hàng và route-filterđể giới hạn các tiền tố được chấp nhận thành / 32, như vậy:

from {
    as-path customer;
    community blackhole;
    prefix-list-filter customer-prefixes orlonger;
    route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}

Nhưng sau đó tôi vấp phải thông tin này trong tài liệu:

Nếu bạn định cấu hình chính sách bao gồm một số kết hợp bộ lọc tuyến đường, danh sách tiền tố và bộ lọc địa chỉ nguồn, chúng được đánh giá theo thao tác HOẶC logic hoặc tra cứu kết hợp tuyến đường dài nhất.

Như tôi đã hiểu được điều này (và tôi tìm thấy nó một chút không rõ ràng), nếu tôi sử dụng prefix-list-filter, route-filtervà / hoặc source-address-filtertrong cùng hạn nó sẽ được đánh giá với một lâu nhất trận đấu OR giữa tất cả trong số họ, mà làm cho phương pháp này không sử dụng được .

Những gì tôi đã đưa ra là đây là bộ lọc sau đây. Các hostroutes-onlyhạn chuyển hướng tất cả tiền tố ngắn hơn / 32 với chính sách tiếp theo. Sau đó, prefixesthuật ngữ này phù hợp nếu / 32 nằm trong phạm vi của khách hàng, khớp với đường dẫn của anh ta và có cộng đồng lỗ đen được đặt:

term hostroutes-only {
    from {
        route-filter 0.0.0.0/0 prefix-length-range /0-/31;
    }
    then next policy;
}
term prefixes {
    from {
        as-path customer;
        community blackhole;
        prefix-list-filter customer-prefixes orlonger;
    }
    then {
        next-hop 192.0.2.1;
        accept;
    }
}

Vì vậy, đây có phải là cách thanh lịch nhất để xử lý này? Bất kỳ giải pháp nào khác?

Không có lý do gì để giới hạn khách hàng chỉ lỗ đen / 32, cho phép họ lỗ đen bất cứ thứ gì từ họ.

Một cái gì đó như thế này:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

Hãy nhớ đặt 'accept-remote-nexthop' trong cài đặt BGP, để hop kế tiếp có thể được thay đổi thành một thứ khác ngoài địa chỉ liên kết.

Tôi cũng ủng hộ mạnh mẽ rằng các nhà cung cấp bắt đầu hỗ trợ các cộng đồng lỗ đen khác nhau chứ không chỉ là 'lỗ đen đầy đủ'. Đặc biệt, nếu bạn hoạt động ở nhiều quốc gia, thường tấn công là do quá cảnh và thường khách hàng thực sự muốn truy cập các đồng nghiệp trong nước, do đó, rất hữu ích khi thực hiện một số cấp độ của lỗ đen:

1. Đầy
2. Bên ngoài quốc gia (IXP địa phương, toàn bộ khách hàng AS + đã thấy)
3. Bên ngoài khu vực địa phương (nếu có thể, như đối với tôi, đó có thể là 'Nordics')
4. Bao gồm / Loại trừ bộ định tuyến tiên phong cụ thể trong lỗ đen

Tôi rất vui khi đưa ra ví dụ về cách triển khai một cái gì đó như thế này với JNPR DCU / SCU, với điều kiện các bộ định tuyến tiên phong của bạn là JNPR, nhưng chỉ với cộng đồng, có thể khó xử hơn một chút.

Nếu bạn hoàn toàn muốn giới hạn các tùy chọn của khách hàng, bạn có thể thêm điều này:

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

Cách này phải hợp lý VÀ. Nhưng tôi thực sự không thấy giá trị trong việc tạo ra sự phức tạp để giảm tính biểu cảm của cấu hình.