PLNOG 9: Robert Ślaski - SKALOWALNE SZYFROWANIE USŁUG W SIECI OPERATORA - przykład wdrożenia

ATM Systemy Informatyczne S.A.
SKALOWALNE SZYFROWANIE
USŁUG W SIECI OPERATORA
- przykład wdrożenia
Robert Ślaski
Chief Network Architect
CCIE#10877
PLNOG9
22-23 października 2012
Kraków

ATM Systemy Informatyczne S.A. PLNOG9, Kraków 2012
2
 Nasz pacjent
 Nasze narzędzie
 Pacjent kontra narzędzie
 Przebieg operacji
Zapraszamy na pokład!
http://www.pbase.com/flying_dutchman/

3
NASZ
PACJENT

4
 Wdrażana w ramach budowy sieci operatorskiej usługa ogólnopolskiego
Systemu Zintegrowanej Komunikacji (SZK)
 Świadczona ma być przez Operatora dla wszystkich Użytkowników sieci
 Zapewni łączność VoIP pomiędzy „starymi” systemami PBX użytkowników
 Zapewni obsługę telefonii IP (centralne IP PABX)
 Da ogromne możliwości funkcjonalne, nową jakość pracy
 Usługi dodatkowe
 Mobilność użytkowników
 Dostępność pod jednym numerem telefonu
 Wideo
 Audio i Wideo konferencje
 Jednorodne styki z sieciami operatorów
Nasz pacjent
- usługa Zintegrowanej Komunikacji

System Zintegrowanej Komunikacji
- struktura
 Planowana struktura Systemu Zintegrowanej Komunikacji
 17 klastrów Cisco Unified Communications Manager
 34 gatekeepery
 2 directory gatekeepery
 Na początek ponad 1000 bram głosowych
ze stykami do PBX użytkowników
 Tysiące telefonów IP
 Centralny styk do PSTN
 5 użytkowników z ponad 100 000
abonentów w pierwszym etapie
5

Wymagania techniczne pacjenta
 Wymagane jest szyfrowanie całego ruchu w systemie
(ruchu kontrolnego jak i danych)
 Zapewnienie przewagi technologicznej
 Metoda zabezpieczenia transmisji przy niektórych
„nie do końca bezpiecznej natury” łączach dostępowych
 Z szyfrowaniem mają działać połączenia głosowe VoIP,
telefonia IP, wideo oraz faksy (w tym również wcześniej zaszyfrowane)
 Ze względu na sposób dołączenia i topologię dołączenia
najmniejszych lokalizacji, pożądane jest, aby ruch
(nawet po zaszyfrowaniu) podążał ścieżkami routingu sieci podkładowej
 Architektura szyfrowania dla potrzeb SZK powinna również móc być
wykorzystana w celu szyfrowania innych usług transmisji danych
6

Wymagania techniczne pacjenta
 Niezawodność – każde województwo musi
działać autonomicznie w przypadku awarii
 System ma być skalowalny
– musi obsłużyć kilkadziesiąt tysięcy lokalizacji
 Trzeba obsłużyć wiele różnych typów
routerów wykorzystywanych w systemie
SZK operatora oraz w jako bramy głosowe
użytkowników
- (Cisco 38xx, 29xx, 39xx, 7200, ASR)
 Możliwość dołączenia bram głosowych non-Cisco
7

Zaprojektowana architektura szyfrowania
Systemu Zintegrowanej Komunikacji
 Decyzja: szyfrowanie realizowane będzie przez gatekeepery i bramy głosowe
8

9
NASZE
NARZĘDZIE

10
 GETVPN (Group Encrypted Transport VPN)
 Szyfrowanie beztunelowe
 W przeciwieństwie do klasycznego IPSec, GETVPN nie zestawia tuneli
- możliwa jest wymiana ruchu między więcej niż dwoma routerami (w obrębie całej
grupy routerów)
 Ergo: bezproblemowe szyfrowanie multicastów
 Zewnętrzny nagłówek IPSec ma te same adresy, co oryginalne adresy IP
