Instrukcja dla studenta:
Zadania laboratoryjne należy wykonać w emulatorze GNS3 lub EVE-NG z wykorzystaniem obrazów Cisco IOS, MikroTik RouterOS (CHR) oraz maszyn wirtualnych Linux (np. Docker lub VirtualBox). Sprawozdanie musi zawierać: treść zadania, szczegółowy opis wykonania z uzasadnieniem technologicznym, zrzuty ekranu topologii i konfiguracji, kody konfiguracyjne urządzeń, zestawienie napotkanych problemów oraz merytoryczne wnioski końcowe.

Spis zagadnień laboratoryjnych

  1. Podstawy diagnostyki i transportu IP w GNS3
  2. Emulacja dostępu szerokopasmowego PPPoE/DSL
  3. Konfiguracja szkieletu MPLS i dystrybucja etykiet (LDP)
  4. Implementacja usług L3VPN VRF Lite i MP-BGP
  5. Sieci rozciągnięte L2VPN (VPLS) w środowisku heterogenicznym
  6. Inżynieria ruchu MPLS-TE i ochrona łączy (Fast Reroute)
  7. Emulacja łączy TDM/E1 nad siecią pakietową (TDMoIP/SAToP)
  8. Logiczna struktura transportu GPON (VLAN Staging & QoS)
  9. Zabezpieczanie transportu – IPSec over MPLS VPN
  10. Diagnostyka MTU i optymalizacja MSS w stosie transportowym
01
Podstawy diagnostyki i transportu IP w GNS3
Podstawa merytoryczna

Część 1 Modele ISO/OSI i TCP/IP, Media transmisyjne, Narzędzia diagnostyczne (ping, traceroute, nslookup).

Scenariusz problemowy

Jako młodszy inżynier sieciowy w firmie telekomunikacyjnej otrzymałeś zadanie przygotowania środowiska diagnostycznego w emulatorze GNS3. Twoim celem jest połączenie dwóch stacji roboczych Linux poprzez sieć złożoną z trzech routerów Cisco, symulującą infrastrukturę dostawcy usług. Musisz udowodnić, że pakiety IP przepływają poprawnie między odległymi podsieciami, analizując jednocześnie ich drogę oraz czasy odpowiedzi (RTT).

Wymagania techniczne
  • Zbudowanie topologii z 3 routerów Cisco i 2 VM Linux.
  • Konfiguracja interfejsów routera z adresacją IP /30.
  • Implementacja routingu statycznego.
  • Wykorzystanie narzędzia ping do weryfikacji dostępności.
  • Użycie narzędzia traceroute do wizualizacji ścieżki pakietu.
  • Przechwycenie ruchu za pomocą Wireshark.
  • Analiza nagłówka IP pod kątem pola TTL.
  • Konfiguracja adresacji IP na interfejsach routerów i stacjach Linux.
  • Weryfikacja tabeli routingu za pomocą komendy show ip route.
  • Sprawdzenie sąsiedztwa ARP za pomocą komendy show arp.
  • Analiza statystyk interfejsów sieciowych.
  • Testowanie łączności end-to-end z różnych podsieci.
Wskazówki
  1. Traceroute w Linuksie wysyła pakiety UDP, Windows używa ICMP Echo Request.
  2. W Wiresharku szukaj komunikatów ICMP typ 11 (Time Exceeded).
  3. Wartość TTL jest zmniejszana o 1 na każdym routerze.
  4. Gwiazdki (*) w traceroute oznaczają brak odpowiedzi w wyznaczonym czasie.
  5. Ping z opcją -n w Windows określa liczbę pakietów do wysłania.
  6. Ping z opcją -i w Linuksie pozwala ustawić wartość TTL początkową.
  7. Różnice w RTT między hopami wskazują na opóźnienia na poszczególnych łączach.
  8. Pole TTL w nagłówku IP ma wartość maksymalną 255 i jest zmniejszane przez każdy router.
  9. Komenda show ip interface brief służy do szybkiego podglądu statusu interfejsów.
  10. Debug ip icmp może być użyty do szczegółowej analizy komunikatów ICMP.
Wnioski do opracowania

1. RTT (Round Trip Time) to czas od wysłania pakietu ICMP Echo Request do otrzymania odpowiedzi Echo Reply.

2. Gwiazdki (*) w traceroute pojawiają się, gdy router pośredniczący nie odpowiada na czas w ramach oczekiwania.

3. Wartość TTL w IPv4 wynosi maksymalnie 255 i jest zmniejszana na każdym hopie.

4. Routing statyczny wymaga ręcznej konfiguracji tras na każdym routerze i nie skaluje się w dużych sieciach.

5. Komenda ping pozwala na podstawową weryfikację łączności, ale nie wskazuje dokładnej ścieżki pakietu.

6. Traceroute wykorzystuje zróżnicowane wartości TTL do identyfikacji kolejnych hopów na trasie.

7. Analiza RTT pozwala zidentyfikować wolne lub przeciążone łącza w sieci.

8. Tabela routingu routera Cisco zawiera kody określające źródło pochodzenia trasy (C-connected, S-static, O-OSPF).

9. Protokół ICMP jest niezbędny do diagnostyki sieci, ale może być blokowany przez firewall.

10. Wireshark pozwala na szczegółową analizę pakietów, w tym nagłówków ICMP, IP i Ethernet.

Przykładowe polecenia CLI
! Konfiguracja interfejsów na routerze R1 R1# configure terminal R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip address 192.168.1.1 255.255.255.0 R1(config-if)# description LAN_TO_PC1 R1(config-if)# no shutdown R1(config-if)# exit ! Konfiguracja interfejsu WAN R1(config)# interface Serial0/0/0 R1(config-if)# ip address 10.0.12.1 255.255.255.252 R1(config-if)# description WAN_TO_R2 R1(config-if)# no shutdown R1(config-if)# exit ! Konfiguracja routingu statycznego R1(config)# ip route 192.168.2.0 255.255.255.0 10.0.12.2 R1(config)# ip route 192.168.3.0 255.255.255.0 10.0.12.2 ! Zabezpieczenie routera R1(config)# enable secret class R1(config)# line con 0 R1(config-line)# password cisco R1(config-line)# login R1(config-line)# exit ! Weryfikacja konfiguracji interfejsów R1# show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet0/0 192.168.1.1 YES manual up up Serial0/0/0 10.0.12.1 YES manual up up ! Testowanie łączności do hosta w innej sieci R1# ping 192.168.2.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 10/12/15 ms ! Śledzenie ścieżki do hosta R1# traceroute 192.168.3.10 Type escape sequence to abort. Tracing the route to 192.168.3.10 1 10.0.12.2 8 msec 6 msec 5 msec 2 10.0.23.1 12 msec 10 msec 11 msec 3 192.168.3.1 15 msec 14 msec 13 msec ! Weryfikacja tabeli routingu R1# show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS * - candidate default Gateway of last resort is not set C 192.168.1.0/24 is directly connected, GigabitEthernet0/0 C 10.0.12.0/30 is directly connected, Serial0/0/0 S 192.168.2.0/24 [1/0] via 10.0.12.2 S 192.168.3.0/24 [1/0] via 10.0.12.2 ! Weryfikacja tabeli ARP R1# show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.1.1 - c803.6794.0000 ARPA GigabitEthernet0/0 Internet 192.168.1.10 10 0050.56c0.0008 ARPA GigabitEthernet0/0 ! Weryfikacja szczegółowa interfejsu R1# show interfaces GigabitEthernet0/0 GigabitEthernet0/0 is up, line protocol is up Hardware is i82543 (Gigabit), address is c803.6794.0000 (bia c803.6794.0000) Internet address is 192.168.1.1/24 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255
PRZYKŁADOWY SCHEMAT DO ZADANIA
02
Emulacja dostępu szerokopasmowego PPPoE/DSL
Podstawa merytoryczna

Część 5 Sieci telefoniczne (POTS/PSTN), Modulacje (ASK, FSK, QAM), Technologie xDSL, Standardy ADSL/VDSL.

Scenariusz problemowy

