Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Fonctionnalités de Junos OS prises en charge sur cRPD

Fonctionnalités prises en charge sur cRPD

cRPD hérite de la plupart des fonctionnalités de routage avec les considérations suivantes indiquées dans le tableau 1.

Tableau 1 : fonctionnalités prises en charge sur cRPD

Fonction

Description

BGP FlowSpec

À partir de Junos OS version 20.3R1, la méthode de spécification de flux BGP est prise en charge pour empêcher les attaques par déni de service sur l’environnement cRPD.

[Voir Présentation des itinéraires de flux BGP pour le filtrage du trafic.]

EVPN-VPWS

À partir de Junos OS version 20.3R1, EVPN-VPWS est pris en charge pour fournir à VPWS des mécanismes de signalisation EVPN sur cRPD.

[Voir Vue d’ensemble de VPWS avec mécanismes de signalisation EVPN.]

EVPN TYPE 5 avec MPLS

À partir de Junos OS version 20.3R1, EVPN Type 5 est pris en charge pour EVPN/MPLS.

[Voir Route EVPN Type-5 avec encapsulation MPLS pour EVPN-MPLS.]

Routage de segments

À partir de Junos OS version 20.3R1, le routage de segments prend en charge les protocoles OSPF et IS-IS afin de fournir des fonctionnalités de base avec SPRING (Source Packet Routing in Networking).

[Voir Comprendre le routage des paquets sources en réseau (SPRING).]

VPN de couche 2

À partir de Junos OS version 20.3R1, prise en charge du circuit de couche 2 pour fournir aux VPN et VPWS de couche 2 une signalisation LDP.

[Voir Configuration d’Ethernet sur MPLS (circuit de couche 2).]

MPLS

À partir de Junos OS version 20.3R1, prise en charge de MPLS pour fournir la configuration du protocole de signalisation LDP avec la fonctionnalité de plan de contrôle.

[Voir Présentation du protocole de signalisation LDP.]

Événement

À partir de Junos OS version 20.4R1, nous prenons uniquement en charge les stratégies d’événements externes. Vous pouvez activer ces stratégies dans cRPD. Dans cRPD, eventd et rsyslogd s’exécutent en tant que processus indépendants. Le processus eventd fournit une interface eventinterface avec des processus tels que rpd, auditd et mgd et prend en charge l’exécution automatisée des stratégies d’événements.

Utilisez la commande pour activer une stratégie d’événements et restart event-processing redémarrer le set event-options policy policy name events [events] then traitement des événements.

Par défaut, la prise en charge de Python 3.x est activée avec les fonctions Python ou SLAX intégrées existantes dans l’environnement cRPD.

Utilisez le niveau hiérarchique pour activer et prendre en charge l’automatisation des [edit system scripts language python3] événements Python.

[Voir options d’événement et politique d’événement.]

Authentification, autorisation et comptabilité

À partir de cRPD version 21.1R1, vous pouvez configurer l’authentification locale, l’autorisation locale, l’authentification Tacplus, l’autorisation Tacplus et la comptabilité Tacplus au niveau de la [edit system] hiérarchie.

Nous prenons en charge les fonctionnalités suivantes :

  • Authentification locale et autorisation locale

  • Authentification, autorisation et comptabilité TACACS+

  • Prise en charge des modèles utilisateur

  • Prise en charge des commandes opérationnelles et des expressions régulières

  • Authentification locale et autorisation à distance sur serveur Tacplus.

[Voir password-options et tacplus.]

Programmation réseau SRv6 dans IS-IS

À partir de cRPD version 21.1R1, vous pouvez configurer pour activer les fonctionnalités de routage de segments de base dans un réseau IPv6 central pour le rôle de réflecteur de route et le rôle de routage hôte.

Vous pouvez activer la programmation réseau SRv6 dans un réseau IPv6 au niveau de la [edit source-packet-routing] hiérarchie.

