VRF Route-Leaking ist manchmal nötig um z.B. gemeinsam genutzte Ressourcen (Internet, Fileserver, etc.) mehreren VRFs zur Verfügung zu stellen. Ob und wie das Sinnhaft ist, spielt hier keine Rolle. Ich kenne es bis jetzt meistens mit dem Internetzugang den alle nutzen sollen. Intern sind die Netze aber weiterhin getrennt.
Es gibt mehrere Möglichkeiten Route-Leaking zwischen VRFs zu machen, erst die vermeintlich einfacherere Methode. Dazu sind nur statische Routen nötig.
Wir haben jetzt drei VRFs: VPNGW, VRF2, VRF3. Die Router sind einfach in einer Linie: angehordnet, siehe Bild.
Der Router IOU1 hat keine VRFs, lokale Adresse 1.1.1.1, diese soll von den beiden anderen VRFs erreichbar sein. Der mittlere CSR Router hat alle drei VRFs und der rechte Router, IOU2, hat die VRFs VRF2 und VRF3. VRF2 IP 1.1.10.3 und VRF3 IP 1.1.11.3. Das Route Leaking wird auf dem mittleren Router implementiert. Dort ist auch die Anbindung zum linken Router, IOU1, im VRF VPNGW. Der mittlere Router hat immer die IP mit .2 am Ende.
Um das normale Routing zu haben, nicht vergessen auf den äußeren Routern die Routen zu setzen damit sie ihren Weg haben um die Pakete zum mittleren Router zu schicken. Ich setze einfach Default Routen
Linker Router, IOU1
ip route 0.0.0.0 0.0.0.0 1.1.1.2
Rechter Router, IOU2
ip route vrf VRF2 0.0.0.0 0.0.0.0 1.1.10.2
ip route vrf VRF3 0.0.0.0 0.0.0.0 1.1.11.2
Auf dem mittleren Router, CSR, werden nun die statischen Routen gesetzt um das VRF Leaking zu machen
ip route vrf VPNGW 1.1.10.0 255.255.255.0 GigabitEthernet2.2 1.1.10.3
ip route vrf VPNGW 1.1.11.0 255.255.255.0 GigabitEthernet2.2 1.1.11.3
ip route vrf VRF2 1.1.1.0 255.255.255.0 GigabitEthernet1 1.1.1.1
ip route vrf VRF3 1.1.1.0 255.255.255.0 GigabitEthernet1 1.1.1.1
Das ergibt diese Routingtabelle auf dem mittleren Router, CSR:
R2-ISR4k(config)#do sh ip route vrf VPNGW
[...]
Gateway of last resort is not set
1.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 1.1.1.0/24 is directly connected, GigabitEthernet1
L 1.1.1.2/32 is directly connected, GigabitEthernet1
S 1.1.10.0/24 [1/0] via 1.1.10.3, GigabitEthernet2.2
S 1.1.11.0/24 [1/0] via 1.1.11.3, GigabitEthernet2.
Ein Ping und Traceroute vom rechten Router, IOU2, im VRF VRF2:
R-VRFs#ping vrf VRF2 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R-VRFs#traceroute vrf VRF2 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 1.1.10.2 55 msec 1 msec 1 msec
2 1.1.1.1 1 msec 1 msec 1 msec
NOTE – Diese Lösung funktioniert nur wenn man Next-Hop-IPs angeben kann. So wie in diesem Beispiel, wenn Router (IOU1 & IOU2) vorhanden sind. Falls Clients direkt am Router (CSR1000v) hängen, kann keine Next-Hop-IP gesetzt werden. Da die Clients direkt angebunden sind, somit kann in diese Richtung keine Route gesetzt werden.
Die zweite Möglichkeit ist ein VRF Route-Leaking auf Basis von Route-Imports und Exports mit BGP. Wer MPLS kennt, kennt diese Möglichkeit meistens schon.
Zuerst, die Konfig der VRFs:
vrf definition VPNGW
rd 1:1
!
address-family ipv4
route-target export 1:1
route-target import 1:1
route-target import 2:2
route-target import 3:3
exit-address-family
!
vrf definition VRF2
rd 2:2
!
address-family ipv4
route-target export 2:2
route-target import 2:2
route-target import 1:1
exit-address-family
!
vrf definition VRF3
rd 3:3
!
address-family ipv4
route-target export 3:3
route-target import 3:3
route-target import 1:1
exit-address-family
!
Jedes VRF hat sein eigenes Route-Target, wie man oben sehen kann. Damit das Leaking funktioniert, importieren die VRF2 und VRF3 das Route-Target 1:1 des VRF VPNGWs. Und dieses VRF VPNGW importiert die beiden Route-Targets der anderen VRFs. Ist oben alles schon drin. Das allein funktioniert aber nicht allein mit dieses Konfig. Man muss noch BGP einschalten, damit die Routen zwischen den Route-Targets und somit VRFs ausgetauscht werden.
router bgp 1
bgp router-id 2.2.2.2
bgp log-neighbor-changes
!
address-family ipv4 vrf VPNGW
redistribute connected
exit-address-family
!
address-family ipv4 vrf VRF2
redistribute connected
exit-address-family
!
address-family ipv4 vrf VRF3
redistribute connected
exit-address-family
!
Eine Redistribution der Connected Netzen reicht in diesem Labor aus. Wenn andere Routen, statische oder andere dynamische, zwischen den VRFs ausgetauscht werden sollen, muss man das noch anpassen.
Die Routingtabelle auf dem mittleren Router sieht damit nun so aus:
R2-ISR4k#sh ip route vrf VPNGW
[...]
Gateway of last resort is not set
1.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 1.1.1.0/24 is directly connected, GigabitEthernet1
L 1.1.1.2/32 is directly connected, GigabitEthernet1
B 1.1.10.0/24 is directly connected, 00:08:38, GigabitEthernet2.2
L 1.1.10.2/32 is directly connected, GigabitEthernet2.2
B 1.1.11.0/24 is directly connected, 00:08:38, GigabitEthernet2.3
L 1.1.11.2/32 is directly connected, GigabitEthernet2.3
R2-ISR4k#sh ip route vrf VRF2
[...]
Gateway of last resort is not set
1.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
B 1.1.1.0/24 is directly connected, 00:09:02, GigabitEthernet1
L 1.1.1.2/32 is directly connected, GigabitEthernet1
C 1.1.10.0/24 is directly connected, GigabitEthernet2.2
L 1.1.10.2/32 is directly connected, GigabitEthernet2.2
Und, wie vorhin auch, funktioniert der Ping und der Traceroute vom rechten Router, IOU2 aus dem VRF3:
R-VRFs#ping vrf VRF3 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/5 ms
R-VRFs#traceroute vrf VRF3 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 1.1.11.2 1 msec 2 msec 2 msec
2 1.1.1.1 1 msec 1 msec 1 msec
R-VRFs#
Der erste Ping ist, wie immer, in Timeout gelaufen, da die ARP Einträge noch nicht vorhanden waren.
NOTE – Im Gegensatz zur Lösung mit statischen Routen, wie oben beschrieben, funktioniert diese Lösung auch ohne Next-Hop Router.
Es gibt auch eine Möglichkeit Route-Leaking auf einem Router zu machen, auch wenn keine Next-Hops verfügbar sind. Dazu hat Cisco auch eine Anleitung geschrieben: