Filtre BGP à déclenchement à distance (RTBH) BGP pour Juniper


9

J'essaie de trouver le moyen le plus élégant d'implémenter un filtre RTBH pour les itinéraires reçus d'un client.

Le filtre doit:

  1. Accepter uniquement les préfixes des clients à partir d'une liste de préfixes
  2. Accepter uniquement / 32 préfixes
  3. Seuls les préfixes avec la communauté blackhole
  4. Définissez le tronçon suivant sur le tronçon suivant RTBH (192.0.2.1)

Pour commencer, j'ai regardé le document " Configuration des conditions de correspondance dans les conditions de la politique de routage " de Juniper.

J'ai d'abord pensé à combiner un prefix-list-filterpour ne faire correspondre que les itinéraires de la liste des préfixes clients et un route-filterpour limiter les préfixes acceptés à / 32, comme ceci:

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

Mais ensuite je suis tombé sur cette information dans le document:

Si vous configurez une stratégie qui inclut une combinaison de filtres de route, de listes de préfixes et de filtres d'adresse source, ils sont évalués selon une opération logique OU ou une recherche de correspondance de route la plus longue.

Si je comprends bien (et je trouve cela un peu flou), si j'utilise prefix-list-filter, route-filteret / ou source-address-filterdans le même terme, il serait évalué avec un OU le plus long entre tous, ce qui rend cette approche inutilisable .

Ce que j'ai trouvé, c'est le filtre suivant. Le hostroutes-onlyterme détourne tous les préfixes inférieurs à / 32 vers la stratégie suivante. Après cela, le prefixesterme correspond si le / 32 est à la portée du client, correspond à son chemin d'accès et a la communauté de trous noirs définie:

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

Alors, est-ce la façon la plus élégante de gérer cela? D'autres solutions?

Réponses:


8

Il n'y a aucune raison de limiter le client au trou noir uniquement / 32, de leur permettre de tout trou noir.

Quelque chose comme ça:

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

N'oubliez pas de définir «accept-remote-nexthop» sous les paramètres BGP, afin que le prochain saut puisse être changé en autre chose que l'adresse de liaison.

Je soutiens également fermement que les prestataires commencent à soutenir différentes communautés de trou noir que le «trou noir complet». Surtout si vous opérez dans plus d'un pays, l'attaque provient généralement du transit et, souvent, le client souhaite principalement accéder aux peerings nationaux, il est donc utile de mettre en œuvre plusieurs niveaux de trou noir:

  1. Plein
  2. En dehors du pays local (IXP local, propres clients AS + vus)
  3. En dehors de la zone locale (le cas échéant, comme pour moi, il pourrait s'agir de «pays nordiques»)
  4. Inclure / exclure un routeur d'appairage spécifique dans le trou noir

Je suis heureux de donner un exemple comment implémenter quelque chose comme ça avec JNPR DCU / SCU, à condition que vos routeurs d'appairage soient JNPR, mais c'est possible avec seulement des communautés, juste un peu plus gênantes.


Si vous voulez absolument limiter les options de votre client, vous pouvez ajouter ceci:

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

De cette façon, il devrait être logique ET. Mais je ne vois vraiment pas l'intérêt de créer de la complexité pour réduire l'expressivité de la configuration.


Merci pour votre réponse. Je ne veux pas que les clients trouent de plus grandes parties de leur espace, car ils se tirent généralement dessus avec le pied. En ce qui concerne «accept-remote-nexthop», je change le prochain saut de notre côté dans le filtre de politique, donc je n'ai pas besoin de l'activer sur la session.
Sebastian Wiesinger

Nous ne «punissons» personne. S'ils veulent mettre sur liste noire des préfixes plus grands, ils peuvent certainement le demander. Au cours des dernières années, personne ne l'a demandé.
Sebastian Wiesinger

Vous voyez des problèmes supplémentaires, ajoutant de la complexité, pour réduire l'expressivité. Si vous ne l'avez jamais proposé, comment savez-vous que vos clients ajouteraient accidentellement une communauté de trous noirs à des filets plus grands que / 32? Par coïncidence, chaque fois que nous demandons une fonctionnalité aux fournisseurs, ils répondent `` personne ne l'a jamais demandée '' et lorsque vous parlez à la communauté, vous trouverez de nombreuses personnes en manque pour une telle fonctionnalité. Quoi qu'il en soit, j'ai ajouté une suggestion sur la façon de mettre en œuvre cette limite.
ytti

J'ai réalisé que dans votre exemple, vous n'acceptez pas du tout les préfixes sans blackholing. Donc, vous avez probablement deux peerings, un pour le trafic normal et un pour blackholing, et le blackholing est probablement multihop dans votre cas, dans multihop, la vérification du saut suivant est déjà désactivée, vous n'avez donc pas besoin d'accepter à distance -nexthop ». Mon exemple couvre les deux peerings BGP dans la même configuration, et comme il s'agit de PE direct <-> CE sans multihop, il a besoin de 'accept-remote-nexthop'.
ytti

Oui c'est vrai, vous en avez besoin lors de sessions directes. Le filtre devrait fonctionner dans les deux situations, vous le chaîneriez avec d'autres politiques de filtrage derrière lui dans le scénario PE <-> CE.
Sebastian Wiesinger
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.