Un identificateur de segment se compose des éléments suivants :

  • Locator— Le localisateur est la première partie d’un SID composée des bits les plus significatifs représentant l’adresse d’un nœud SRv6 particulier. Le localisateur est très similaire à une adresse réseau qui fournit un itinéraire vers son nœud parent. Le protocole IS-IS installe la route de localisation dans la table de inet6.0 routage. IS-IS achemine le segment vers son nœud parent, qui exécute ensuite une fonction définie dans l’autre partie du SID SRv6. Vous pouvez également spécifier l’algorithme associé à ce localisateur.

  • Function: l’autre partie du SID définit une fonction exécutée localement sur le nœud spécifié par le localisateur. Il y a plusieurs fonctions qui ont déjà été définies dans le brouillon Internet draft-ietf-spring-srv6-network-programming-07draft, SRv6 Network Programming. Cependant, nous avons implémenté les fonctions suivantes qui sont signalées dans IS-IS. IS-IS installe ces SID de fonction dans la table de inet6.0 routage.

    • End— Fonction de point de terminaison pour l’instanciation SRv6 d’un SID de préfixe. Elle ne permet pas la décapsulation d’un en-tête extérieur pour l’enlèvement d’une SSR. Par conséquent, un SID final ne peut pas être le dernier SID d’une liste SID et ne peut pas être l’adresse de destination (DA) d’un paquet sans SRH.

    • End.X— Une fonction de point de terminaison X est une instanciation SRv6 d’un SID adjacent. Il s’agit d’une variante de la fonction de point de terminaison avec une connexion croisée de couche 3 à un ensemble d’adjacences de couche 3.

    Note:

    La prise en charge des options de saveur (spécifie le comportement des sid d’extrémité) et d’algorithmes flexibles n’est pas disponible pour configurer les sids d’extrémité.

[Voir routage des paquets source].

Augmenter la limite de saut suivant ECMP

À partir de cRPD version 21.1R1, vous pouvez spécifier la limite de saut suivant à chemins multiples au niveau de la [edit routing-options maximum-ecmp] hiérarchie. Cela permet d’équilibrer la charge du trafic sur plusieurs chemins. La limite de saut suivant ECMP par défaut est de 16.

[Voir les options de routage max ecmp et Hash Field Selection pour l’équilibrage de charge ECMP sous Linux].

EVPN Type 5 avec VXLAN

À partir de la version 21.1R1 de cRPD, nous prenons en charge la route EVPN de type 5 sur VXLAN pour les annonces de préfixe IPv4 et IPv6.

[Voir Route EVPN Type-5 avec encapsulation VXLAN pour EVPN-VXLAN].

Encapsulation EVPN sur VXLAN

À partir de la version 21.2R1 de cRPD, nous prenons en charge la fonctionnalité EVPN sur VXLAN de couche 2.

[Voir EVPN avec encapsulation de plan de données VXLAN et services MAC-VRF L2].

Prise en charge des tunnels dynamiques basés sur le saut suivant

À partir de cRPD version 21.2R1, cRPD prend en charge la configuration de tunnels IP dynamiques basés sur le saut suivant dans le noyau Linux pour fournir un chemin privé et sécurisé sur un réseau public. Chaque fois qu’un tunnel doit être installé dans le noyau, une interface de tunnel est créée. Les interfaces de tunnel sont créées sous Linux à l’aide de messages netlink. L’ifindex de l’interface du tunnel est utilisé pour écouter et programmer les itinéraires passant par le tunnel composite next-hop. Par défaut, le tunnel MPLS-over-UDP est préféré aux tunnels GRE. Les tunnels dynamiques suivants sont pris en charge :

  • MPLS-over-GRE (encapsulation de routage générique)
  • MPLS-sur-UDP

[Pour plus d’informations sur la présentation des tunnels dynamiques, consultez Tunnels dynamiques basés sur le saut suivant, Tunnels basés sur le saut suivant pour les VPN de couche 3, Configuration des tunnels dynamiques MPLS-sur-UDP basés sur le saut suivant, Tunnels dynamiques et Vue d’ensemble des tunnels dynamiques].

Prise en charge des services SRv6 et de couche 3 sur SRv6 dans BGP

