Filtrez avant de préférer. Une politique BGP de bordure qui échoue sans danger

Être multi-homed n'est pas la même chose qu'être résilient. Deux opérateurs de transit et un port sur un point d'échange vous donnent des options. La politique de routage décide si ces options vous rendent plus rapide et plus sûr, ou donnent simplement à une mauvaise route davantage de façons d'entrer. Voici comment nous pensons une politique de bordure, dans l'ordre où une route la rencontre réellement.

Le problème qu'a tout réseau multi-homed

Dès l'instant où vous recevez des tables complètes de plus d'un opérateur, votre routeur choisit entre des chemins toute la journée, tous les jours, et il choisit selon les règles que vous avez écrites. Si vous n'en avez écrit aucune, il retombe sur les critères de départage par défaut de BGP : le chemin d'AS le plus court, puis une cascade de détails qui n'ont rien à voir avec la latence, le coût ou vos clients.

Le raccourci habituel consiste à plaquer d'abord une préférence sur les sessions (« préférer l'opérateur A, il est moins cher ») et à ajouter le filtrage plus tard, voire jamais. Cet ordre est à l'envers. La préférence est une décision sur de bonnes routes. Si les déchets n'ont pas été retirés avant que cette décision soit prise, vous classez soigneusement des déchets.

Étape un : l'hygiène, avant toute décision

Chaque session entrante, transit ou peer, passe par la même politique d'hygiène avant que quoi que ce soit d'autre ne touche la route. La liste est courte et ennuyeuse, et c'est le but :

• Les bogons. L'espace privé, réservé, de documentation et non alloué n'a rien à faire en provenance d'internet.
• Vos propres préfixes. Une route vers votre propre espace apprise de l'extérieur est soit une boucle, soit un détournement. Rejetez-la.
• La route par défaut. À moins d'avoir demandé une route par défaut à un opérateur, vous ne voulez pas en voir apparaître parce que quelqu'un en amont a fait une erreur.
• Trop spécifique. Tout ce qui est plus long qu'un /24 en IPv4 (et qu'un /48 en IPv6) n'est pas routable globalement par convention. L'accepter invite les détournements par préfixe plus spécifique.
• Des chemins d'AS absurdes. Des chemins contenant des ASN privés, ou des chemins bien plus longs que n'importe quelle route réelle n'en a besoin.

En termes génériques de route-policy Cisco IOS-XR, le squelette ressemble à ceci :

route-policy TRANSIT-IN
  if destination in BOGONS-V4 or destination in OUR-PREFIXES then
    drop
  endif
  if destination in (0.0.0.0/0) then
    drop
  endif
  if destination in (0.0.0.0/0 ge 25) then
    drop
  endif
  if as-path in PRIVATE-ASNS then
    drop
  endif
  apply SET-PREFERENCE
end-policy

Remarquez que la logique de préférence s'applique tout à la fin, comme politique séparée. L'hygiène est identique sur chaque session. La préférence diffère par session. Les tenir séparées signifie qu'un changement d'aiguillage ne peut jamais affaiblir le filtrage par accident.

Étape deux : la préférence par paliers

Une fois qu'il ne reste que des routes saines, décidez quel chemin l'emporte. Nous utilisons des paliers de local preference plutôt qu'un nombre par opérateur, parce que les paliers décrivent une intention :

1. Le peering direct l'emporte. Une route apprise du réseau lui-même, sur un point d'échange ou par une session bilatérale, est le chemin le plus court que vous puissiez obtenir.
2. Les propres clients d'un opérateur viennent ensuite. Si un opérateur de transit marque d'une community les routes qu'il apprend de ses propres clients, ces routes restent sur le réseau de cet opérateur de bout en bout.
3. Tout le reste passe par le transit qui mesure le mieux pour le gros du trafic.

Un second opérateur est tenu « chaud » en secours : table complète acceptée, préférence plus basse, prêt dès l'instant où le premier se retire.