Mimo postępu światłowodowego, technologie DSL nadal odgrywają rolę w dostępie do sieci w miejscach o rozwiniętej infrastrukturze miedzianej. Musisz emulować działanie koncentratora usług szerokopasmowych (BRAS) wykorzystując system MikroTik RouterOS.

Wymagania techniczne
  • Uruchomienie MikroTik CHR jako serwera PPPoE.
  • Konfiguracja puli adresów IP (IP Pool) dla klientów DSL.
  • Stworzenie profilu PPPoE z limitami prędkości.
  • Utworzenie lokalnej bazy użytkowników (Secrets).
  • Aktywacja PPPoE Service na interfejsie Ethernet.
  • Konfiguracja klienta PPPoE na Linux.
  • Konfiguracja NAT dla sieci klientów.
  • Ustawienie MSS Clamping w profilu lub firewallu.
  • Konfiguracja Simple Queue dla dodatkowego QoS.
  • Weryfikacja aktywnych sesji PPPoE.
  • Monitorowanie ruchu na interfejsie BRAS.
  • Testowanie połączenia od strony klienta.
Wskazówki
  1. Pamiętaj o dodaniu MSS Clamping w profilu PPPoE.
  2. Sesja PPPoE składa się z fazy Discovery i Session.
  3. Wartość MRU powinna być ustawiana na MTU minus nagłówek PPPoE.
  4. PPPoE używa specjalnego adresu MAC broadcastowego (ff:ff:ff:ff:ff:ff) w fazie Discovery.
  5. Numer sesji PPPoE jest ustalany podczas fazy PADI/PADO.
  6. MTU dla PPPoE zazwyczaj wynosi 1492 bajtów (1500 - 8 nagłówka).
  7. Rate-limit w profilu określa maksymalną przepustowość pobierania i wysyłania.
  8. MPPE (Microsoft Point-to-Point Encryption) może być włączony dla szyfrowania.
  9. Komenda /ppp active pozwala na podgląd aktualnie połączonych klientów.
  10. Masquerade w NAT zastępuje adres źródłowy na adres routera.
Wnioski do opracowania

1. Narzut protokołu PPPoE wynosi 8 bajtów (nagłówek PPPoE + PPP).

2. ADSL oferuje asymetryczną prędkość: wyższa prędkość pobierania.

3. SDSL oferuje identyczne prędkości w obu kierunkach.

4. PPPoE jest protokołem warstwy 2, który enkapsuluje pakiety IP w ramki Ethernet.

5. Faza Discovery służy do wykrycia serwera PPPoE i ustalenia identyfikatora sesji.

6. BRAS (Broadband Remote Access Server) to urządzenie kończące sesje PPPoE od klientów.

7. Profile PPPoE pozwalają na definiowanie różnych poziomów usług dla klientów.

8. MSS Clamping zapobiega fragmentacji pakietów przez ustawienie odpowiedniego MSS w TCP.

9. IP Pool w RouterOS automatycznie przydziela adresy z określonego zakresu.

10. QoS w postaci Simple Queue pozwala na limitowanie przepustowości per klient.

Przykładowe polecenia CLI
! Konfiguracja serwera PPPoE na MikroTik RouterOS [admin@MikroTik] /ip pool add name=dsl-pool range=84.3.98.2-84.3.98.254 ! Dodanie profilu PPPoE z limitami prędkości [admin@MikroTik] /ppp profile add name=dsl-10m local-address=84.3.98.1 remote-address=dsl-pool rate-limit=10M/1M ! Dodanie użytkownika PPPoE [admin@MikroTik] /ppp secret add name=klient1 password=cisco123 profile=dsl-10m service=pppoe ! Aktywacja serwera PPPoE na interfejsie [admin@MikroTik] /interface pppoe-server server add service-name=ISP-PPPOE interface=ether1 default-profile=dsl-10m ! Konfiguracja NAT dla klientów [admin@MikroTik] /ip firewall nat add chain=srcnat action=masquerade out-interface=ether1 ! Weryfikacja aktywnych sesji PPPoE [admin@MikroTik] /ppp active print Flags: R - RADIUS # NAME SERVICE CALLER-ID ADDRESS UPTIME ENCODING 0 klient1 pppoe 00:1C:42 84.3.98.2 00:05:23 MPPE128 ! Weryfikacja sekretów (użytkowników) [admin@MikroTik] /ppp secret print Flags: X - disabled # NAME SERVICE PROFILE REMOTE-ADDRESS CALLER-ID 0 klient1 pppoe dsl-10m 84.3.98.2 00:1C:42 ! Weryfikacja profilów PPP [admin@MikroTik] /ppp profile print Flags: * - default 0 * ; default-encryption name="default-encryption" use-mpls=default default=default-encryption only-one=default 1 ; dsl-10m name="dsl-10m" local-address=84.3.98.1 remote-address=dsl-pool rate-limit="10M/1M" ! Weryfikacja puli adresów [admin@MikroTik] /ip pool print # NAME RANGES 0 dsl-pool 84.3.98.2-84.3.98.254 ! Weryfikacja interfejsów PPPoE [admin@MikroTik] /interface pppoe-server server print Flags: X - disabled 0 ; defconf service-name=ISP-PPPOE interface=ether1 default-profile=dsl-10m ! Monitorowanie ruchu na interfejsie [admin@MikroTik] /interface monitor-traffic ether1 status: running rx-packets-per-second: 145 rx-drops-per-second: 0 rx-errors-per-second: 0 tx-packets-per-second: 89 tx-drops-per-second: 0 tx-errors-per-second: 0 ! Konfiguracja Queue (Simple Queue) dla QoS [admin@MikroTik] /queue simple add name=klient1 target=84.3.98.2/32 max-limit=10M/1M ! Weryfikacja kolejek [admin@MikroTik] /queue simple print Flags: X - disabled, I - invalid, D - dynamic 0 name="klient1" target=84.3.98.2/32 parent=none packet-marks="" direction=both priority=8/8 queue=default-small/default-small limit-at=10M/1M max-limit=10M/1M burst-limit=0/0 ! Dodanie reguły MSS Clamping [admin@MikroTik] /ip firewall mangle add action=change-mss chain=forward new-mss=1400 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1401-65535 out-interface=pppoe ! Weryfikacja NAT [admin@MikroTik] /ip firewall nat print Flags: X - disabled, I - invalid, D - dynamic 0 chain=srcnat action=masquerade out-interface=ether1 log=no log-prefix=""
PRZYKŁADOWY SCHEMAT DO ZADANIA
03
Konfiguracja szkieletu MPLS i dystrybucja etykiet (LDP)
Podstawa merytoryczna

Część 3 MPLS (Multiprotocol Label Switching), Architektura LSR/LER, Operacje na etykietach (Push, Swap, Pop), Protokół LDP.

Scenariusz problemowy

Współczesne sieci szkieletowe (Core) opierają się na technologii MPLS. Twoim zadaniem jest zbudowanie rdzenia sieci złożonego z czterech routerów przekazujących dane za pomocą etykiet.

Wymagania techniczne
  • Stworzenie topologii z 4 routerów Cisco.
  • Konfiguracja interfejsów Loopback.
  • Uruchomienie OSPF jako IGP.
  • Włączenie CEF (Cisco Express Forwarding).
  • Aktywacja MPLS na interfejsach wewnętrznych.
  • Konfiguracja protokołu LDP.
  • Weryfikacja sąsiedztwa OSPF i zbieżności routingu.
  • Sprawdzenie sąsiedztwa LDP za pomocą show mpls ldp neighbor.
  • Analiza tabeli LFIB (Label Forwarding Information Base).
  • Weryfikacja interfejsów z aktywnym MPLS.
  • Testowanie trasowania z wykorzystaniem traceroute z etykietami.
  • Sprawdzenie wpisów CEF dla tras routingowych.
