Instance de routage virtuel (VRF-Lite)
RÉSUMÉ Lisez cette rubrique pour comprendre l’implémentation des instances de routage virtuel dans JCNR.
Les instances de routage virtuel permettent aux administrateurs de diviser le routeur cloud natif en plusieurs routeurs virtuels indépendants, chacun ayant sa propre table de routage. Le fractionnement d’un équipement en plusieurs instances de routage virtuel isole le trafic circulant sur le réseau sans que plusieurs équipements n’aient besoin de segmenter le réseau. Vous pouvez utiliser des instances de routage virtuelles pour isoler le trafic client sur votre réseau et lier des instances spécifiques au client à des interfaces appartenant au client. Le routage et transfert virtuels (VRF) est souvent utilisé en conjonction avec des sous-interfaces de couche 3, permettant de différencier le trafic sur une seule interface physique et de l’associer à plusieurs routeurs virtuels. Chaque sous-interface logique de couche 3 ne peut appartenir qu’à une seule instance de routage. Consultez la rubrique Instances de routeur virtuel pour plus d’informations.
Configuration
Vous pouvez créer une instance de routage virtuel dans JCNR via un manifeste NAD (Network Attachment Definition). Voici un exemple NAD pour créer une bluenet instance de routage de routeur virtuel :
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: blue
spec:
config: '{
"cniVersion":"0.4.0",
"name": "blue-net",
"plugins": [
{
"type": "jcnr",
"args": {
"instanceName": "bluenet",
"instanceType": "virtual-router"
},
"kubeConfig":"/root/.kube/config"
}
]
}'
Notez que l’attribut instanceType est défini sur virtual-router. Pour plus d’informations sur le NAD, reportez-vous aux cas d’utilisation et à la présentation de la configuration JCNR .
Voici un exemple de configuration pour un podblue pod avec une interface (192.168.11.10/24) attachée au blue réseau (la sortie est coupée pour plus de brièveté) :
apiVersion: v1
kind: Pod
metadata:
name: podblue
annotations:
k8s.v1.cni.cncf.io/networks: |
[
{
"name": "blue",
"interface":"net1",
"cni-args": {
"interfaceType":"veth",
"dataplane":"dpdk",
"mac":"aa:bb:cc:dd:ee:10",
"ipConfig":{
"ipv4":{
"address":"192.168.11.10/24",
"gateway":"192.168.11.1",
"routes":["192.168.11.0/24"]
},
"ipv6":{
"address":"abcd::192.168.11.10/112",
"gateway":"abcd::192.168.11.1",
"routes":["abcd::192.168.11.0/112"]
}
}
}
}
]
spec:
...
Lorsque vous appliquez le NAD et les manifestes de pod à l’aide de la kubectl apply -f manifest commande, l’instance de routage et bluenet.inet.0 la bluenet table de routage sont créées dans le contrôleur JCNR. Vous pouvez configurer JCNR pour activer la communication depuis podblue les pods sur le réseau distant. Une configuration cRPD supplémentaire peut être effectuée en accédant au shell cRPD. Voici un exemple de configuration cRPD :
Configurez l’interface de structure locale et le protocole BGP :
set interfaces ens2f0 unit 0 family inet address 10.10.10.11/24 set protocols bgp group overlay type internal set protocols bgp group overlay local-address 10.10.10.11 set protocols bgp group overlay local-as 64520 set protocols bgp group overlay neighbor 10.10.10.12 peer-as 64520
où
10.10.10.12/24est l’adresse IP du pair BGP ou du routeur voisin.Exportez les
inetroutes à l’aide du protocole BGP :set policy-options policy-statement send_direct term 1 from protocol direct set policy-options policy-statement send_direct term 1 then accept set policy-options policy-statement send_direct term reject then reject set protocols bgp group overlay export send_direct
Fuite des routes de l’instance
bluenetde routage vers l’instance dedefaultroutage :set groups cni routing-instances bluenet routing-options interface-routes rib-group inet blue_to_inet set routing-options rib-groups blue_to_inet import-rib bluenet.inet.0 set routing-options rib-groups blue_to_inet import-rib inet.0
Ne divulguez que le préfixe
192.168.12.0correspondant aux routes BGP de vers l’instancebluenetdeinet.0routage, où192.168.12.0/24se trouve le réseau de pod distant :set policy-options policy-statement inet_to_blue term from_bgp from instance master set policy-options policy-statement inet_to_blue term from_bgp from protocol bgp set policy-options policy-statement inet_to_blue term from_bgp from route-filter 192.168.12.0/24 orlonger set policy-options policy-statement inet_to_blue term from_bgp then accept set policy-options policy-statement inet_to_blue term reject then reject set routing-options rib-groups inet_to_blue import-rib inet.0 set routing-options rib-groups inet_to_blue import-rib bluenet.inet.0 set routing-options rib-groups inet_to_blue import-policy inet_to_blue set groups cni routing-instances bluenet routing-options instance-import inet_to_blue
JCNR prend en charge la fuite de route entre les instances de routage de routeur virtuel pour les routes avec des sauts suivants d’interface, de réception, de résolution et de table.