Une règle de plus rend service discrètement : n'utilisez jamais un opérateur de transit pour atteindre les clients d'un autre opérateur lorsque ce second opérateur est connecté à vous directement. Faire correspondre l'AS voisin dans le chemin et abaisser la préférence empêche le trafic de faire un détour coûteux par un tiers.

Étape trois : la discipline en sortie

Le côté sortant est plus simple et plus important. Annoncez exactement les préfixes dont vous êtes l'origine, et rien d'autre :

prefix-set OUR-PREFIXES-V4
  192.0.2.0/24,
  198.51.100.0/24
end-set

route-policy TRANSIT-OUT
  if destination in OUR-PREFIXES-V4 then
    pass
  else
    drop
  endif
end-policy

Une allow-list explicite en sortie signifie qu'une erreur ailleurs dans votre réseau (une statique redistribuée, une route client qui aurait dû rester interne) ne peut pas faire de vous un chemin de transit pour le trafic d'autrui. Le façonnage du chemin de retour, comme le préfixage d'AS-path vers un opérateur que vous voulez moins utiliser en entrée, se fait à l'intérieur de cette politique, jamais à sa place.

Étape quatre : n'émettez pas de trafic usurpé

La politique de routage contrôle ce que vous croyez. L'anti-spoofing contrôle ce que vous envoyez. BCP38 dit qu'un réseau ne doit pas transmettre de paquets dont l'adresse source ne pourrait pas légitimement provenir de derrière l'interface par laquelle ils sont arrivés. Sur les interfaces tournées vers internet et vers les clients, cela signifie l'unicast reverse path forwarding en mode strict là où la topologie le permet, ou des filtres explicites d'adresse source là où elle ne le permet pas. C'est l'un des rares contrôles qui protègent le reste d'internet de vous, et c'est la différence entre un serveur compromis dans votre réseau qui est votre problème et un qui devient le problème de tous.

Vérifier votre propre bordure

Si vous exploitez votre propre bordure, ou si vous voulez poser les bonnes questions à votre fournisseur, voici une courte liste de contrôle :

• L'hygiène est-elle appliquée à l'identique sur chaque session entrante, y compris les route servers des points d'échange et les peers « de confiance » ?
• Pouvez-vous montrer qu'un /25 ou votre propre préfixe envoyé par un voisin est rejeté ? Testez-le en labo, ou lisez la politique ligne par ligne.
• Votre politique de sortie est-elle une allow-list explicite, ou un « tout sauf » ?
• Savez-vous par quel opérateur sort votre trafic vers les dix premières destinations, et pourquoi ? Un traceroute depuis la bordure plus show bgp <prefix> y répond en quelques minutes.
• Le filtrage BCP38 est-il lié à chaque interface tournée vers internet, et avez-vous un test qui le prouve ?
• Mesurez-vous votre réseau depuis l'extérieur ? Une plateforme indépendante comme RIPE Atlas montre comment internet vous atteint réellement, ce qui n'est souvent pas ce que croit votre routeur.

Pourquoi nous nous donnons cette peine

Chacune de ces étapes est invisible un jour ordinaire. Le jour où un opérateur laisse fuir une table, coupe un circuit pour maintenance, ou qu'un voisin annonce quelque chose qu'il ne devrait pas, elles décident si votre trafic s'en aperçoit. Nous exploitons nos propres systèmes autonomes avec cette structure sur des routeurs Cisco ASR 9000 et Juniper MX, mesurés en continu depuis l'extérieur, parce que c'est la seule façon que nous connaissions de rendre un réseau multi-homed prévisible.

Si vous souhaitez un second regard sur votre propre politique de bordure, ou une plateforme qui repose derrière une bordure construite ainsi, nous serons heureux d'en parler.

Parler à un ingénieur

Related

Voir aussi : Notre propre réseau : deux ASN, plusieurs opérateurs, du peering · Supervision réseau et preuves · IPv6, natif et en dual-stack