Wskazówki
  1. Identyfikator LDP LSR-ID musi być identyczny z adresem Loopback.
  2. Prawidłowa zbieżność OSPF jest krytyczna dla LDP.
  3. CEF musi być włączony globalnie i na interfejsach.
  4. LDP używa protokołu TCP (port 646) do ustanawiania sesji między LSR.
  5. Komenda mpls label protocol ldp określa protokół dystrybucji etykiet.
  6. Label 3 (implicit null) jest używane dla bezpośrednio podłączonych sieci.
  7. Komenda mpls ldp autoconfig automatycznie włącza LDP na interfejsach OSPF.
  8. Traceroute w środowisku MPLS pokazuje etykiety w nawiasach [MPLS: Label X].
  9. Tabela LFIB łączy etykiety przychodzące z wychodzącymi dla danej trasy.
  10. CEF wymaga włączonego ip cef globalnie przed konfiguracją na interfejsach.
Wnioski do opracowania

1. Nagłówek MPLS składa się z 4-bajtowej etykiety.

2. Pole TTL służy do ograniczania liczby hopów.

3. MPLS jest nazywany "warstwą 2.5".

4. LDP (Label Distribution Protocol) służy do dystrybucji etykiet między routerami LSR.

5. Etykieta MPLS może być zmieniana (swap), dodawana (push) lub usuwana (pop) na każdym hopie.

6. IP przed ruchem MPLS jest enkapsulowany w etykietę MPLS (label stack).

7. CEF (Cisco Express Forwarding) przyspiesza przetwarzanie pakietów przez sprzętowe tablice.

8. OSPF jest wykorzystywany jako IGP do dystrybucji tras w rdzeniu MPLS.

9. Etykieta transportowa LDP jest używana do przesyłania ruchu przez sieć rdzeniową.

10. Label Binding kojarzy prefiks IP z etykietą MPLS.

Przykładowe polecenia CLI
! Włączenie CEF na routerze PE1# configure terminal PE1(config)# ip cef ! Konfiguracja interfejsów Loopback PE1(config)# interface Loopback0 PE1(config-if)# ip address 10.0.0.1 255.255.255.255 PE1(config-if)# exit ! Konfiguracja interfejsów szkieletowych PE1(config)# interface GigabitEthernet0/0 PE1(config-if)# ip address 10.0.12.1 255.255.255.252 PE1(config-if)# mpls ip PE1(config-if)# mpls label protocol ldp PE1(config-if)# no shutdown PE1(config-if)# exit ! Konfiguracja OSPF PE1(config)# router ospf 1 PE1(config-router)# network 10.0.0.1 0.0.0.0 area 0 PE1(config-router)# network 10.0.12.0 0.0.0.3 area 0 PE1(config-router)# mpls ldp autoconfig PE1(config-router)# exit ! Weryfikacja sąsiedztwa OSPF PE1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.0.2 1 FULL/BDR 00:00:38 10.0.12.2 GigabitEthernet0/0 10.0.0.3 1 FULL/BDR 00:00:35 10.0.23.1 GigabitEthernet0/1 ! Weryfikacja sąsiedztwa LDP PE1# show mpls ldp neighbor Peer LDP Ident: 10.0.0.2:0; Local LDP Ident 10.0.0.1:0 TCP connection: 10.0.12.2 - 10.0.12.1 State: Oper; Msgs sent/rcvd: 45/44; Downstream Up time: 00:25:34 LDP discovery sources: GigabitEthernet0/0, Src IP 10.0.12.2 ! Weryfikacja tabeli LFIB PE1# show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 10.0.0.2/32 0 Gi0/0 10.0.12.2 17 Pop tag 10.0.0.3/32 0 Gi0/1 10.0.23.2 18 17 10.0.0.4/32 0 Gi0/0 10.0.12.2 19 Pop tag 192.168.1.0/24 0 Gi0/2 192.168.1.2 ! Weryfikacja interfejsów z MPLS PE1# show mpls interfaces Interface IP Tunnel BGP Static GigabitEthernet0/0 Yes (ldp) No No No GigabitEthernet0/1 Yes (ldp) No No No ! Weryfikacja tabeli routingu PE1# show ip route Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area O 10.0.0.2/32 [110/2] via 10.0.12.2, 00:25:34, GigabitEthernet0/0 O 10.0.0.3/32 [110/2] via 10.0.23.2, 00:25:33, GigabitEthernet0/1 C 10.0.12.0/30 is directly connected, GigabitEthernet0/0 L 10.0.12.1/32 is directly connected, GigabitEthernet0/0 ! Testowanie łączności z etykietami MPLS PE1# traceroute 10.0.0.4 Type escape sequence to abort. Tracing the route to 10.0.0.4 1 10.0.12.2 [MPLS: Label 17 Exp 0] 5 msec 4 msec 4 msec 2 10.0.23.2 [MPLS: Label 18 Exp 0] 8 msec 7 msec 7 msec 3 10.0.0.4 10 msec 9 msec 9 msec ! Weryfikacja CEF PE1# show ip cef Prefix Next Hop Interface 10.0.0.2/32 10.0.12.2 GigabitEthernet0/0 10.0.0.3/32 10.0.23.2 GigabitEthernet0/1 10.0.12.0/30 attached GigabitEthernet0/0 10.0.12.1/32 receive GigabitEthernet0/0 ! Weryfikacja szczegółowa wpisu LFIB PE1# show mpls forwarding-table 10.0.0.4 32 detail Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag tag switched interface 18 18 10.0.0.4/32 0 Gi0/0 10.0.12.2 MAC/Encaps=4/4, MRU=1500, Tag Stack{18} 000000000000000000000000 No output feature available
PRZYKŁADOWY SCHEMAT DO ZADANIA
04
Implementacja usług L3VPN VRF Lite i MP-BGP
Podstawa merytoryczna

Część 3 VPN L3, VRF (Virtual Routing and Forwarding), RD (Route Distinguisher), RT (Route Target), MP-BGP.

Scenariusz problemowy

Firma obsługuje dwóch rywalizujących klientów, którzy używają tej samej adresacji IP. Twoim wyzwaniem jest przesyłanie ich ruchu przez wspólną sieć szkieletową MPLS.

Wymagania techniczne
  • Utworzenie VRF na routerach brzegowych PE.
  • Konfiguracja Route Distinguishers (RD).
  • Konfiguracja Route Targets (RT).
  • Uruchomienie MP-BGP między routerami PE.
  • Redystrybucja tras klienckich do BGP.
  • Przypisanie interfejsów do odpowiednich VRF.
  • Weryfikacja tabel routingu dla poszczególnych VRF.
  • Testowanie łączności przez VRF z komendą ping vrf.
  • Weryfikacja etykiet MPLS dla VPN za pomocą show mpls forwarding-table.
  • Sprawdzenie tras BGP w poszczególnych VRF.
  • Weryfikacja CEF dla poszczególnych VRF.
  • Analiza sesji BGP VPNv4.
Wskazówki
  1. Komenda ping musi być wykonana ze wskazaniem VRF.
  2. Sprawdź czy etykieta transportowa LDP jest poprawnie generowana.
  3. RD unikalnie identyfikuje prefiks VPNv4.
  4. route-target both oznacza eksport i import tras z tego samego VRF.
  5. Komenda ip vrf forwarding musi być wydana przed przypisaniem adresu IP.
  6. BGP VPNv4 wymaga aktywacji w trybie address-family vpnv4.
  7. redistribute connected dodaje bezpośrednio podłączone sieci do VRF.
  8. Komenda show ip vrf pokazuje wszystkie zdefiniowane VRF.
  9. Komenda show ip bgp vpnv4 vrf pokazuje trasy BGP dla określonego VRF.
  10. send-community both jest wymagane do dystrybucji atrybutów RT.
Wnioski do opracowania

1. Route Distinguisher służy do unikalnej identyfikacji prefiksu sieciowego w BGP VPNv4.

2. Route Target kontroluje przepływ tras między VRF.

3. Pakiety w sieci rdzeniowej P nie potrzebują informacji o VPN-ach klientów.

4. VRF (Virtual Routing and Forwarding) izoluje tabele routingu dla różnych klientów.

5. MP-BGP (Multiprotocol BGP) rozszerza BGP o transport adresacji IPv4 i IPv6 w VPN.

6. VPN label (etykieta VPN) identyfikuje konkretny VRF na routerze PE docelowym.

7. Dwóch klientów może używać tej samej przestrzeni adresowej dzięki mechanizmowi RD.

8. L3VPN pozwala na routowanie między sieciami klientów przez sieć dostawcy.

9. PE (Provider Edge) to routery brzegowe obsługujące VRF klientów.

10. Trasy klientów są redystrybuowane z protokołów IGP do BGP VPNv4.

Przykładowe polecenia CLI
! Definicja VRF na routerze PE1 PE1# configure terminal PE1(config)# ip vrf VRF_A PE1(config-vrf)# rd 65000:1 PE1(config-vrf)# route-target both 1:1 PE1(config-vrf)# exit ! Definicja drugiego VRF PE1(config)# ip vrf VRF_B PE1(config-vrf)# rd 65000:2 PE1(config-vrf)# route-target both 2:2 PE1(config-vrf)# exit ! Przypisanie interfejsu do VRF PE1(config)# interface GigabitEthernet0/2 PE1(config-if)# ip vrf forwarding VRF_A PE1(config-if)# ip address 192.168.1.1 255.255.255.0 PE1(config-if)# exit ! Konfiguracja BGP z VPNv4 PE1(config)# router bgp 65000 PE1(config-router)# no synchronization PE1(config-router)# bgp log-neighbor-changes PE1(config-router)# neighbor 10.0.0.3 remote-as 65000 PE1(config-router)# neighbor 10.0.0.3 update-source Loopback0 PE1(config-router)# address-family vpnv4 PE1(config-router-af)# neighbor 10.0.0.3 activate PE1(config-router-af)# neighbor 10.0.0.3 send-community both PE1(config-router-af)# exit-af ! Redystrybucja tras statycznych do BGP dla VRF_A PE1(config-router)# address-family ipv4 vrf VRF_A PE1(config-router-af)# redistribute connected PE1(config-router-af)# exit-af ! Weryfikacja VRF PE1# show ip vrf Name Default RD Interfaces VRF_A 65000:1 Gi0/2 VRF_B 65000:2 Gi0/3 ! Weryfikacja tabeli routingu VRF PE1# show ip route vrf VRF_A Routing Table: VRF_A Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area C 192.168.1.0/24 is directly connected, GigabitEthernet0/2 B 192.168.2.0/24 [200/0] via 10.0.0.3 (PE2), 00:15:22, VPNv4 ! Weryfikacja tras BGP w VRF PE1# show ip bgp vpnv4 vrf VRF_A BGP table version is 3, local router ID is 10.0.0.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 192.168.1.0/24 0.0.0.0 0 32768 ? *>i 192.168.2.0/24 10.0.0.3 0 100 0 ? ! Weryfikacja sesji BGP PE1# show ip bgp vpnv4 all neighbors BGP neighbor is 10.0.0.3, remote AS 65000, internal link BGP version 4, remote router ID 10.0.0.3 BGP state = Established, up for 00:25:34 Address family: VPNv4 Unicast BGP table version 2, Run threshold 15,etable version 2 Index 1, Offset 0, Mask 0x2 Neighbor capabilities: Route refresh: advertised and received Address family IPv4 VRF: advertised and received ! Test ping przez VRF PE1# ping vrf VRF_A 192.168.2.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/22/25 ms ! Weryfikacja CEF dla VRF PE1# show ip cef vrf VRF_A Prefix Next Hop Interface 192.168.1.0/24 attached GigabitEthernet0/2 192.168.2.0/24 10.0.0.3 Tunnel0 ! Weryfikacja etykiet MPLS dla VPN PE1# show mpls forwarding-table vrf VRF_A Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 21 Pop tag 192.168.1.0/24 0 Gi0/2 192.168.1.10 22 23 192.168.2.0/24 0 Gi0/0 10.0.12.2
PRZYKŁADOWY SCHEMAT DO ZADANIA
05
Sieci rozciągnięte L2VPN (VPLS) w środowisku heterogenicznym
Podstawa merytoryczna

Część 3 VPN L2, VPWS, VPLS, Pseudowire (PW), Bridging over MPLS.

Scenariusz problemowy

Klient korporacyjny potrzebuje połączyć swoje dwie serwerownie w taki sposób, aby wyglądały jak podłączone do tego samego fizycznego switcha (warstwa 2).

Wymagania techniczne
  • Zapewnienie działającej sieci MPLS z LDP.
  • Konfiguracja interfejsu Bridge na MikroTik.
  • Konfiguracja tunelu VPLS.
  • Ustawienie identycznego VPLS-ID po obu stronach.
  • Konfiguracja Bridge na Cisco lub MikroTik po obu stronach.
  • Dodanie portów Ethernet i VPLS do Bridge.
  • Weryfikacja statusu VPLS (stan ESTABLISHED).
  • Sprawdzenie tabeli MAC na Bridge.
  • Testowanie łączności L2 między lokacjami (arping).
  • Monitorowanie statystyk interfejsu VPLS.
  • Weryfikacja L2VPN VFI i Pseudowire na Cisco.
  • Sprawdzenie adresacji MAC po obu stronach tunelu.
Wskazówki
  1. VPLS jest bardzo wrażliwy na MTU.
  2. VPLS-ID musi być identyczny po obu stronach.
  3. Ruch Broadcast jest replikowany do wszystkich tuneli VPLS.
  4. Pseudowire (PW) to wirtualny obwód L2 łączący dwa endpointy VPLS.
  5. remote-peer w MikroTik określa adres IP drugiego końca tunelu.
  6. MTU na interfejsie VPLS powinno być ustawione z uwzględnieniem enkapsulacji MPLS.
  7. Ruch unicast jest kierowany na podstawie tabeli MAC.
  8. Komenda /interface vpls monitor pozwala na podgląd statystyk VPLS.
  9. Komenda show l2vpn vfi sprawdza status VFI (Virtual Forwarding Instance) na Cisco.
  10. Bridge w VPLS łączy ruch z sieci LAN z tunelem VPLS.
Wnioski do opracowania

1. L2VPN (VPLS) różni się od L3VPN tym, że przesyła ramki Ethernet w całości.

2. Zalety L2VPN: pełna transparentność L2.

3. Wady L2VPN: brak skalowalności, problemy z MTU.

4. VPLS (Virtual Private LAN Service) emuluje fizyczny switch w warstwie 2.

5. Pseudowire (PW) to tunel przesyłający ramki Ethernet przez sieć MPLS.

6. VPLS wymaga pełnej tabeli MAC wszystkich urządzeń w sieci rozciągniętej.

7. Ruch broadcast i multicast jest replikowany do wszystkich tuneli VPLS w domenie.

8. Ograniczenia skalowalności wynikają z rozmiaru tabeli MAC i ruchu broadcast.

9. VPLS-ID identyfikuje unikalnie domenę VPLS między endpointami.

10. Bridge w VPLS służy do łączenia portów dostępowych z tunelem pseudowire.

