Testy akceptacyjne Węzeł Kraków

Załącznik C
testy akceptacyjne
Testy akceptacyjne
Węzeł Kraków
Autoryzacja
l.p. Data
1
2
3
4
Imię i Nazwisko
Stanowisko
Podpis
Cel stworzenia dokumentu
Wykonanie procedur testowych ma za zadanie weryfikację prawidłowości pracy sieci
szkieletowej i urządzeń przed przełączeniem ruchu produkcyjnego. Wybrane procedury
testowe mogą być wykonywane także po przełączeniu ruchu produkcyjnego.
1. Sprawdzenie działania urządzeń
Podstawowe sprawdzenie działania urządzeń
Cel testu: Testy mają na celu weryfikację działania urządzeń, możliwości konfiguracji i
sprawdzenie zainstalowanych modułów, interfejsów oraz nadmiarowości modułów
redundantnych. Testy obejmą: uruchomienie urządzeń i weryfikację komunikacji z portem
konsoli; sprawdzenie działania zasilaczy; sprawdzenie działania zainstalowanych modułów
i interfejsów.
Metodologia testu:
Środowisko:
MX960
 Możliwość konfiguracji po porcie konsoli
 Weryfikacja zainstalowanych modułów
poprzez CLI (show chassis hardware)
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli nie zostaną
zauważone żadne problemy w działaniu
urządzeń i zweryfikowane zainstalowane
moduły
Wyniki pomiarów, wnioski:
Wykonał:
Data:
2. Sprawdzenie konfiguracji adresacji IP
Sprawdzenie konfiguracji adresacji IP
Cel testu: Testy mają na celu weryfikację adresacji IP na interfejsach
Metodologia testu:
 Zalogowanie się na urządzenie i
