Wirtualizacja fizycznych routerów czyli konfiguracja VRF na routerach Cisco.

VRF czyli Virtual Routing and Forwarding

W dzisiejszym poście z serii „Eksperymenty przy pełnym kubku” pochylamy się nad tematem VRF, czyli Virtual Routing and Forwarding.

Czy zastanawiałeś się kiedyś ile masz routerów w swoim Data Center? W zależności od wielkości sieci może to być kilka lub nawet kilkanaście. Każdy router musi być niezawodny, monitorowany, trzeba wykupić na niego support lub posiadać części zamienne. Dodatkowo planowanie upgrade’ów czy troubleshooting, szukanie w pośpiechu adresu IP czy nazwy urządzenia może dostarczyć wielu problemów. A co w sytuacji, gdy Wasz router agregujący łącza do oddziałów nie jest w stanie obsłużyć tak dużego ruchu i CPU skacze na 100%? Nie ma wyjścia, trzeba kupić nowy router lub wyjaśnić kierownikowi lub dyrektorowi, że się „nie da”, ale w większości przypadków to „nie” chyba się nie uda 🙂 A wtedy przetargi, zakupy, oczekiwanie 2-5 tygodni na sprzęt, potem instalacja i konfiguracja. Jeśli jest to coś nowego to super, trzeba się uczyć i rozwijać, ale jeśli podobne zadania wykonywaliśmy już dziesiątki razy, a na biurku leży fajny projekt lub nowy lab, to wolałbym się na tym skupić 🙂

W poniższym artykule chciałbym przedstawić rozwiązanie zastępujące kilka routerów jednym urządzeniem. Za pomocą technologii VRF możemy logicznie podzielić router na kilka urządzeń, gdzie każde z nich będzie miało swoją osobną tablicę routingu i forwardingu – stąd ta nazwa. VRF nie jest niczym nowym, jest używany już od wielu lat u operatorów telekomunikacyjnych w sieciach MPLS, by odseparować od siebie klientów.

Jaki router pod VRF ?

Po pierwsze powinien być to router z dużym zapasem mocy, a najlepiej taki, gdzie za pomocą licencji odblokujesz dodatkowo pasmo. Router musi mieć możliwość instalowania dużej ilości portów Ethernet w technologii miedzianej CU i światłowodowej FO oraz oczywiście mieć bogatą wersję IOS.

Jako, że od wielu lat związany jestem głównie z urządzeniami Cisco, mogę zaproponować w tym miejscu modułowy router Cisco z rodziny ASR1k – 1004 lub 1006. Oczywiście są na rynku inni producenci i jeśli wspierają VRF można użyć ich sprzętu.

Cisco ASR1k Data sheet : http://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/datasheet-c78-731632.html

Konfiguracja VRF.

Teraz to co tygryski lubią najbardziej, czyli konfiguracja. Załóżmy scenariusz, gdzie chcemy zastąpić trzy routery jednym, tak jak przedstawiono na poniższym rysunku:

  • Podłączający oddziały,
  • VPN do partnerów,
  • Intranet.

rys1Rys. 1 Typowa sieć z wieloma routerami.

rys2Rys. 2 Podzielenie routera na logiczne VRF.

Krok 1: Definiujemy VRF’y.

Dobrą praktyką jest wydzielenie VRF Managment tylko i wyłącznie do zarządzania routerem.

ip vrf MGMT
rd 10.0.0.1:1

A następnie VRF dla każdego logicznego routera:

ip vrf WAN
rd 10.0.0.1:2

ip vrf EXTRANET
rd 10.0.0.1:3

ip vrf INTRANET
rd 10.0.0.1:4

RD to Route Distinguisher, czyli identyfikator tras. Najlepiej żeby był to adres loopback routera lub BGP ASN jeśli planujesz wymianę tras pomiędzy VRF.

R1#sh ip vrf
Name                             Default RD         Interfaces
EXTRANET                         10.0.0.1:3
INTRANET                         10.0.0.1:4
MGMT                             10.0.0.1:1
WAN                              10.0.0.1:2

Krok 2: Przypisujemy interfejsy do odpowiedniego VRF