- routing pakietów odbywa się tymi samymi drogami, co ruchu cleartext
 Wspiera PKI
 Kluczowy element decyzyjny przy wyborze tej technologii
 Technologia Cisco, ale oparta na RFC 3547 (The Group Domain of
Interpretation) – są podobne rozwiązania, np. Group VPN Junipera
 Ponadto: obsługa wielu niezależnych grup, wsparcie dla VRF
Nasze narzędzie: GETVPN

11
 Technologia scentralizowana
 Key Server (KS)
 Control plane (centralna inteligencja)
 Ustala polityki, generuje klucze, rejestruje GM
 Group Member (GM)
 Data plane, (rozproszona siła szyfrowania)
 Klient rejestrujący się do KS
 Jak to działa - w skrócie
 1. Rejestracja GM w KS
 2. KS wysła GM klucze i polityki
 3. KS cykliczne ponownie wysyła klucze (proces rekey)
GETVPN
- przypomnienie lub zapoznanie

12
GETVPN
- przypomnienie lub zapoznanie
Group
Member
Group
Member
Group
Member
Group
Member
Key Server
„Zwykłe
routery”
Centralna polityka grupy
Key Encryption Key
(KEK)
Traffic Encryption Key
(TEK)

Jak wygląda pakiet w GETVPN?
 Zewnętrzny nagłówek zachowuje oryginalne adresy IP i DSCP
 ESP z nieistotnym Sequence Number
 Narzut prawie* ten sam co przy standardowym IPSec Tunnel Mode
 *Opcjonalnie Time-Based Anti-Replay (TBAR)
 Funkcjonalność zastępująca brakujący ESP Sequence Number
 Dodatkowe 12 bajtów
 Protocol 99 (IANA „ Any private encryption scheme”)
10.1.1.4 10.1.2.32
Group Member Group MemberRouter Router
crypto-mapa
13

Pakiety w GETVPN – z TBAR i bez
Enkapsulacja bez TBAR
10.1.1.4 10.1.2.32
Dane IP
10.1.1.4 10.1.2.32
Dane IP
10.1.1.4 10.1.2.32
Nagłówek ESP (SPI)
Stopka ESP
10.1.1.4 10.1.2.32
Dane IP
Enkapsulacja z TBAR
10.1.1.4 10.1.2.32
Dane IP
10.1.1.4 10.1.2.32
Dane IP
10.1.1.4 10.1.2.32
Dane IP
Stopka ESP
Cisco Meta Data
Znacznik
czasowy
7 3 9
4
5
7 4 0
2
3
Znacznik
czasowy
10.1.1.4 10.1.2.32
14

TBAR – zasada działania
Znacznik czasowy
ESP/SPI
TEK Deszyfracja
porównaj
Koszpasuje? ID
Kosz
Wyślij
zbyt
wcześnie
lub zbyt
późno
Nie!
7 4 0
2
3
10.1.1.4 10.1.2.32
Dane IP
Stopka ESP
Cisco Meta Data
10.1.1.4 10.1.2.32
10.1.1.4 10.1.2.32
Dane IP
15
Tak!
OK!

16
Wiele KS – wydajność i niezawodność
Group
Member
Group
Member
Primary KS
„Zwykłe
routery”
COOP
(Cooperative Protocol)
Group
Member
Secondary KS
 Primary KS (jeden)
 Wybierany spośród KS w grupie
 Generuje i dystrybuuje klucze
 Secondary KS (wiele)
 Monitoruje Primary
 Powiadamia go o nowych GM
 Funkcje wspólne: rejestrowanie GM

Primary Secondary
Secondary
Group Member
Group Member
Wiele KS – wydajność i niezawodność
GET VPN
Key Server Key Server
Key Server
17
COOP
Klucze i polityki
Rejestracja

Proces rekey - multicastowy
 Łatwiejszy albo trudniejszy niż unicastowy
t-360
…
t0
t-30t-180
t-420t-3600
… …
Retry = 1, Interval = 60 sec
10 % 5 %
18

Proces rekey - unicastowy
t-360
…
t0
t-30t-180
t-420t-3600
… …
Retry = 1, Interval = 60 sec
10 % 5 %
 Łatwiejszy albo trudniejszy niż multicastowy
19

ATM Systemy Informatyczne S.A.
ip access-list extended ACL_EXCEPTIONS
deny ip host 192.168.1.14 host 192.168.1.13
deny tcp host 192.168.1.14 eq ssh any
crypto map CMAP 10 gdoi
set group GET_WAN
match address ACL_EXCEPTIONS
interface Serial0/0
ip address 192.168.1.14 255.255.255.252
crypto map CMAP
Konfiguracja GM – dość banalna
Przypięcie crypto-mapy do interfejsu
Powiązanie crypto-mapy z GETVPN
Konfiguracja lokalnych wyjątków
Konfiguracja powiązania z grupą GETVPN
20
crypto gdoi group GET_WAN
identity number 3333
server address ipv4 <ks1_address>
server address ipv4 <ks2_address>

ip access-list extended CRYPTO_ACL <- ENCRYPTION POLICY
deny udp any eq 848 any eq 848 <- ALLOW GDOI
permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 <- UNICAST
permit ip 10.0.0.0 0.255.255.255 232.0.0.0 0.255.255.255 <- MULTICAST
ip access-list extended ACL_MEMBERS <- GM AUTH LIST
permit <ks_peer_address> <- PEER KS
permit <gm_address> <- GROUP MEMBER
crypto gdoi group GET_WAN
identity number 3333 <- GROUP ID
server local <- KEY SERVER
rekey retransmit 40 number 3 <- REKEY RETRANSMITS
rekey authentication mypubkey rsa my_rsa <- KS MSG AUTHENTICATION
authorization address ACL_MEMBERS <- GROUP MEMBER AUTHORIZATION
sa ipsec 1 <- SECURITY ASSOCIATION
profile gdoi-p <- CRYPTO ATTRIBUTES SELECTION
match address ipv4 CRYPTO_ACL <- ENCRYPTION POLICY LAN-to-LAN
no replay <- NO ANTI-REPLAY
address ipv4 <ks_address> <- KS ADDRESS
Konfiguracja KS – też niezbyt trudna
21
Definicja polityki szyfrowania w grupie
Definicja członków grupy którzy mają prawo się dołączać
Definicja grupy GETVPN

22
 Key Server - routery Cisco serii
 28xx, 38xx, 29xx, 39xx, 7200, (od jakiegoś czasu również ASR1000)
 Group Member - routery Cisco serii
 87x
 28xx, 38xx, 29xx, 39xx, 7200
 ASR1000
Sprzęt dla GETVPN

23
PACJENT
KONTRA
NARZĘDZIE

871
1841 / AIM
2851 / AIM
3845 / AIM
3945
150 M 600 M300M 450 M 750 M 900 M
3825 / AIM
2951
1941
24
Pacjent kontra narzędzie
- Problem 1: wydajność GMów (ISR)
JEST OK
IMIX, 70% CPU

0.500 G 2.0 G1.0 G 1.5 G
7200
G1/
VAM2+
IMIX, 70% CPU
7200
G2/
VAM2+
7200
G2/VSA
ASR1000 ESP10
ASR1000 ESP5
2.5 G 3.0 G
ASR1000 ESP20
25
- Problem 1: wydajność GMów (nie-ISR)
JEST OK

- Problem 2: uwarunkowania KS
PSK:
150 s/okno * 30 rej/s = 4500 rej/okno
Dla 3000 GM wymagany jest minimum 1 KS
PKI:
150 s/okno * 12 rej/s = 1800 rej/okno
Dla 3000 GM wymagane są minimum 2 KS
26
 Problem bardziej złożony, zależy od:
 Liczby GMów per jeden KS
 Czasu życia klucza TEK (domyślnie 3600s)
 Wymaganej liczby rejestracji na sekundę (zależna od platformy oraz PSK/PKI)
 Wymaganej liczby rekey na sekundę (dla unicast rekey)
 Przykład: 3000 GMów, domyślny czas klucza TEK, okno rejestracji 150 sek,
platforma wspiera 30 rejestracji/s dla PSK i 12 rejestracji/s dla PKI
Typowo liczone okno rejestracji:
OKNO_REJ = TEK_LIFETIME * 5% - 30s

Problem 2
- wydajność KS dla różnych systemów
200 800400 600
Maks. rekomendowana liczba GM w grupie
1000100 2000
2900, PKI
2851, PSK
3845, PSK
Maksymalna wydajność:
7200+VSA PSK = 100 rejestracji /s
7200+VSA PKI = 12 rejestracji /s
3900 PSK > 80 rejestracji /s
3800 PSK = 16 rejestracji /s
2800 PSK = 6 rejestracji /s
3825, PSK
2821, PSK
1841, PSK
5000
7200, PKI
7200, PSK
27
Wybieramy 7201
ale nie jest dobrze…

1000 40002000 3000
1 KS
5000500250
PSKPKI
8 KS
4 KS
2 KS
Obciążenie KS: 33 rejestr/s LF: 33 / 100 = 33%
Obciążenie KS: 16 rejestr/s
LF: 16 / 100 = 16%
1 KS Obciążenie KS: 33 rejestr/s LF: 33 / 12 = 270%
2 KS Obciążenie KS: 16 rejestr/s LF: 16 / 12 = 139%
TEK
3600
2 KS Obciążenie KS: 7.3 rejestr/s LF: 7.3 / 12 = 60%
LF: 4 / 12 = 33%
LF: 2 / 12 = 17%
Obciążenie KS = #GM / Okno_rej / #KS
TEK
3600
TEK
7200
28
Problem 2
- analiza per przykładowa grupa, dla C7200
7200+VSA: PSK - 100 rejestracji /s, PKI = 12 rejestracji /s
LF: Load Factor

Problem 2:
- wielkość grupy GETVPN
29
 Zademonstrowana w testach wielkość grupy VPN to 5000 GMów
- daleko poniżej wymaganej skalowalności sieci
 Współczynnik obciążenia KS (Load Factor) rośnie wraz ze wzrostem grupy
 Możemy go obniżyć przez wydłużenie timerów TEK i okna rejestacji
 Oraz zwiększenie liczby KSów per grupa GET
 Ale w jednej grupie może być tylko do 8 współpracujących KSów
(a w niektórych wersjach oprogramowania nawet 7)
 Rozproszenie geograficzne jednej dużej grupy może skutkować problemami
przy awariach (scenariusz split / merge grupy GET)
Ups… może zaparkujmy temat

30
 Multicast
 Potencjalnie większa skalowalność rozwiązania
 Wymaga budowy sieci multicastowej
 Jeśli nie ma VRF-Aware GDOI, multicasty muszą krążyć w sieci użytkownika
 Unicast
 Potencjalnie mniejsza skalowalność rozwiązania
 Bezproblemowy od strony routingu
- Problem 3: sposób realizacji rekey
Wstępnie wybieramy unicast

31
 W zasadzie nie było wyboru
 Skala systemu
 Silna presja przyszłego operatora na użycie PKI
 Konieczność dołączania do VPN urządzeń zewnętrznych użytkowników
(kwestie operacyjne)
 Wsparcie w GETVPN autoryzacji również dla PKI
 Niespodzianka: brak wsparcia PSK w GETVPN w ASR1000 (wówczas)
- Problem 4: To PKI or not to PKI?
Decyzja: na 100% będzie PKI

32
 Metoda 1 – osobne KS dla osobnych VPNów
 Wspierana nakładająca się adresacja
 Niezbyt efektywna kosztowo (KSy się mnożą razem z VPNami)
 Prosta konfiguracja sieci, większe bezpieczeństwo
PE
VRF: Orendż
VRF: Grin
VRF: Orendż
PE
VRF: Grin
Polityka Orendż
Grupy KS GM
GM
GM
GM
KS
Orendż
KS
Grin
Polityka Grin
Grupy KS
- Problem 5: jak obsłużyć wiele VPNów?