Przykładowe polecenia CLI
! Konfiguracja VPLS na MikroTik RouterOS (strona A) [admin@MikroTik-A] /interface vpls add name=vpls-to-b remote-peer=10.0.0.2 vpls-id=100:1 disabled=no ! Konfiguracja Bridge i dodanie portów [admin@MikroTik-A] /interface bridge add name=bridge-l2 protocol-mode=none [admin@MikroTik-A] /interface bridge port add bridge=bridge-l2 interface=ether2 [admin@MikroTik-A] /interface bridge port add bridge=bridge-l2 interface=vpls-to-b ! Weryfikacja statusu VPLS [admin@MikroTik-A] /interface vpls print status Flags: X - disabled, R - running, D - dynamic, E - estr 0 R ;;; VPLS to Site B name="vpls-to-b" mtu=1500 l2mtu=1500 mac-address=XX:XX:XX:XX:XX:XX remote-peer=10.0.0.2 vpls-id=100:1 cur-state="ESTABLISHED" uptime="01:25:34" ! Weryfikacja tabeli MAC na Bridge [admin@MikroTik-A] /interface bridge host print Flags: X - disabled, E - external, I - incomplete # BRIDGE ADDRESS INTERFACE 0 bridge-l2 00:1C:42:11:22:33 ether2 1 bridge-l2 00:1C:42:44:55:66 vpls-to-b 2 bridge-l2 00:1C:42:77:88:99 vpls-to-b ! Konfiguracja VPLS na Cisco (alternatywnie) Cisco# configure terminal Cisco(config)# ip vrf VPLS Cisco(config-vrf)# rd 100:1 Cisco(config-vrf)# exit ! Konfiguracja L2VPN VFI Cisco(config)# l2vpn vfi context VPLS Cisco(config-vfi)# vpn id 100:1 Cisco(config-vfi)# neighbor 10.0.0.2 encapsulation mpls Cisco(config-vfi)# exit ! Konfiguracja Bridge na Cisco Cisco(config)# bridge irp mode Cisco(config)# interface GigabitEthernet0/1 Cisco(config-if)# bridge-group 1 Cisco(config-if)# exit ! Weryfikacja L2VPN VFI Cisco# show l2vpn vfi Legend: RT=Route Target, S=Static, D=Dynamic, B=BGP PW=Peer Interface, VC=Virtual Circuit VFI Name: VPLS VPN ID: 100 Peer Route Dist PW PW States 10.0.0.2 100:1 UP UP ! Weryfikacja PW (Pseudowire) Cisco# show l2vpn pw vcid Legend: UP=Up, DN=Down, BK=Backup Interface Peer VCID Type Status Gi0/2 10.0.0.2 100 VPLS UP ! Weryfikacja tabeli MAC Cisco# show bridge address Bridge domain 1 table: MAC Address Type Age Port 001c.4211.2233 dynamic 120 Gi0/1 001c.4244.5566 dynamic 115 Gi0/2 ! Test ping z hosta A do hosta B (L2) PC-A:~# arping -I eth0 192.168.1.20 ARPING 192.168.1.20 from 192.168.1.10 eth0 Unicast reply from 192.168.1.20 [00:1C:42:77:88:99] 1.234 ms Unicast reply from 192.168.1.20 [00:1C:42:77:88:99] 1.156 ms ! Weryfikacja statystyk interfejsu VPLS [admin@MikroTik-A] /interface vpls monitor vpls-to-b once remote-target: 10.0.0.2 remote-label: 21 local-label: 20 curr-msg-id: 0 last-msg-id: 0 pkt-in: 15234 byte-in: 1456234 pkt-out: 8923 byte-out: 892340
PRZYKŁADOWY SCHEMAT DO ZADANIA
06
Inżynieria ruchu MPLS-TE i ochrona łączy (Fast Reroute)
Podstawa merytoryczna

Część 3 Traffic Engineering, RSVP-TE, Fast Reroute (FRR), Rezerwacja pasma.

Scenariusz problemowy

W sieci szkieletowej najbardziej optymalna ścieżka jest przeciążona. Musisz ręcznie wymusić drogę dla konkretnego strumienia danych, stosując tunele MPLS Traffic Engineering.

Wymagania techniczne
  • Aktywacja RSVP na interfejsach rdzeniowych.
  • Konfiguracja rozszerzeń TE dla OSPF.
  • Utworzenie interfejsu Tunnel-TE.
  • Zdefiniowanie ścieżki jawnej (Explicit Path).
  • Konfiguracja mechanizmu Fast Reroute.
  • Weryfikacja statusu tunelu TE (Admin/Oper).
  • Sprawdzenie opcji ścieżki (path-option) tunelu.
  • Analiza bazy TED (Traffic Engineering Database).
  • Testowanie Fast Reroute poprzez symulację awarii łącza.
  • Konfiguracja routingu statycznego przez tunel TE.
  • Weryfikacja rezerwacji pasma RSVP.
  • Sprawdzenie Available Bandwidth na łączach.
Wskazówki
  1. Funkcje RSVP-TE są ograniczone na niektórych obrazach IOS.
  2. Tunel TE składa się z: path, tunnel i forwarding.
  3. Explicit Path definiuje dokładną trasę tunelu.
  4. RSVP (Resource Reservation Protocol) rezerwuje pasmo dla tunelu TE.
  5. ip rsvp bandwidth określa maksymalne pasmo do rezerwacji na porcie.
  6. CSPF (Constrained Shortest Path First) to algorytm wyznaczający ścieżkę z ograniczeniami.
  7. tunnel mpls traffic-eng fast-reroute włącza ochronę łączy.
  8. path-option 10 określa pierwszą opcję ścieżki, 20 zapasową.
  9. mpls traffic-eng router-id wskazuje ID routera dla TE w OSPF.
  10. tunnel destination to adres IP Loopback routera docelowego.
Wnioski do opracowania

1. CSPF to algorytm routingu wykorzystywany w MPLS-TE.

2. Standardowe protokoły IGP używają prostego algorytmu SPF.

3. MPLS-TE eliminuje ograniczenia IGP przez rezerwację pasma.

Przykładowe polecenia CLI
! Włączenie MPLS TE i RSVP R1# configure terminal R1(config)# mpls traffic-eng tunnels ! Konfiguracja interfejsu dla TE R1(config)# interface GigabitEthernet0/0 R1(config-if)# mpls traffic-eng tunnels R1(config-if)# ip rsvp bandwidth 100000 R1(config-if)# exit ! Konfiguracja OSPF z TE R1(config)# router ospf 1 R1(config-router)# mpls traffic-eng router-id Loopback0 R1(config-router)# mpls traffic-eng area 0 R1(config-router)# exit ! Definiowanie Explicit Path R1(config)# ip explicit-path name PRIMARY-PATH enable R1(config-expl-path)# next-address 10.0.12.2 R1(config-expl-path)# next-address 10.0.23.2 R1(config-expl-path)# exit ! Definiowanie ścieżki zapasowej R1(config)# ip explicit-path name BACKUP-PATH enable R1(config-expl-path)# next-address 10.0.13.2 R1(config-expl-path)# next-address 10.0.34.2 R1(config-expl-path)# exit ! Tworzenie tunelu TE R1(config)# interface Tunnel100 R1(config-if)# ip unnumbered Loopback0 R1(config-if)# tunnel mode mpls traffic-eng R1(config-if)# tunnel destination 10.0.0.4 R1(config-if)# tunnel mpls traffic-eng path-option 10 explicit name PRIMARY-PATH R1(config-if)# tunnel mpls traffic-eng path-option 20 explicit name BACKUP-PATH R1(config-if)# tunnel mpls traffic-eng bandwidth 50000 R1(config-if)# tunnel mpls traffic-eng fast-reroute ! Weryfikacja tunelu TE R1# show mpls traffic-eng tunnels Tunnel100 Destination: 10.0.0.4. Ifindex: 0x84 Status: Admin: up Oper: up Path: valid Signalling: connected Config Parameters: Bandwidth: 50000 Priority: 7 7 AutoRoute: disabled FastReroute: enabled Path Info: Outgoing: Explicit: PRIMARY-PATH Incoming: Explicit: BACKUP-PATH RSVP: Hello enabled ! Weryfikacja ścieżki tunelu R1# show mpls traffic-eng tunnels brief Tunnels configured at this router: Tunnel100 dest 10.0.0.4 role=head path=PRIMARY-PATH status=UP Path options: 1: explicit PRIMARY-PATH (Active) 2: explicit BACKUP-PATH (Standby) ! Weryfikacja bazy TED R1# show mpls traffic-eng topology MPLS TE Topology Database (Area 0) Router ID: 10.0.0.1 Link Count: 4 Link[0]: GigabitEthernet0/0 Nbr ID: 10.0.0.2 TE metric: 10 Bandwidth: Total: 100000 Available: 50000 Attributes: 0x00000003 (BN-) Link[1]: GigabitEthernet0/1 Nbr ID: 10.0.0.3 TE metric: 10 Bandwidth: Total: 100000 Available: 100000 ! Konfiguracja routingu przez tunel R1(config)# ip route 192.168.2.0 255.255.255.0 Tunnel100 ! Weryfikacja Fast Reroute R1# show mpls traffic-eng fast-reroute database Tunnel100: Dest 10.0.0.4 FRR Protection: Available Primary path: PRIMARY-PATH Bypass: Not configured ! Testowanie FRR - symulacja awarii R1# ping 192.168.2.10 repeat 100 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 192.168.2.10, timeout is 2 seconds: !!!!!.!!!!!.!!!!!.!!!!!.!!!!!.!!!!!.!!!!!.!!!!! Success rate is 95 percent (95/100), round-trip min/avg/max = 15/18/22 ms
PRZYKŁADOWY SCHEMAT DO ZADANIA
07
Emulacja łączy TDM/E1 nad siecią pakietową (TDMoIP/SAToP)
Podstawa merytoryczna