Gi 0/0/0 – MGMT
Gi 0/0/1 – WAN
Gi 0/0/2 – WAN
Gi 0/0/3 – WAN
Gi 0/0/4 – EXTRANET
Gi 0/0/5 – EXTRANET
Gi 0/0/6 – INTRANET
Gi 0/0/7 – INTRANET

UWAGA: Jeśli interfejs posiada adres IP, to zostanie on usunięty i trzeba go wpisać ponownie. Warto zwrócić na to uwagę, by się przypadkiem nie odciąć od routera. Najbezpieczniej VRF MGMT konfigurować po konsoli.

int e0/0
ip vrf forwarding MGMT
ip address 10.1.1.2 255.255.255.0

int e0/1
ip vrf forwarding WAN
int e0/2
ip vrf forwarding WAN
int e0/3
ip vrf forwarding WAN

int e1/0
ip vrf forwarding EXTRANET
int e1/1
ip vrf forwarding EXTRANET

int e1/2
ip vrf forwarding INTRANET
int e1/3
ip vrf forwarding INTRANET

W przypadku tuneli GRE musimy także dodać tę konfigurację na tunelach + dodatkowo komendę „tunnel vrf WAN”.

int tu0
ip vrf forwarding WAN
tunnel vrf WAN

Konfigurację VRF oraz przypisane do nich interfejsy możemy sprawdzić za pomocą komendy:

R1#sh ip vrf

Name                             Default RD         Interfaces
EXTRANET                         10.0.0.1:3         Et1/0 Et1/1
INTRANET                         10.0.0.1:4         Et1/2 Et1/3
MGMT                             10.0.0.1:1         Et0/0
WAN                              10.0.0.1:2         Et0/1 Et0/2 Et0/3 Tu0

Krok 3: Konfiguracja routingu

VRF MGMT – ma statyczny routing default route
VRF WAN – ma skonfigurowany routing dynamiczny w oparciu o EIGRP AS 10
VRF EXTRANET – ma skonfigurowany routing dynamiczny w oparciu o BGP AS 65001
VRF INTRANET – ma skonfigurowany routing dynamiczny w oparciu o OSPF

Krok 3.1:

VRF MGMT – ma statyczny routing default route

ip route vrf MGMT 0.0.0.0 0.0.0.0 10.1.1.1

Sprawdzamy tablicę routing VRF MGMT:

R1#sh ip route vrf MGMT

Routing Table: MGMT
Gateway of last resort is 10.1.1.1 to network 0.0.0.0
S*   0.0.0.0/0 [1/0] via 10.1.1.1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.1.1.0/24 is directly connected, Ethernet0/0
L       10.1.1.2/32 is directly connected, Ethernet0/0

Krok 3.2:

VRF WAN – ma skonfigurowany routing dynamiczny w oparciu o EIGRP AS 10

router eigrp 10
address-family ipv4 vrf WAN
autonomous-system 10
network 10.2.2.0
passive-interface default
no passive-interface Et0/1
no passive-interface Tu0
exit-address-family

Sprawdzamy sąsiedztwo EIGRP I tablicę routing VRF WAN:

R1#sh ip eigrp vrf WAN neighbors

EIGRP-IPv4 Neighbors for AS(10) VRF(WAN)
H   Address                 Interface             Hold Uptime   SRTT   RTO Q Seq
(sec)         (ms)       Cnt Num
0   10.2.2.1               Et0/1                   12 00:00:17   13   100 0 2

R1#sh ip route vrf WAN

Routing Table: WAN
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C       10.2.2.0/24 is directly connected, Ethernet0/1
L       10.2.2.2/32 is directly connected, Ethernet0/1
D       10.10.10.0/24 [90/409600] via 10.2.2.1, 00:00:21, Ethernet0/1

Krok 3.3:

VRF EXTRANET – ma skonfigurowany routing dynamiczny w oparciu o BGP AS 65001

router bgp 65001
address-family ipv4 vrf EXTRANET
neighbor 10.3.3.1 remote-as 40000
neighbor 10.3.3.1 activate
no auto-summary
no synchronization
exit-address-family

Sprawdzamy sąsiedztwo BGP i tablicę routing VRF EXTRANET:

R1#sh bgp vpnv4 unicast vrf EXTRANET neighbors