33
- Problem 5: jak obsłużyć wiele VPNów?
VRF: Orendż
VRF: Control
PE PE
VRF: Grin
Polityka Orendż
Polityka Grin
Grupy KS GM
GM
GM
GM
KS
 Metoda 2 – KS współdzielone między VPNami
 Adresacja musi być globalnie spójna
 Efektywne wykorzystanie KSów
 Konieczność zapewnienia bezpiecznej wymiany ruchu między VPNami
Wybieramy 2

IVRF-1
IVRF-2
crypto mapa
crypto mapa
34
- Problem 6: VPN - a co z VRFami?
 Prawdopodobnie będzie potrzeba „zaGETować” kilka VRF per pudełko
 Można w jednym pudełku używać GETVPN z VRF, przy kilku założeniach
 Terminologia
 FVRF (Front-door VRF) – strona niebezpieczna
 Inside VRF (IVRF) – strona zabezpieczana
 GETVPN i VRF-Lite
 Wejście i wyjście muszą być w tym samym VRF
 Osobne crypto-mapy na interfejsach
 Ruch nie może przeciekać między VRFami
Jest OK

35
- Problem 7: VRFy a rejestracja do grup
 Dwie wspierane opcje
 Klasyczne GDOI
 Osobne tożsamości per VRF
 Rejestracja z tego samego VRFu co grupa
 VRF-Aware GDOI
 Wspólna tożsamość dla VRFów
 Rejestracja z osobnego VRFu, wspólnego
dla wszystkich grup
 Ta sama tożsamość IKE – autoryzacja
nie grupy, ale urządzenia
 ASR1000 nie wspiera(ł) tej opcji
IVRF-1
IVRF-2
FVRF
crypto mapa Orendż
crypto mapa Grin
tożsamość współdzielona
IVRF-1
IVRF-2
FVRF
crypto mapa Orendż
crypto mapa Grin
tożsamość
Orendź
tożsamość
Grin
Opcja klasyczna

36
 Podsumowując: wymagania naszego pacjenta, warunki
brzegowe i niuanse technologiczne są częściowo nieco
wzajemnie sprzeczne ze sobą
 Wymagana skalowalność całości jest daleko mniejsza niż
udowodnione możliwości pojedynczej grupy (5000 GMów)
 Konieczność użycia PKI znacząco obniża wydajność KSów
 Ograniczony budżet wymaga ograniczenia liczby KSów, co wraz z niższą ich
wydajnością mocno obniża teoretyczną skalowalność grupy.
 Brak VRF-Aware GET powoduje konieczność zapewnienia wymiany ruchu
między VPNami KSów i wieloma VPNami GMów
 Liczba punktów wymiany ruchu między VPNami jest skończona i mniejsza niż
liczba województw (co łamie warunek autonomii pojedynczego województwa)
- Problem 8: jak to zebrać do kupy?
Pfffff…..

37
PRZEBIEG
OPERACJI

38
Architektura naszego systemu szyfrowania
 Mimo tych wszystkich trudności - będzie szyfrowanie GETVPN !
 Udało się zaprojektować architekturę, która godzi sprzeczne wymagania
 Podział na domeny wojewódzkie
 Osobne grupy GET per województwo
 Dla obejścia ograniczeń skalowalności GET, wykorzystane będzie
reszyfrowanie pomiędzy domenami
 Centrala domena dla 6 centralnych węzłów
(kwestie wydajnościowe oraz architekturalne)
 Reszyfrowanie między domenami realizowane będzie przez redundantne i
niezależne huby kryptograficzne
 W labie przetestowano brak wpływu reszyfrowania na szczególnie wrażliwy ruch

39
Architektura systemu
- huby kryptograficzne
 Huby kryptograficzne
 Wdrożone zostaną 34 rozproszone (po dwa redundantnie w każdym „województwie”)
huby kryptograficzne, zapewniające reszyfrowanie ruchu Systemu Zintegrowanej
Komunikacji między poszczególnymi domenami
 Huby kryptograficzne będą mogły również terminować klasyczne (IPSec) i mniej