Część 4 Sieci SDH, PDH (E1/E3), Hierarchia STM, Emulacja obwodów (Circuit Emulation Service).

Scenariusz problemowy

Klient posiada starą centralę PBX wymagającą styku E1 (2 Mbps). Twoim zadaniem jest przesłanie sygnału TDM przez sieć pakietową IP/MPLS.

Wymagania techniczne
  • Konfiguracja interfejsu kontrolera E1.
  • Stworzenie Pseudowire klasy SAToP.
  • Zdefiniowanie bufora jittera.
  • Mapowanie kanałów TDM do tunelu.
  • Konfiguracja zegara (clock source line lub internal).
  • Weryfikacja statusu kontrolera E1.
  • Sprawdzenie statusu xconnect (pseudowire).
  • Analiza statystyk interfejsu Serial po stronie TDM.
  • Monitorowanie etykiet MPLS dla pseudowire.
  • Konfiguracja Circuit Emulation po stronie RouterOS.
  • Weryfikacja bufora jittera i opóźnień.
  • Testowanie ciągłości sygnału TDM przez sieć pakietową.
Wskazówki
  1. SAToP enkapsuluje bitowy strumień TDM do pakietów IP.
  2. Bufor jittera kompensuje różnice w opóźnieniach sieci.
  3. Źródło zegara w sieciach TDM jest krytyczne.
  4. channel-group 0 unframed tworzy jeden kanał dla pełnego E1 (2.048 Mbps).
  5. clock source line oznacza zegar pochodzący z linii (zdalny).
  6. encapsulation mpls określa transport przez MPLS.
  7. control-word zapewnia poprawną sekwencję bitów w pseudowire.
  8. xconnect łączy interfejs TDM z endpointem pseudowire.
  9. VCID (Virtual Circuit ID) identyfikuje unikalnie pseudowire.
  10. Komenda show xconnect all pokazuje status wszystkich xconnect.
Wnioski do opracowania

1. Sieci TDM działają w trybie synchronicznym.

2. Sieci pakietowe działają asynchronicznie.

3. Wander to powolna zmiana częstotliwości zegara.

4. SAToP (Structure-Agnostic TDM over Packet) enkapsuluje strumień bitowy bez struktury.

5. E1 to standard europejski o przepustowości 2.048 Mbps (32 kanały po 64 kbps).

6. Bufor jittera kompensuje zmienne opóźnienia (jitter) w sieci pakietowej.

7. SAToP wymaga stałego pasma niezależnie od ruchu danych.

8. W przypadku utraty pakietów mogą wystąpić błędy w sygnale TDM.

9. Emulacja obwodów TDM pozwala na migrację legacy systems do sieci IP/MPLS.

10. Synchronizacja zegara jest krytyczna dla poprawnej pracy Circuit Emulation.

Przykładowe polecenia CLI
! Konfiguracja Circuit Emulation na Cisco R1# configure terminal R1(config)# controller E1 0/0/0 R1(config-controller)# channel-group 0 unframed R1(config-controller)# clock source line R1(config-controller)# exit ! Tworzenie pseudowire class R1(config)# pseudowire-class CES-SAToP R1(config-pw-class)# encapsulation mpls R1(config-pw-class)# protocol mpls R1(config-pw-class)# control-word R1(config-pw-class)# exit ! Konfiguracja xconnect R1(config)# interface Serial0/0/0:0 R1(config-if)# xconnect 10.0.0.2 100 pw-class CES-SAToP R1(config-if)# exit ! Weryfikacja kontrolera E1 R1# show controller E1 0/0/0 E1 0/0/0 is up. Channelization is unframed (channel group 0) Framing is CRC4, Line Code is HDB3 Clock Source is LINE No alarms detected Rx(DS1) coding: BIP B1, errors: 0,SEF: 0 Tx coding: BIP B1, errors: 0 ! Weryfikacja pseudowire R1# show xconnect all Legend: XC ST=Xconnect State, S1=Segment1 State, S2=Segment2 State UP=Up, DN=Down, AD=Admin Down, IA=Inactive NH=Not Hosted, Sc=Standby XC ST Segment 1 S1 Segment 2 S2 UP Se0/0/0:0 UP 10.0.0.2(100) UP CES-SAToP mpls ! Weryfikacja szczegółów PW R1# show l2vpn pw Interface Peer VCID Type Status Serial:0/0/0:0 10.0.0.2 100 CES UP Local Label: 24001 Remote Label: 24002 MTU: 1500 Control Word: Enabled ! Konfiguracja RouterOS (strona przeciwna) [admin@RouterOS-B] /interface seth [admin@RouterOS-B] set e1-pw enabled=yes mtu=1500 running=yes comment="SAToP E1" ! Weryfikacja statystyk E1 R1# show interfaces Serial0/0/0:0 Serial0/0/0:0 is up, line protocol is up Hardware is Canal MTU 1500 bytes, BW 2048 Kbit, DLY 200000 usec reliability 255/255, txload 1/255, rxload 1/255 Encapsulation: HDLC, crc 16, loopback not set Keepalive not set Last input never, output never, output hang never Last clearing of "show interface" counters: 00:15:30 ! Konfiguracja bufora jittera R1(config)# pseudowire-class CES-SAToP R1(config-pw-class)# xconnect router-id 10.0.0.1 [admin@RouterOS] /interface e1 set numbers=1 clock-source=internal
PRZYKŁADOWY SCHEMAT DO ZADANIA
08
Logiczna struktura transportu GPON (VLAN Staging & QoS)
Podstawa merytoryczna

Część 2 Sieci Optyczne (PON/GPON), Architektura OLT/ONT, Zasada działania Downstream/Upstream (TDMA), Splittery.

Scenariusz problemowy

Musisz emulować strukturę VLANów i zarządzania pasmem (DBA), jaka występuje między centralą OLT a końcówkami ONT u klientów.

Wymagania techniczne
  • Konfiguracja QinQ (VLAN stacking) na OLT.
  • Przypisanie C-VLANów dla każdego klienta.
  • Konfiguracja Traffic Shaping.
  • Zastosowanie polityki QoS.
  • Tworzenie S-VLAN (Service VLAN) dla emulator GPON.
  • Konfiguracja portu w trybie dot1q-tunnel.
  • Definiowanie class-map dla ruchu głosowego (DSCP EF).
  • Tworzenie policy-map z priorytetem dla VOICE.
  • Zastosowanie service-policy na portach OLT.
  • Konfiguracja traffic-shape na portach dostępowych.
  • Weryfikacja VLANów i portów switchport.
  • Sprawdzenie statystyk QoS i kolejek.
Wskazówki
  1. Użyj switchy z obsługą dot1q-tunnel dla emulacji GPON.
  2. S-VLAN reprezentuje gałąź fizyczną.
  3. Upstream w GPON używa TDMA.
  4. C-VLAN (Customer VLAN) to VLAN klienta przenikający przez sieć dostawcy.
  5. dot1q-tunnel dodaje S-VLAN do ramki z C-VLAN.
  6. DSCP EF (Expedited Forwarding) jest używany dla ruchu VoIP.
  7. priority percent w QoS zapewnia dedykowane pasmo dla ruchu głosowego.
  8. traffic-shape rate ogranicza pasmo na porcie dostępowym.
  9. match protocol rtp identyfikuje ruch głosowy VoIP.
  10. Komenda show policy-map interface weryfikuje polityki QoS.
Wnioski do opracowania

1. TDMA w upstreamzie GPON polega na podziale czasu na ramki.

2. Downstream jest broadcastowy.

