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.
Rys. 1 Typowa sieć z wieloma routerami.
Rys. 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.
Bardzo fajny post.