klasyczne (np. DMVPN) połączenia od urządzeń niewspierających GETVPN
 Możliwość reutylizacji tej koncepcji
 Będzie mogła być wykorzystywana przy obsłudze ruchu w innych VPNach
 (ale z wykorzystaniem osobnych routerów reszyfrujących)

40
 Wykorzystanie „koni roboczych”, czyli ASR1000
 Bardzo wydajne CPU na Route Procesorze
 Bardzo wydajna sprzętowa (ESP)
obróbka pakietów oraz szyfrowanie
 Pełnią funkcję routera usługowego sieci operatora
 CPU jest już wykorzystywane w sieci na potrzeby
Control Plane (route-reflectory dla potrzeb BGP)
 Reszyfrowanie GETVPN jest funkcją Data Plane
– dociążając je, efektywnie wykorzystujemy wszystkie komponenty routera

41
 Hub kryptograficzny jako podwójny GM
VRF: UC
PE1
Hub Crypto
Polityka UC1
Grupy KS
KS1
PE2
VRF: UC1
PE1
PE2
VRF: UC2
KS2
Hub Crypto
Polityka UC2
Grupy KS
VPN Control
GM UC1
GM
UC1
GM
UC2

42
- serwery kluczy
 Serwery kluczy
 17 KSów, po jednym serwerze kluczy w każdym „województwie”
- zapewniona niezależność geograficzna
 Każdy KS obsługuje wszystkie konieczne grupy VPN
 Połączone zostaną logicznie w grupy wspierające się wzajemnie
– skalowalność i redundancja
 Połączenie przez COOP (5x KS w grupie centralnej, pozostałe parami
– nie przekraczamy ograniczenia 8 KS per grupa )
 Każdy KS będzie obsługiwał wszystkie grupy w „swoje” i wszystkie „sąsiada”
 Spójność polityk między „swoim” a „sąsiadem”

43
- serwery kluczy
 Serwery kluczy
 Każdy GM rejestruje się przede w swoim „lokalnym” KSie
 W przypadku awarii „lokalnego”, rejestruje się „u sąsiada”
KS-W1 KS-W2
Polityka VPN A
Polityka VPN B
…
Polityka VPN Z
Grupy KS-W1
Polityka VPN A
Polityka VPN B
…
Polityka VPN Z
Grupy KS-W2
Polityka VPN A
Polityka VPN B
…
Polityka VPN Z
Grupy KS-W2
Polityka VPN A
Polityka VPN B
…
Polityka VPN Z
Grupy KS-W1
VPN A GMGM GM GM

44
- PKI
 Dla potrzeb szyfrowania SZK wykorzystywana jest jedynie część systemu PKI
 Wykorzystanie IOS Certificate Authority na dedykowanych do potrzeb PKI
niezbyt dużych routerach (w zupełności wystarczą)
 Hierarchiczna, scentralizowana, niezawodna struktura
 Root CA (zakopany głęboko pod ziemią)
 Sub-CA systemu SZK (redundantne, Active-Standby)
 RA systemu SZK (redundantne, Active-Standby)
 Dedykowane serwery do publikacji CRL oraz jako magazyny certyfikatów
(flashe routerów nie nadają się do trzymania dziesiątek tysięcy plików)
 Redundancja dzięki IOS CA High Availability
 Klienci systemu PKI: wszystkie KS oraz wszystkie GM

45
- PKI
 Dostęp klientów PKI do systemu protokołem SCEP (Simple Certificate
Enrollment Protocol)
 Klienci PKI mają dostęp tylko i wyłącznie do RA, jest on kontrolowany
poprzez firewalle - CA są schowane w głębi sieci
 Zatwierdzenie certyfikatów na RA zawsze manualne, przez operatora
 Odpowiednie procedury eksploatacyjne
 Również dla okresowego re-enrollmentu
 Magazyn certyfikatów dostępny poprzez TFTP na dedykowanym serwerze
(tylko TFTP potrafi w czasie rzeczywistym ściągnąć na router listę
wystawionych certyfikatów, rząd wielkości wydajniejszy niż np. FTP)
 Autoryzacja dostępu do danej grupy na podstawie części pola DN certyfikatu

 Przykład: sposób dostępu telefonu IP do klastra CUCM w innym województwie