3. Szyfrowanie AES-128 w GPON jest obowiązkowe.

4. GPON wykorzystuje architekturę OLT-ONT (Optical Line Terminal - Optical Network Terminal).

5. Splittery optyczne dzielą sygnał downstream na wiele ONT.

6. QinQ (802.1Q-in-802.1Q) pozwala na przenoszenie wielu VLANów klienta przez sieć dostawcy.

7. DBA (Dynamic Bandwidth Allocation) alokuje pasmo upstream na żądanie.

8. Klasy ruchu QoS (VOICE, VIDEO, DATA) zapewniają odpowiednią jakość usług.

9. S-VLAN w emulacji GPON reprezentuje gałąź (branch) do klienta.

10. QoS w GPON zapewnia priorytetowanie ruchu czasowo-krytycznego.

Przykładowe polecenia CLI
! Konfiguracja QinQ na switchu OLT OLT# configure terminal OLT(config)# vlan 100 OLT(config-vlan)# name S-VLAN-PON-1 OLT(config-vlan)# exit ! Konfiguracja portu trunk dla GPON OLT(config)# interface GigabitEthernet0/1 OLT(config-if)# switchport mode trunk OLT(config-if)# switchport trunk allowed vlan 100 OLT(config-if)# exit ! Konfiguracja portu dostępowego dla klientów z QinQ OLT(config)# interface GigabitEthernet0/10 OLT(config-if)# switchport mode dot1q-tunnel OLT(config-if)# switchport access vlan 100 OLT(config-if)# l2protocol-tunnel point-to-point OLT(config-if)# exit ! Tworzenie C-VLANów OLT(config)# vlan 200 OLT(config-vlan)# name KLIENT-A OLT(config-vlan)# exit OLT(config)# vlan 300 OLT(config-vlan)# name KLIENT-B OLT(config-vlan)# exit ! Konfiguracja QoS - klasyfikacja ruchu OLT(config)# class-map match-any VOICE OLT(config-cmap)# match ip dscp ef OLT(config-cmap)# match protocol rtp OLT(config-cmap)# exit ! Definicja polityki QoS OLT(config)# policy-map GPON-QoS OLT(config-pmap)# class VOICE OLT(config-pmap-c)# priority percent 30 OLT(config-pmap-c)# class class-default OLT(config-pmap-c)# bandwidth percent 70 OLT(config-pmap-c)# exit ! Zastosowanie polityki na porcie OLT(config)# interface GigabitEthernet0/1 OLT(config-if)# service-policy output GPON-QoS OLT(config-if)# exit ! Konfiguracja Traffic Shaping OLT(config)# interface GigabitEthernet0/10 OLT(config-if)# traffic-shape rate 100000000 ! Weryfikacja VLANów OLT# show vlan brief VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active 100 S-VLAN-PON-1 active Gi0/1, Gi0/10 200 KLIENT-A active 300 KLIENT-B active ! Weryfikacja interfejsów dot1q-tunnel OLT# show interfaces switchport Interface: Gi0/10 Mode: dot1q-tunnel Access VLAN: 100 Native VLAN: 1 Trunking VLANs: none ! Weryfikacja QoS OLT# show policy-map interface GigabitEthernet0/1 GigabitEthernet0/1 Service-policy output: GPON-QoS Class-map: VOICE (match-any) 1453 packets, 145320 bytes 30 second offered rate 2000 bps priority: 30% Class-map: class-default (match-any) 24534 packets, 3523421 bytes 30 second offered rate 5000000 bps bandwidth: 70%
PRZYKŁADOWY SCHEMAT DO ZADANIA
09
Zabezpieczanie transportu – IPSec over MPLS VPN
Podstawa merytoryczna

Część 1 Bezpieczeństwo Internetu, Część 3 MPLS VPN, IPSec, Szyfrowanie i autoryzacja.

Scenariusz problemowy

Klient bankowy wymaga dodatkowego szyfrowania "end-to-end" na istniejącej strukturze VPN.

Wymagania techniczne
  • Konfiguracja polityki ISAKMP.
  • Zdefiniowanie ACL dla ruchu interesującego.
  • Zastosowanie crypto map.
  • Weryfikacja statusu SA.
  • Konfiguracja transform-set (ESP-AES-SHA).
  • Ustawienie PSK (Pre-Shared Key) dla autoryzacji.
  • Włączenie PFS (Perfect Forward Secrecy) dla dodatkowego bezpieczeństwa.
  • Zastosowanie crypto map na interfejsie zewnętrznym.
  • Konfiguracja keepalive dla monitorowania SA.
  • Weryfikacja ISAKMP SA (Phase 1).
  • Sprawdzenie IPSec SA (Phase 2).
  • Testowanie szyfrowanego połączenia ping.
Wskazówki
  1. Phase 1 ustanawia bezpieczny tunel, Phase 2 chroni dane.
  2. Transform Set definiuje protokoły szyfrowania.
  3. ACL definiuje ruch interesujący.
  4. ISAKMP Policy określa parametry negocjacji Phase 1 (szyfrowanie, hash, grupa DH).
  5. encryption aes lub 3des określa algorytm szyfrowania w Phase 1.
  6. hash sha lub md5 określa algorytm autentykacji wiadomości.
  7. group 2 lub 5 określa grupę Diffie-Hellman dla wymiany kluczy.
  8. lifetime określa czas życia SA Phase 1 (domyślnie 86400 sekund).
  9. Komenda show crypto isakmp sa sprawdza Phase 1 SA.
  10. Komenda show crypto ipsec sa sprawdza Phase 2 SA.
Wnioski do opracowania

1. Szyfrowanie IPSec dodaje znaczny narzut do rozmiaru pakietu.

2. W połączeniu z MPLS wymagane jest odpowiednie MTU.

3. IPSec nad MPLS stosować gdy wymagane przez compliance.

4. IPSec składa się z IKE (Phase 1) i IPSec (Phase 2) do negocjacji i ochrony danych.

5. ESP (Encapsulating Security Payload) zapewnia szyfrowanie i autentykację.

6. AH (Authentication Header) zapewnia tylko autentykację bez szyfrowania.

7. Mode tunnel chroni cały oryginalny pakiet IP nowym nagłówkiem.

8. PFS (Perfect Forward Secrecy) zapewnia nowe klucze dla każdej sesji Phase 2.

9. ISAKMP używa portu 500 do negocjacji IKE.

10. Pre-Shared Key jest używany do autentykacji urządzeń w Phase 1.

11. Crypto map łączy ACL, transform-set i peer dla pełnej konfiguracji IPSec.

12. Narzut IPSec (ESP header + trailer) wynosi około 50-60 bajtów.

13. Debug crypto isakmp pozwala na szczegółową analizę negocjacji IKE.

14. ESP-AES zapewnia strong encryption z algorytmem AES.