À partir de cRPD version 21.3R1, vous pouvez configurer un service de couche 3 basé sur BGP sur un cœur SRv6 sur cRPD. Vous pouvez activer les services de superposition de couche 3 avec BGP comme plan de contrôle et SRv6 comme plan de données. La programmation réseau SRv6 offre la flexibilité nécessaire pour exploiter le routage de segments sans déployer MPLS. Ces réseaux dépendent uniquement des en-têtes IPv6 et des extensions d’en-tête pour la transmission des données.

Limitations

  • Lorsque cRPD en tant que PE agit en tant que RR, le transfert ne fonctionnera pas à l’aide du tunnel SRv6 pour les routes PE-CE locales
  • Fin du cœur IPv4 sur SRv6 global. DT4 n’est pas pris en charge avec le noyau Linux
  • La vérification du SID SRv6 configuré en double dans un routeur n’est pas prise en charge.
  • Le service de superposition SRv6 requiert un SID de service pour le transfert. Lorsqu’au moins une TLV de service SRV6 mal formée est présente dans l’attribut BGP Prefix-SID, au lieu d’action, le paquet de treat-as-withdraw mise à jour BGP est ignoré. Lors de la suppression accept-srv6-service , il n’y aura aucun impact sur les routes déjà reçues avec SRV6 SID.

[Pour plus d’informations, voir advertise-srv6-service, srv6 (BGP), Comprendre la programmation réseau SRv6 et les services de couche 3 sur SRv6 dans BGP].

Prise en charge des machines RISC avancées (ARM64) (cRPD)

À partir de la version 21.4R1 de cRPD, cRPD est empaqueté sous la forme d’un conteneur docker pouvant s’exécuter sur une plate-forme ARM 64 bits.

cRPD sur ARM ne prend pas en charge les fonctionnalités suivantes :

  • Sharding et mise à jourIO. Les set system processes routing bgp rib-sharding number-of-shard commandes et set system processes routing bgp update-threading number-of-threadsne sont pas prises en charge.
  • SRv6

[Pour plus d’informations, voir Configuration requise pour le serveur ].

Prise en charge de l’exportation du RIB local BGP via le protocole de surveillance BGP (BMP)

À partir de cRPD version 23.2R1, BMP est améliorée pour prendre en charge la surveillance de la stratégie de la base d’informations de routage local (RIB) loc-rib sur cRPD. La loc-rib stratégie est ajoutée aux types RIB sous l’instruction bmp route-monitoring .

[Pour plus d’informations, voir Présentation du protocole de surveillance BGP, bmp et route-monitoring].

Interopérabilité du routage de segments avec LDP

À partir de cRPD version 23.2R1, vous pouvez utiliser OSPF ou ISIS pour permettre aux périphériques de routage de segments de fonctionner avec les périphériques LDP qui ne sont pas compatibles avec le routage de segments.

[Pour plus d’informations, consultez Serveur de mappage LDP pour l’interopérabilité du routage de segments et du routage de paquets source].

Prise en charge de la journalisation à l’aide d’événements et de fuseaux horaires (cRPD)

Nous prenons en charge le processus événementiel sur cRPD pour configurer la journalisation et le transfert du syslog vers l’hôte distant et le fuseau horaire du système.

Le support suivant n’est pas disponible sur cRPD :

  • help pour afficher les informations syslog.

  • rsyslogd pour la journalisation.

Limitations

  • La configuration de l’instance de routage pour le client Syslog n’est management-instance pas prise en charge.

  • L’authentification TLS n’est pas prise en charge pour le transfert syslog sur cRPD.

[Pour plus d’informations, reportez-vous à Configurer les fuseaux horaires, les fuseaux horaires et la prise en charge de Syslog sur cRPD].

Prise en charge du serveur RADIUS (cRPD)

Nous fournissons un support serveur RADIUS pour utiliser les fonctions d’authentification, d’autorisation et de comptabilité sur cRPD.

[Pour plus d’informations, consultez Authentification RADIUS, radius (système) et serveur_rayon (système)].