Instance de routage virtuelle (VRF-Lite)
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-native en plusieurs routeurs virtuels indépendants, chacun disposant de sa propre table de routage. La division d’un appareil 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 VRF (Virtual Routing and Forwarding) est souvent utilisé en conjonction avec des sous-interfaces de couche 3, ce qui permet de différencier le trafic d’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. Pour plus d’informations, consultez la rubrique Instances de routeur virtuel .
Configuration
Vous pouvez créer une instance de routage virtuelle dans le routeur Cloud-Native via un manifeste NAD (Network Attachment Definition). Voici un exemple de 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’option instanceType est définie sur virtual-router. Pour plus d’informations sur le NAD, reportez-vous à la section Cas d’usage et présentation de la configuration des routeurs cloud-native .
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 de routeur Cloud-Native. Vous pouvez configurer le routeur Cloud-Native 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 fabric 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 les routes BGP correspondant au préfixe
192.168.12.0de 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
Le routeur Cloud-Native prend en charge les fuites 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.