46
Architektura w działaniu

47
 Ruch między GMami, a KSami NIE JEST kontrolowany firewallami
 Dostęp GMów do Ksów musi być niezawodny, niezależnie od stanu sieci
 Wymagana autonomia województw (nie mamy firewalla w każdym węźle)
 Znajdźcie mi firewalla, który potrafi kontrolować UDP/848, czyli GETVPNowe IKE :-)
 Wymiana ruchu następuje poprzez „przeciekanie” na PE prefiksów VPNv4
między odpowiednimi VPNami
 Loopbacki KSów i GMów muszą się widzieć (ale tylko tych dla odpowiednich domen
grup GETVPN i tylko między odpowiednimi województwami)
 GMy między różnymi VPNami nie mogą się widzieć
 Podsieci inne niż loopbacki też nie mogą się widzieć
 Konfiguracja różna w zależności od kategorii danego węzła
 Proste ACLki zabezpieczające dostęp do KSów
Szaleństwo Route-Targetów

48
 Odpowiednia konfiguracja eksportu / importu
Route-Targetów (statyczne i route-mapy)
 Tworzy składankę topologii a’la hub-and-spoke
 Skonfigurowane w dużej skali projektu
TYLKO dzięki szablonom
 W pracy operacyjnej dające się zarządzać
również ręcznie
Szaleństwo Route-Targetów
PE1
VRF VG_B1
65112:XXXB1
VRF UC_B1
65112:XXXB1
PFX_UCB1_LOOP
65112:XXXB2
VRF CONTROL_B1
65112:XXXB1
65112:XXX
PFX_UCB1
65112:XXXB1
PFX_UCB1
65112:XXXB1
PFX_UCB1
65112:XXXB1
PFX_UCB1
65112:XXXB1
PFX_UCB1
65112:XXXB1
PFX_CTRB1_KS
65112:XXXB2
VRF ADMIN_B1
65112:XXXB1
65112:XXX
PFX_CTRB1_KS
65112:XXXB2
PFX_UCB1_LOOP
65112:XXXB2
PFX_UCB1
65112:XXXB1
VRF UCB2
65112:XXXB2
VRF VGB2
65112:XXXB2
VRF CONTROLB2
65112:XXXB2
65112:XXX
VRF ADMINAX
65112:XXXAX
65112:XXX
PFX_UCB1_LOOP
65112:XXX11
KS
GK
KS
GK
VG
VG
ROUTE
MAP
ROUTE
MAP
ROUTE
MAP

49
 Równoważenie obciążenia KS w większej grupie zapewnia konfiguracja
 GM rejestruje się zawsze do pierwszego skonfigurowanego, działającego KSa
 Wszystkie GMy w danej grupie mają skonfigurowany ten sam zestaw KSów,
ale w różnej kolejności
 Kolejność KSów w konfiguracji ustalana przez hash numeru węzła lub lokalizacji
- takie rzeczy możliwe są tylko dzięki szablonom konfiguracji
 Użycie do tego celu szablonów konfiguracji generowanych w Excel
(zapraszam na moją drugą prezentację podczas PLNOG9)
Jak to skonfigurować?
crypto gdoi group GET_UC
server address ipv4 280.390.216.11
!
crypto gdoi group GET_UC
!
konfiguracja GMa ‘m’ konfiguracja GMa ‘n’

50
Tak, to działa!
Dziękuję!

PLNOG 9: Robert Ślaski - SKALOWALNE SZYFROWANIE USŁUG W SIECI OPERATORA - przykład wdrożenia

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to PLNOG 9: Robert Ślaski - SKALOWALNE SZYFROWANIE USŁUG W SIECI OPERATORA - przykład wdrożenia

Similar to PLNOG 9: Robert Ślaski - SKALOWALNE SZYFROWANIE USŁUG W SIECI OPERATORA - przykład wdrożenia (20)

PLNOG 9: Robert Ślaski - SKALOWALNE SZYFROWANIE USŁUG W SIECI OPERATORA - przykład wdrożenia