BGP Remote-Triggered Blackhole (RTBH) -Filter für Juniper

Ich versuche, den elegantesten Weg zu finden, um einen RTBH- Filter für von einem Kunden empfangene Routen zu implementieren .

Der Filter sollte:

1. Akzeptieren Sie nur die eigenen Präfixe des Kunden aus einer Präfixliste
2. Akzeptiere nur / 32 Präfixe
3. Nur Präfixe mit der Blackhole-Community
4. Stellen Sie den nächsten Hop auf den nächsten RTBH-Hop (192.0.2.1).

Zu Beginn habe ich mir das Dokument " Konfigurieren von Übereinstimmungsbedingungen in Routing-Richtlinienbedingungen " von Juniper angesehen.

Zuerst dachte ich darüber nach, a so prefix-list-filterzu kombinieren , dass nur Routen aus der Präfixliste des Kunden übereinstimmen, und a route-filter, um die akzeptierten Präfixe auf / 32 zu beschränken, wie folgt:

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

Aber dann bin ich über diese Informationen im Dokument gestolpert:

Wenn Sie eine Richtlinie konfigurieren, die eine Kombination aus Routenfiltern, Präfixlisten und Quelladressfiltern enthält, werden diese gemäß einer logischen ODER-Operation oder einer Suche nach Übereinstimmungen mit der längsten Route ausgewertet.

Wie ich verstehe diese (und ich es ein bisschen unklar finden), wenn ich verwende prefix-list-filter, route-filterund / oder source-address-filterin dem gleichen Begriff wäre es mit einem längsten Match ODER zwischen alle von ihnen ausgewertet werden, was dieser Ansatz macht unbrauchbar .

Was ich mir ausgedacht habe, ist der folgende Filter. Der hostroutes-onlyBegriff leitet alle Präfixe, die kürzer als / 32 sind, zur nächsten Richtlinie um. Danach prefixesstimmt der Begriff überein, wenn sich die / 32 im Bereich des Kunden befindet, mit seinem As-Path übereinstimmt und die Blackhole-Community festgelegt ist:

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;
    }
}

Ist dies die eleganteste Art, damit umzugehen? Irgendwelche anderen Lösungen?

Es gibt keinen Grund, den Kunden auf Blackhole / 32 zu beschränken und ihm zu erlauben, alles von ihm zu lochen.

Etwas wie das:

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;
    }
}

Denken Sie daran, 'accept-remote-nexthop' unter den BGP-Einstellungen festzulegen, damit der nächste Hop in etwas anderes als die Linkadresse geändert werden kann.

Ich unterstütze auch nachdrücklich, dass Anbieter beginnen, andere Blackhole-Communities zu unterstützen als nur "Full Blackhole". Insbesondere wenn Sie in mehr als einem Land tätig sind, erfolgt der Angriff normalerweise über den Transit und häufig möchte der Kunde tatsächlich auf inländische Peerings zugreifen. Daher ist es nützlich, mehrere Ebenen von Blackhhole zu implementieren:

1. Voll
2. Außerhalb des Landes (lokales IXP, ganze eigene AS + Kunden gesehen)
3. Außerhalb der Region (falls zutreffend, wie bei mir könnte es sich um "Nordics" handeln)
4. Einschließen / Ausschließen eines bestimmten Peering-Routers in Blackhole

Ich gebe gerne ein Beispiel, wie man so etwas mit JNPR DCU / SCU implementiert, vorausgesetzt, Ihre Peering-Router sind JNPR, aber es ist nur mit Communitys möglich, nur etwas umständlicher.

Wenn Sie die Optionen Ihres Kunden unbedingt einschränken möchten, können Sie Folgendes hinzufügen:

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;
        }
..
}

Auf diese Weise sollte es logisch sein UND. Aber ich sehe wirklich keinen Wert darin, Komplexität zu schaffen, um die Ausdruckskraft der Konfiguration zu verringern.