Przykładowe polecenia CLI
! Konfiguracja ISAKMP Phase 1 CE1# configure terminal CE1(config)# crypto isakmp policy 10 CE1(config-isakmp)# encryption aes CE1(config-isakmp)# hash sha CE1(config-isakmp)# authentication pre-share CE1(config-isakmp)# group 5 CE1(config-isakmp)# lifetime 86400 CE1(config-isakmp)# exit ! Konfiguracja PSK CE1(config)# crypto isakmp key cisco123 address 84.3.99.2 ! Definiowanie ACL dla ruchu interesującego CE1(config)# ip access-list extended VPN-TRAFFIC CE1(config-ext-nacl)# permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 CE1(config-ext-nacl)# exit ! Konfiguracja Transform Set CE1(config)# crypto ipsec transform-set ESP-AES-SHA esp-aes esp-sha-hmac CE1(cfg-crypto-trans)# mode tunnel CE1(cfg-crypto-trans)# exit ! Konfiguracja Crypto Map CE1(config)# crypto map IPSEC-VPN 10 ipsec-isakmp CE1(config-crypto-map)# match address VPN-TRAFFIC CE1(config-crypto-map)# set transform-set ESP-AES-SHA CE1(config-crypto-map)# set peer 84.3.99.2 CE1(config-crypto-map)# set pfs group5 CE1(config-crypto-map)# exit ! Zastosowanie Crypto Map na interfejsie CE1(config)# interface GigabitEthernet0/0 CE1(config-if)# crypto map IPSEC-VPN CE1(config-if)# exit ! Weryfikacja ISAKMP SA CE1# show crypto isakmp sa dst src state conn-id slot status 84.3.99.2 84.3.99.1 QM_IDLE 1001 0 ACTIVE ! Weryfikacja IPSec SA CE1# show crypto ipsec sa interface: GigabitEthernet0/0 Crypto map tag: IPSEC-VPN, local addr 84.3.99.1 local ident (addr/mask): (192.168.1.0/255.255.255.0) remote ident (addr/mask): (192.168.2.0/255.255.255.0) current_peer: 84.3.99.2 pkts encaps: 5234 pkts encrypt: 5234 pkts digest: 0 pkts decaps: 5102 pkts decrypt: 5102 pkts verify: 0 send cumulative bytes 654234 (654.234 KB) recv cumulative bytes 543210 (543.210 KB) ! Weryfikacja transform set CE1# show crypto ipsec transform-set Transform set {ESP-AES-SHA}: { esp-aes esp-sha-hmac } will negotiate = { Tunnel, }, { esp-3des esp-md5-hmac }, { esp-des esp-md5-hmac } ! Weryfikacja crypto map CE1# show crypto map Crypto Map "IPSEC-VPN" 10 ipsec-isakmp Peer = 84.3.99.2 Extended IP access list VPN-TRAFFIC access-list VPN-TRAFFIC permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 Current peer: 84.3.99.2 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): Y Transform sets={ ESP-AES-SHA: { esp-aes esp-sha-hmac } } ! Test szyfrowanego połączenia CE1# ping 192.168.2.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 25/27/30 ms ! Debug IPSec CE1# debug crypto isakmp ! Otrzymasz szczegółowe informacje o negocjacji IKE
PRZYKŁADOWY SCHEMAT DO ZADANIA
10
Diagnostyka MTU i optymalizacja MSS w stosie transportowym
Podstawa merytoryczna

Część 3 MTU w MPLS, Część 4 MTU w SDH, Fragmentacja IP, MSS Clamping.

Scenariusz problemowy

Użytkownicy zgłaszają problemy z dużymi plikami i stronami WWW. To klasyczny objaw problemów z MTU.

Wymagania techniczne
  • Budowa wielowarstwowego stosu transportowego.
  • Wykrycie problemu za pomocą pingu z bitem DF.
  • Konfiguracja MSS Clamping.
  • Analiza PMTUD.
  • Identyfikacja minimalnego MTU na ścieżce.
  • Konfiguracja ip tcp adjust-mss na routerze.
  • Ustawienie MTU na interfejsie.
  • Weryfikacja interfejsów i ich MTU.
  • Analiza statystyk ICMP (type 3, type 11).
  • Włączenie ip tcp path-mtu-discovery.
  • Konfiguracja MSS Clamping na MikroTik (mangle).
  • Sprawdzenie w Wireshark czy MSS jest ustawiony prawidłowo.
Wskazówki
  1. MSS = MTU - 20 (IP) - 20 (TCP).
  2. MSS Clamping działa tylko na pakiety SYN.
  3. PMTUD automatycznie wykrywa minimalne MTU.
  4. ping -f -l w Windows ustawia DF (Don't Fragment) i rozmiar danych.
  5. ping -M do w Linuksie ustawia flagę DF (dont-fragment).
  6. MTU 1472 + 20 IP + 8 ICMP = 1500 to typowy test Ethernet.
  7. ip tcp adjust-mss wymaga ACL do filtrowania ruchu TCP.
  8. MSS Clamping na MikroTik używa łańcucha prerouting z action=change-mss.
  9. show ip interface pokazuje MTU na interfejsie.
  10. Komenda show ip traffic weryfikuje statystyki ICMP.
Wnioski do opracowania

1. Fragmentacja w warstwie IP to proces dzielenia pakietu.

2. MSS Clamping to optymalizacja w warstwie TCP.

3. Fragmentacja jest unikana w nowoczesnych sieciach.

4. PMTUD (Path MTU Discovery) automatycznie wykrywa minimalne MTU na ścieżce.

5. Bit DF (Don't Fragment) w pakiecie ICMP zapobiega fragmentacji.

6. ICMP typ 3 kod 4 (Fragmentation Needed) jest wysyłany gdy DF jest ustawiony.

7. MSS (Maximum Segment Size) określa maksymalny rozmiar segmentu TCP.

8. Typowy MSS dla Ethernet to 1460 bajtów (1500 - 20 IP - 20 TCP).

9. MSS Clamping modyfikuje pole MSS w nagłówku TCP podczas trwania trójstronnego uścisku dłoni.

10. Problem z MTU objawia się utratą pakietów dla większych payloadów.

11. Ręczne ustawienie MTU na interfejsie rozwiązuje problemy z większymi pakietami.

12. Analiza przechwyconego ruchu w Wireshark pozwala zweryfikować ustawienia MSS.

Przykładowe polecenia CLI
! Testowanie MTU za pomocą pingu z bitem DF (Windows) C:\Users\admin] ping -f -l 1472 192.168.2.10 Pinging 192.168.2.10 with 1472 bytes of data: Reply from 192.168.2.10: bytes=1472 time=10ms TTL=64 ! Test z większym rozmiarem (przekroczenie MTU) C:\Users\admin] ping -f -l 1500 192.168.2.10 Packet needs to be fragmented but DF set. ! Testowanie MTU na Linux admin@linux:~$ ping -M do -s 1472 192.168.2.10 PING 192.168.2.10 (192.168.2.10) 1472(1500) bytes of data. 1480 bytes from 192.168.2.10: icmp_seq=1 ttl=64 time=10.2 ms ! Konfiguracja MSS Clamping na Cisco Router# configure terminal Router(config)# ip tcp adjust-mss 1400 Router(config)# interface GigabitEthernet0/0 Router(config-if)# ip access-group 110 in Router(config-if)# exit ! Konfiguracja ACL dla MSS Clamping Router(config)# access-list 110 permit tcp any any eq www Router(config)# access-list 110 permit tcp any any eq 443 ! Konfiguracja MSS Clamping na MikroTik [admin@MikroTik] /ip firewall mangle add chain=prerouting protocol=tcp tcp-flags=syn action=change-mss new-mss=1400 passthrough=yes in-interface=bridge-lan tcp-mss=1401-65535 ! Weryfikacja interfejsów i MTU Router# show ip interface GigabitEthernet0/0 GigabitEthernet0/0 is up, line protocol is up Internet address is 192.168.1.1/24 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec ! Weryfikacja MSS Clamping Router# show ip tcp adjust-mss TCP option mss adjust is enabled for following interfaces: GigabitEthernet0/0 (inbound) - 1400 ! Analiza PMTUD - przechwytywanie ICMP Router# show ip traffic ICMP: 0 drops, 0 unknown type type 0 echo, 45 echo-reply type 3 destination unreachable, 12 port-unreachable type 11 time-exceeded ! Konfiguracja włączenia ICMP fragmentation-needed Router(config)# ip tcp path-mtu-discovery ! Weryfikacja statystyk interfejsu Router# show interfaces GigabitEthernet0/0 GigabitEthernet0/0 is up, line protocol is up 5 minute input rate 2340000 bits/sec, 342 packets/sec 5 minute output rate 1234000 bits/sec, 234 packets/sec 0 packets input, 0 bytes, 0 no buffer 0 received, 0 dropped 0 packets output, 0 bytes, 0 dropped ! Test po zmianie MTU na interfejsie Router(config)# interface GigabitEthernet0/1 Router(config-if)# mtu 1400 ! Weryfikacja MSS w przechwyconym pakiecie ! W Wireshark filtruj: tcp.options.mss ! Szukaj: tcp.options.mss == 1400 ! Sprawdzenie fragmentacji Router# show ip traffic IP: 3450 total, 2340 delivered 0 fragments, 0 reassembled 0 fragment failures
PRZYKŁADOWY SCHEMAT DO ZADANIA