weryfikacja adresacji IP (interfejsy
xe/ae/lo0/irb) oraz loopback) zgodnie z
projektem
(show interface terse)
Środowisko:MX960
Uwagi:
Test zostanie zaliczony, jeżeli nie zostaną
zauważone żadne problemy w konfiguracji
Wyniki pomiarów, wnioski:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Wykonał:
Data:
3. Sprawdzenie łączności na warstwie IP oraz stanów warstwy 1 oraz 2
Test ma na celu weryfikację połączeń fizycznych i logicznych dla interfejsów urządzeń
i usunięcie ewentualnych problemów z interfejsami, modułami SFP, okablowaniem
oraz weryfikację połączeń pomiędzy urządzeniami.
Sprawdzenie łączności w warstwie L3 oraz błędów L1/L2
Cel testu: Test ma na celu weryfikację połączeń fizycznych i logicznych dla interfejsów
urządzeń i usunięcie ewentualnych problemów z interfejsami, modułami SFP,
okablowaniem oraz weryfikację połączeń pomiędzy urządzeniami.
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenie
 Weryfikacja łączności po warstwie L3 (ping
do sąsiedniego rutera)
 Weryfikacja liczników błędów L1/L2 (brak
przyrastających liczników w show
interface [] extensive
Uwagi:
Test zostanie zaliczony, jeżeli nie zostaną
zauważone żadne problemy w łączności oraz
brak przyrastających błędów L1/L2
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
4. Sprawdzenie konfiguracji routingu ISIS
4.1. ISIS - Sprawdzenie stanu sąsiadów
ISIS – weryfikacja sąsiedztwa
Cel testu: Test ma na celu weryfikację włączenia protokołu ISIS na interfejsach i
ustanowienia sąsiedztwa w protokole ISIS
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenie
 Weryfikacja sąsiedztw ISIS (show isis
adjacency)
Uwagi:
Test zostanie zaliczony, jeżeli sąsiedztwa wg
topologii sieci będą widoczne
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
4.2. ISIS – Wpisy w tabeli routingu
ISIS – tabela rutingu
Cel testu: Sprawdzenie czy w tabeli routingu znajdują się pozycje z protokołu ISIS.
Metodologia testu:
 Zalogowanie się na urządzenie
 Weryfikacja wpisów ISIS w tabeli rutingu
(show route protocol isis)
Środowisko:
MX960
Uwagi:
Test zostanie zaliczony, jeżeli w tabeli rutingu
danego rutera są widoczne wszystkie lo0
widoczne poprzez ISIS (poza lo0 danego
rutera)
Wyniki pomiarów, wnioski:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Wykonał:
Data:
5. Sprawdzenie stanów sesji MP-BGP
Weryfikacja stanów sesji MP-BGP
Cel testu: Test ma na celu sprawdzenie stanów wszystkich sesji MP-BGP
Metodologia testu:
 Zalogowanie się na rutery
 Weryfikacja stanów sesji bgp (show bgp
summary)
Środowisko:
MX960
Uwagi:
Test zostanie zaliczony, jeżeli sesje do
wskazanych sąsiadów będą posiadały stan
Establish Należy przeprowadzić test dla
family: inet unicast, inet-vpn unicast, inet6
labeled-unicast l2vpn. W każdym family
muszą być widoczne prefixy w określonych
tablicach routingu.
Wyniki pomiarów, wnioski:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Wykonał:
Data:
6. Sprawdzenie l2circuit (xconnect)
Weryfikacja stanów l2circuit
Cel testu: Test ma na celu sprawdzenie współdziałania l2circuit na routerze Juniper z
xconnect na routerze Cisco
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na rutery
 Weryfikacja stanów l2circuit (show l2
circuit connection)
Uwagi:
Test zostanie zaliczony, jeżeli połączenie
l2circuit będzie w stanie UP, labelki wejściowa
i wyjściowa zostaną przydzielone, możliwe
będzie sprawdzenie połączenie L3 z routerów
CE poprzez pakiety ICMP
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
7. Sprawdzenie L3VPN
Weryfikacja działania L3VPN
Cel testu: Test ma na celu sprawdzenie poprawnego działania exportów, importów w
L3VPN, oraz redystrybucji
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na rutery
 Weryfikacja tablicy routingu dla danego
L3VPN’a
Uwagi:
Test zostanie zaliczony, jeżeli tablica routingu
zostanie wypełniona poprzez prefixy
otrzymane z bgp. Lokalne prefixy muszę być
także widoczne na zdalnych routerach
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
8. Sprawdzenie L2VPN z BGP autodiscovery
Weryfikacja L2VPN
Cel testu: Test ma na celu sprawdzenie poprawności działania L2VPN opartego na
protokole LDP do przydzielania labelek z wykorzystaniem BGP do wykrywania urządzeń
PE
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na rutery
 Weryfikacja działania l2vpn (show vpls
connection, show vpls mac-table)
Uwagi:
Test zostanie zaliczony, jeżeli l2vpn będzie
posiadał status UP, zostanie wykryty
automatycznie zdalny router PE. Po
skonfigurowaniu warstwy L3 na urządzeniach
CE, odpowiednie wpisy MAC powinny pojawić
się w tablicy danego VPLS’a.
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
9. Sprawdzenie L2VPN ze statycznymi sąsiedztwami
Weryfikacja L2VPN
Cel testu: Test ma na celu sprawdzenie poprawności działania L2VPN bez
automatycznego wykrywania zdalnych routerów PE. Sąsiedztwa są konfigurowane
ręcznie.
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na rutery
 Weryfikacja stanów L2VPN (show vpls
conncection, show vpls mac-table)
Uwagi:
Test zostanie zaliczony, jeżeli l2vpn będzie
posiadał status UP. Po skonfigurowaniu
warstwy L3 na urządzeniach CE, odpowiednie
wpisy MAC powinny pojawić się w tablicy
danego VPLS’a.
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
10. Sprawdzenie tworzenia i dystrybucji etykiet
10.1.
Sprawdzenie stanu sąsiadów LDP
LDP – sprawdzenie sąsiedztw
Cel testu: Test ma na celu weryfikację ustanowienia sąsiedztwa LDP na wszystkich
szkieletowych połączeniach sieci IP MPLS
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenie
 Weryfikacja stanu sąsiedztw LDP (show
ldp neighbor)
Uwagi:
Test zostanie zaliczony, jeżeli sąsiedztwa na
danym ruterze są zgodnie z topologią sieci
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
10.2.
Sprawdzenie stanu sąsiadów RSVP
RSVP – sprawdzenie sąsiedztw
Cel testu: Test ma na celu weryfikację ustanowienia sąsiedztwa RSVP na wszystkich
połączeniach sieci IP MPLS
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenie
 Weryfikacja stanu sąsiedztw RSVP (show
rsvp neighbor)
Uwagi:
Test zostanie zaliczony, jeżeli sąsiedztwa na
danym ruterze są zgodne z przebiegiem
skonfigurowanego tunelu rsvp. Sąsiedztwa w
RSVP pojawiają się dopiero w momencie
podniesienia tunelu.
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
11. Zarządzanie urządzeniem (autentykacja, SSH, snmp, syslog)
11.1.
Uwierzytelnianie – poziomy uprzywilejowania użytkowników
Uwierzytelnianie (authentication) - poziomy uprzywilejowania użytkowników
Cel testu: Test ma na celu sprawdzenie możliwości zalogowania się na urządzenie danego
użytkownika z określonym poziomem dostępu
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenie
użytkowników z pełnymi prawami i
ograniczonymi
 Weryfikacja stanów praw użytkowników
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli zalogowani
użytkownicy będą mieli prawa zgodne ze
skonfigurowanymi
Wyniki pomiarów, wnioski:
Wykonał:
Data:
11.2.
SSH – użycie protokołu ssh w celu dostępu do urządzenia
SSH – jako zabezpieczony dostęp do urządzenia
Cel testu: Test ma na celu sprawdzenie możliwości zalogowania do urządzenia za pomocą
protokołu ssh
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenie po
protokole ssh
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli zalogowanie
będzie możliwe z użyciem ssh
Wyniki pomiarów, wnioski:
Wykonał:
Data:
11.3.
SNMP server/trap SNMP
SNMP
Cel testu: Zostanie sprawdzona poprawność konfiguracja oraz możliwość odpytania
urządzenia o określone OID’y oraz wysyłanie przez urządzenie SNMP trap
Metodologia testu:
Środowisko:
MX960
 Próba pobrania informacji po odpytaniu
poprzez serwer snmp – odpytanie OID
 Weryfikacja wysłanych SNMP trap
Uwagi:
Test zostanie zaliczony, jeżeli zostaną pobrane
właściwe dane przez serwer snmp oraz
urządzenie wyśle SNMP trap (np. informacja o
stanie interfejsu)
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
11.4.
SYSLOG – LOGOWANIE do bufora i serwera zewnętrznego
SYSLOG – logowanie zdarzeń do na urządzeniu i serwerze zewnętrznym
Cel testu: Celem testu jest weryfikacja zapisywania zdarzeń do pamięci urządzenia oraz
do serwera zewnętrznego syslog
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenie
 Weryfikacja informacji zalogowanych
lokalnie (show log messages –
np.zalogowanie się użytkownika)
 Weryfikacja wysłanych informacji syslog
na sewerze
Uwagi:
Test zostanie zaliczony, jeżeli informacje
syslog będą logowane lokalnie i na serwerze
zewnętrznym
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
12. TESTY NIEZAWODNOŚCIOWE URZĄDZEŃ
12.1.
Testy redundancji zasilania
Redundancja zasilania
Cel testu: Weryfikacja pracy urządzenia po odcięciu zasilania od jednego z zasilaczy oraz
powrót do konfiguracja redundantnej
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenie
 Weryfikacja pracy zasilaczy (show chassis
environment pem)
 Wyłączenie zasilania na jednym zasilaczu –
wypięcie kabla
 Weryfikacja pracy urządzenia
 Włączenie zasilania
 Ponowna weryfikacja pracy urządzenia
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli urządzenie
pracuje poprawnie po wyłączeniu zasilania
jednego z zasilaczy
Wyniki pomiarów, wnioski:
Wykonał:
Data:
12.2.
Testy kart zarządzających
Testy kart redundancji kart zarządzających (RE)
Cel testu: Weryfikacja poprawności zachowania mechanizmów przełączających.
Metodologia testu:
 Wyłączenie karty RE
 Weryfikacja pracy urządzenia i usług
 Włączenie karty
 Ponowna weryfikacja pracy urządzenia i
usług
Środowisko:
MX960
Uwagi:
Test zostanie zaliczony, jeżeli usługi działają
poprawnie po wyłączeniu
redundantnego/podstawowego RE
(przy wyłączeniu podstawowego RE
oczekiwana przerwa w ruchu)
Wyniki pomiarów, wnioski:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Wykonał:
Data:
12.3.
Hot swap kart liniowych
Hot swap kart liniowych
Cel testu: Test ma na celu sprawdzenie zachowania urządzenia po wyjęciu i powrotnym
włożeniu karty liniowej
Metodologia testu:
Środowisko:
MX960
 Wyłączenie karty liniowej mpc lub mic
 Weryfikacja pracy urządzenia
(show chassis alarm, show log messages)
 Włączenie karty
 Ponowna weryfikacja pracy urządzenia
Uwagi:
Test zostanie zaliczony, jeżeli urządzenie
powróci do prawidłowej pracy po ponownym
obsadzeniu karty
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
13. LAG
13.1.
LAG
LAG LACP (802.1ad)
Cel testu: Przedmiotem testu będzie utworzenie pomiędzy urządzeniami dynamicznego
(LACP) grupowania portów i weryfikacja działania, rozkładu ruchu
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenie
 Weryfikacja pracy LAG (show interface
aeX)
 Weryfikacja rozkładu ruchu (monitor
interface traffic)

Uwagi:
 Zaliczony
Test zostanie zaliczony, jeżeli rozkład
 Częściowo zaliczony
równomierny z 10% odchyłem, przy
 Nie zaliczony
wygenerowanym ruchu z kilkudziesięciu
adresów źródłowych
Wyniki pomiarów, wnioski:
Wykonał:
Data:
13.2.
LAG - symulacja awarii
LAG LACP (802.1ad) – symulacja awarii
Cel testu: Po „awaryjnym” wyłączeniu jednego z portów składowych LAG będziemy
obserwować rozłożenie ruchu na pozostałych portach
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenie
 Weryfikacja pracy LAG (show interface
aeX)
 Weryfikacja rozkładu ruchu (monitor
interface traffic)
 Wypięcie jednego ze składowych
interfejsów w LAGu
 Ponowna weryfikacja stanu LAG rozkładu
ruchu
 Wyjęcie drugiego składowego interfejsu
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli rozkład
równomierny z 10% odchyłem, przy
wygenerowanym ruchu z kilkudziesięciu
adresów źródłowych i pozostanie
równomierny po symulacji awarii
Wyniki pomiarów, wnioski:
Wykonał:
Data:
14. Sprawdzenie działania BFD
14.1.
Testy BFD
Testy BFD
Cel testu: Sprawdzenie wykrywania przez bfd niedostępności sąsiada ISIS
Metodologia testu:
 Wyłączenie protokołu ISIS na jednym z
sąsiadów
 Weryfikacja w logach wykrycia
niedostępności sąsiada przez BFD
Środowisko:
MX960
Uwagi:
Test zostanie zaliczony, jeżeli sąsiedztwo
zostanie wyłączone w zadanym czasie.
Nie powinny samoistnie występować wykrycia
niedostępności sąsiada spowodowane
brakiem mocy obliczeniowej karty liniowej.
Bezpieczny interwał na urządzeniach Cisco
7600 to 100ms, na Juniper 10ms.
Wyniki pomiarów, wnioski:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Wykonał:
Data:
15. QOS
15.1.
QOS – oznaczanie pakietów na routerze wejściowym
QOS – oznaczanie pakietów na routerze wejściowym
Cel testu: Pakiety z określonych adresów IP będą oznaczane za pomocą różnych wartości
IP PRECEDENCE
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenia ingress
 Weryfikacja liczników pakietów
wchodzących na odpowiednio
zdefiniowanym filtrze input (show firewall
filter)
 Zalogowanie na egress
 Weryfikacja liczników pakietów
wchodzących na odpowiednio
zdefiniowanym filtrze output (show
firewall filter)
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli ruch jest
prawidłowo oznaczany
Wyniki pomiarów, wnioski:
Wykonał:
Data:
15.2.
QOS – zmiana dscp na exp
QOS – zmiana dscp na exp
Cel testu: Weryfikacja czy pakietom z określonymi wartościami dscp zostaną w sieci mpls
przypisane wartości EXP
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenia transit lub
egress
 Weryfikacja liczników pakietów
wchodzących na odpowiednio
zdefiniowanym filtrze input na family mpls
(show firewall filter)
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli ruch jest
prawidłowo oznaczany
Wyniki pomiarów, wnioski:
Wykonał:
Data:
15.3.
Zachowanie parametrów QOS
QOS – weryfikacja przenoszenia bitów IP precedence
Cel testu: Test ma na celu weryfikację oznaczeń QoS pakietów po przejściu przez sieć
szkieletową
Metodologia testu:
Środowisko:
MX960
 Weryfikacja przenoszenia bitów IP
precedence przez sieć – wygenerowanie
ruchu z właściwymi IP precedence i
odebranie ruchu po drugiej stronie sieci
Uwagi:
 Zaliczony
Test zostanie zaliczony, jeżeli ruch jest
 Częściowo zaliczony
przenoszony i bity IP precedence pozostają
 Nie zaliczony
niezmienione
Wyniki pomiarów, wnioski:
Wykonał:
Data:
15.4.
QOS – policing pakietów
QOS – policing
Cel testu: Celem testu będzie sprawdzenie mechanizmu przycinania pakietów o
określonych wartościach
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenia
 Weryfikacja wolumenu ruchu na
interfejsie wyjściowym (monitor interface
traffic)
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli ruch jest
prawidłowo ograniczany
Wyniki pomiarów, wnioski:
Wykonał:
Data:
15.5.
QOS – shaping pakietów
QOS – shaping
Cel testu: Celem testu będzie sprawdzenie mechanizmu shapingu pakietów o
określonych wartościach
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenia
 Weryfikacja wolumenu ruchu na
interfejsie wyjściowym (monitor interface
traffic)
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli ruch jest
prawidłowo oznaczany
Wyniki pomiarów, wnioski:
Wykonał:
Data:
15.6.
QOS – priorytetyzacja pakietów w przy niewysyconym łączu
QOS – priorytetyzacja pakietów na niewysyconym łączu
Cel testu: Zweryfikowana zostanie ilość pakietów przesłanych gdy łącze jest niewysycone
Metodologia testu:
 Zalogowanie się na urządzenia
 Weryfikacja liczników pakietów
wchodzących na odpowiednio
zdefiniowanym filtrze input/output dwóch
sąsiadujących ze sobą ruterów (show
firewall filter)
Środowisko:
MX960
Uwagi:
Test zostanie zaliczony, jeżeli ruch jest
prawidłowo liczba pakietów o wysokim
priorytecie się zgadza
Wyniki pomiarów, wnioski:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Wykonał:
Data:
15.7.
QOS – priorytetyzacja pakietów w warunkach wysyconego łącza
QOS – priorytetyzacja pakietów na wysyconym łączu
Cel testu: Zweryfikowana zostanie ilość przesłanych pakietów o wysokim priorytecie, gdy
łącze jest wysycone
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenia
 Weryfikacja liczników pakietów
wchodzących na odpowiednio
zdefiniowanym filtrze input/output dwóch
sąsiadujących ze sobą ruterów (show
firewall filter)
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli ruch jest
prawidłowo liczba pakietów o wysokim
priorytecie się zgadza
Wyniki pomiarów, wnioski:
Wykonał:
Data:
16. Zabezpieczenie RE - filtr
16.1.
RE – filtr SSH
RE – filtr SSH
Cel testu: Weryfikacja poprawności działania filtra na pakiety ssh kierowane do
urządzenia
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenia
 Weryfikacja liczników pakietów w filtrach
ssh
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli odpowiednie
liczniki filtrach będą się zwiększać
odpowiednio dla ruchu dopuszczonego (z
określonych podsieci) jak i dla ruchu
zabronionego (z pozostałych podsieci)
Wyniki pomiarów, wnioski:
Wykonał:
Data:
16.2.
RE filtr NTP
RE – filtr NTP
Cel testu: Weryfikacja poprawności działania filtra na pakiety NTP kierowane do
urządzenia
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenia
 Weryfikacja liczników pakietów w filtrach
NTP
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony
Uwagi:
Test zostanie zaliczony, jeżeli odpowiednie
liczniki filtrach będą się zwiększać
odpowiednio dla ruchu dopuszczonego (z
określonych podsieci) jak i dla ruchu
zabronionego (z pozostałych podsieci)
Wyniki pomiarów, wnioski:
Wykonał:
Data:
16.3.
RE filtr BGP
RE – filtr BGP
Cel testu: Weryfikacja poprawności działania filtra na pakiety BGP kierowane do
urządzenia
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenia
 Weryfikacja liczników pakietów w filtrach
BGP
Uwagi:
 Zaliczony
Test zostanie zaliczony, jeżeli odpowiednie
 Częściowo zaliczony
liczniki filtrach będą się zwiększać
 Nie zaliczony
odpowiednio dla ruchu dopuszczonego (z
określonych podsieci) jak i dla ruchu
zabronionego (z pozostałych podsieci)
Wyniki pomiarów, wnioski:
Wykonał:
Data:
16.4.
RE filtr LDP
RE – filtr LDP
Cel testu: Weryfikacja poprawności działania filtra na pakiety LDP kierowane do
urządzenia
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenia
 Weryfikacja liczników pakietów w filtrach
LDP
Uwagi:
 Zaliczony
Test zostanie zaliczony, jeżeli odpowiednie
 Częściowo zaliczony
liczniki filtrach będą się zwiększać
 Nie zaliczony
odpowiednio dla ruchu dopuszczonego (z
określonych podsieci) jak i dla ruchu
zabronionego (z pozostałych podsieci)
Sąsiedztwo LDP pomiędzy właściwymi
routerami musi zostać nawiązane.
Wyniki pomiarów, wnioski:
Wykonał:
Data:
16.5.
RE filtr RSVP
RE – filtr RSVP
Cel testu: Weryfikacja poprawności działania filtra na pakiety RSVP kierowane do
urządzenia
Metodologia testu:
Środowisko:
MX960
 Zalogowanie się na urządzenia
 Weryfikacja liczników pakietów w filtrach
RSVP
Uwagi:
Test zostanie zaliczony, jeżeli odpowiednie
liczniki filtrach będą się zwiększać
odpowiednio dla ruchu dopuszczonego (z
określonych podsieci) jak i dla ruchu
zabronionego (z pozostałych podsieci). Ruch
kontrolny RSVP jest generowany dopiero w
momencie złożenia ścieżek RSVP pomiędzy
urządzeniami
Wyniki pomiarów, wnioski:
Wykonał:
Data:
 Zaliczony
 Częściowo zaliczony
 Nie zaliczony