BGP neighbor is 10.3.3.1, vrf EXTRANET, remote AS 40000, external link
BGP version 4, remote router ID 20.20.20.1
BGP state = Established, up for 00:01:14
Last read 00:00:07, last write 00:00:13, hold time is 180, keepalive interval is 60 seconds

Neighbor sessions:
1 active, is not multisession capable (disabled)

Wyświetlmy tablicę BGP:

R1#sh bgp vpnv4 unicast vrf EXTRANET

BGP table version is 2, local router ID is 10.3.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network         Next Hop           Metric LocPrf Weight Path
Route Distinguisher: 10.0.0.1:3 (default for vrf EXTRANET)
*> 20.20.20.0/24   10.3.3.1                 0             0 40000 i

Wyświetlmy tablicę routingu VRF EXTRANET:

R1#sh ip route vrf EXTRANET

Routing Table: EXTRANET
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.3.3.0/24 is directly connected, Ethernet1/0
L      10.3.3.2/32 is directly connected, Ethernet1/0
20.0.0.0/24 is subnetted, 1 subnets
B       20.20.20.0 [20/0] via 10.3.3.1, 00:00:43

Krok 3.4:

VRF INTRANET – ma skonfigurowany routing dynamiczny w oparciu o OSPF

router ospf 1 vrf INTRANET
network 10.4.4.0 0.0.0.255 area 0

Wyświetlamy stan sąsiedztwa OSPF:

R1#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.10       1   FULL/BDR       00:00:37   10.4.4.1       Ethernet1/3

Wyświetlmy tablicę routingu VRF EXTRANET:

R1#sh ip route vrf INTRANET

Routing Table: INTRANET
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.4.4.0/24 is directly connected, Ethernet1/3
L       10.4.4.2/32 is directly connected, Ethernet1/3
40.0.0.0/32 is subnetted, 1 subnets
O IA     40.40.40.1 [110/11] via 10.4.4.1, 00:00:15, Ethernet1/3

Należy pamiętać, że każda z tablic routingu i forwardingu VRF jest autonomiczna i samodzielna. Domyślam się, że wiele osób czytających ten artykuł obawia się, że ruch w jakiś “magiczny” sposób przejdzie pomiędzy VRF’ami. Chciałbym uspokoić I potwierdzić, że w konfiguracji jaką przedstawiłem nie ma takiej bezpośredniej możliwości i należałoby użyć jedną z następujących dwóch metod:

– kabel łączący porty w różnych VRF, wpiete de facto w ten sam router,

– RD (Route Distinguisher) import/export :

ip vrf EXTRANET
rd 10.0.0.1:3
route-target export 10.0.0.1:3
route-target import 10.0.0.1:3
route-target import 10.0.0.1:4

ip vrf INTRANET
rd 10.0.0.1:4
route-target export 10.0.0.1:4
route-target import 10.0.0.1:4
route-target import 10.0.0.1:3

Dodatkowo należałoby uruchomić proces MP-BGP (Multi-Protocol BGP) i dodać address-family ipv4 dla każdego VRF, by trasy routingu zostały wymienione. Bez MP-BGP nic się nie stanie.

Podsumowanie

Wiem, że przedstawiony w powyższym artykule sposób na logiczne podzielenie routera nie wpisuje się w każdą sieć, ale jestem pewien, wraz ze wzrostem świadomości jak to rozwiązanie działa, przećwiczeniem swojego scenariusza w laboratorium, można znacznie uprościć swoją sieć. Jestem także pewien, że wiele osób zastanawia się czy ja jako autor użyłem tego scenariusza w produkcji? Tak, użyłem I to w dużej skali, bo uruchamiając VRF na ok 140 routerach Cisco 2800, gdzie musiałem wydzielić oddzielną instancję routera. Pomimo skali tego przedsięwzięcia i długości pracy tego rozwiązania (około roku) nie było żadnych problemów z tym związanych, co uważam za jeden ze swoich większych sukcesów zawodowych.

Michał Grzelak
Posiada 11 lat doświadczenia w zarządzaniu i projektowania sieci i systemów bezpieczeństwa – głównie w Data Center, a od 3 lat entuzjasta wirtualizacji sieci. Pasjonat biegania i kolarstwa górskiego.