GNS3 - QoS - Iperf problem z portami

VIRL, Dynamips, Boson NetSim, Packet Tracert, Olive, UNL, EVE-NG
Wiadomość
Autor
pacholekck
fresh
fresh
Posty: 3
Rejestracja: 11 kwie 2015, 23:27

GNS3 - QoS - Iperf problem z portami

#1

#1 Post autor: pacholekck »

Witam.
Mam zestawione środowisko w GNS3 do testów konfiguracji QoS.
Topologia wygląda następująco:

Klient(wirtualka Ubuntu, Iperf serwer)<=>R1<=>R2<=>Serwer(wirtualka Ubuntu, Iperf Client)

Między routerami link ograniczony do 128kbps.

Na R2 zrobiłem klasyfikacje ruchu przy pomocy ACL na różnych portach.

Problem jaki mam jest taki, że jeżeli przy pomocy Iperfa generuję np. strumień UDP na porcie 2000, to na ruterze ten ruch jest widziany na porcie 0. Mam nadzieję, że wiecie o co mi chodzi. Mój plan był taki, że z jednego hosta odpalam kilka razy iperfa i generuję jednocześnie np. TCP 80, TCP 20 i UDP 5000, ale jedyne co widzę na ruterze to ruch UDP lub TCP z jednego hosta na drugi, ale wszystko na porcie 0.

Macie jakiś pomysł jak to obejść, czy to tak musi działać?

Z góry dzięki za pomoc.

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

Re: GNS3 - QoS - Iperf problem z portami

#2

#2 Post autor: lbromirs »

Dziwne.

Pokaż skąd wiesz że to ruch na porcie 0 i jakiej konkretnie konfiguracji używasz na routerach do klasyfikacji ruchu/matchowania go.

pacholekck
fresh
fresh
Posty: 3
Rejestracja: 11 kwie 2015, 23:27

#3

#3 Post autor: pacholekck »

Dzięki za odpowiedź, jednak to był mój błąd, a zmylił mnie ten log z rutera:

*Mar 1 00:18:01.631: %SEC-6-IPACCESSLOGP: list TEST_PORT permitted udp 192.168.20.3(0) -> 192.168.10.3(0), 4526 packets

Myślałem, że te wartości w nawiasach obok adresów IP to właśnie port. Na szczęście debug ip packed detail pokazał, że ruch idzie faktycznie na takich portach na jakich chce.

Niestety mam kolejny problem z symulacją.
Chcę, żeby łącze pomiędzy routerami było skonfigurowane jako 512kbit/s. Zrealizowałem to komendami na R2 i R1:

interface Serial0/0
rate-limit input 512000 3500 3500 conform-action transmit exceed-action drop
rate-limit output 512000 3500 3500 conform-action transmit exceed-action drop

Niestety takie rozwiązanie wydaje się być niepoprawne, ponieważ chcąc później QoS-em ograniczyć pasmo np. dla FTP do 64kbps dostaję błąd:

R2(config)#policy-map OUTPUT
R2(config-pmap)#class FTP_BW
R2(config-pmap-c)#police 16000
Output rate-limit already configured, police not allowed

Po usunięciu linijki "rate-limit output 512000 3500 3500 conform-action transmit exceed-action drop" z se 0/0 mogę dodać komendę police 16000.



Zastanawia mnie jeszcze jedna rzecz. Bez konfiguracji żadnego QoS-a, ani ograniczeń łącza, przy podstawowej konfiguracji generuję ruch UDP. Topologia jak poniżej:

Iperf Server<=>(Fa0/1)R1(Se0/0)<=>(Se0/0)R2(Fa0/1)<=>Iperf Client

Generuję iperfem strumień UDP 3Mb/s. Po stronie iperf serwer otrzymuję 1Mb/s. Oglądam co się dzieje na interfejsach routerów:

R2#sh int fa 0/1
30 second input rate 2871000 bits/sec, 239 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
R2#sh int se 0/0
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 2917000 bits/sec, 245 packets/sec

R1#sh int se 0/0
30 second input rate 3046000 bits/sec, 255 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
R1#sh int fa 0/1
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 1122000 bits/sec, 93 packets/sec

Jak to interpretować? R2 odbiera i wysyła około 3Mb/s, a R1 odbiera około 3Mb/s, a wysyła tylko nieco ponad 1Mb/s? Czym to jest spowodowane?


Z góry dziękuję za pomoc i porady :D

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#4

#4 Post autor: lbromirs »

pacholekck pisze:Dzięki za odpowiedź, jednak to był mój błąd, a zmylił mnie ten log z rutera:

*Mar 1 00:18:01.631: %SEC-6-IPACCESSLOGP: list TEST_PORT permitted udp 192.168.20.3(0) -> 192.168.10.3(0), 4526 packets

Myślałem, że te wartości w nawiasach obok adresów IP to właśnie port. Na szczęście debug ip packed detail pokazał, że ruch idzie faktycznie na takich portach na jakich chce.
I to są porty, ale logują się prawidłowo dopiero, gdy ACLka logująca również zawiera specyfikację portów. Taki niuans :P
pacholekck pisze:Niestety mam kolejny problem z symulacją.
Chcę, żeby łącze pomiędzy routerami było skonfigurowane jako 512kbit/s. Zrealizowałem to komendami na R2 i R1:

interface Serial0/0
rate-limit input 512000 3500 3500 conform-action transmit exceed-action drop
rate-limit output 512000 3500 3500 conform-action transmit exceed-action drop

Niestety takie rozwiązanie wydaje się być niepoprawne, ponieważ chcąc później QoS-em ograniczyć pasmo np. dla FTP do 64kbps dostaję błąd:

R2(config)#policy-map OUTPUT
R2(config-pmap)#class FTP_BW
R2(config-pmap-c)#police 16000
Output rate-limit already configured, police not allowed
Konfigurujesz jednocześnie dwie polityki, tak się nie robi. Albo MQC (i to jest właściwa metoda), albo stare polecenia typu rate-limit - które odchodzą już jako CAR do lamusa (a właściwie odeszły - nie wiem której wersji IOSa używasz, w nowszych ich po prostu nie ma).
pacholekck pisze:Zastanawia mnie jeszcze jedna rzecz. Bez konfiguracji żadnego QoS-a, ani ograniczeń łącza, przy podstawowej konfiguracji generuję ruch UDP. Topologia jak poniżej:

Iperf Server<=>(Fa0/1)R1(Se0/0)<=>(Se0/0)R2(Fa0/1)<=>Iperf Client

Generuję iperfem strumień UDP 3Mb/s. Po stronie iperf serwer otrzymuję 1Mb/s. Oglądam co się dzieje na interfejsach routerów:

R2#sh int fa 0/1
30 second input rate 2871000 bits/sec, 239 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
R2#sh int se 0/0
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 2917000 bits/sec, 245 packets/sec

R1#sh int se 0/0
30 second input rate 3046000 bits/sec, 255 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
R1#sh int fa 0/1
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 1122000 bits/sec, 93 packets/sec

Jak to interpretować? R2 odbiera i wysyła około 3Mb/s, a R1 odbiera około 3Mb/s, a wysyła tylko nieco ponad 1Mb/s? Czym to jest spowodowane?
Tym, że GNS3 a dokładniej dynamips nie nadaje się generalnie do badania QoSa - kod jest interpretowany w locie i to co dzieje się ze wszystkimi funkcjami opierającymi się o ścisły pomiar jednostek czasu po prostu nie ma szansy działać poprawnie.

Możesz spróbować zmniejszyć mierzone pasmo do np. 1Mbit/s - w zależności od CPU/etc może to poprawić sytuację, ale niekoniecznie.

Do QoSa, jeśli już, lepiej użyć CSRów 1000v.

pacholekck
fresh
fresh
Posty: 3
Rejestracja: 11 kwie 2015, 23:27

#5

#5 Post autor: pacholekck »

lbromirs pisze: I to są porty, ale logują się prawidłowo dopiero, gdy ACLka logująca również zawiera specyfikację portów. Taki niuans :P
Dobrze wiedzieć, dzięki za wyjaśnienie :)
lbromirs pisze: Konfigurujesz jednocześnie dwie polityki, tak się nie robi. Albo MQC (i to jest właściwa metoda), albo stare polecenia typu rate-limit - które odchodzą już jako CAR do lamusa (a właściwie odeszły - nie wiem której wersji IOSa używasz, w nowszych ich po prostu nie ma).
Ok, rozumiem. Jak w takim razie mogę ograniczyć łącze np. do 512kbit/s ? Nie mogę przecież podpiąć pod Serial 0/0 dwóch różnych service-policy, a będę chciał np. skonfigurować CB-WFQ. Czy mogę użyć komendy "traffic-shape rate 512000 12800 12800 1000" na se 0/0 obu routerów?
lbromirs pisze: Tym, że GNS3 a dokładniej dynamips nie nadaje się generalnie do badania QoSa - kod jest interpretowany w locie i to co dzieje się ze wszystkimi funkcjami opierającymi się o ścisły pomiar jednostek czasu po prostu nie ma szansy działać poprawnie.

Możesz spróbować zmniejszyć mierzone pasmo do np. 1Mbit/s - w zależności od CPU/etc może to poprawić sytuację, ale niekoniecznie.

Do QoSa, jeśli już, lepiej użyć CSRów 1000v.
Dzięki popatrzę na tego CSR-a. Używam mniejszego ruchu przy symulacjach. Skonfigurowałem klasyfikacje po portach i markowanie dscp na interfejsie wchodzącym, a następnie kolejne class-mapy, w których markuję już po wartrościach dscp i przydzielam oraz ograniczam pasmo na interfejsie wychodzącym. Symuluję ruch UDP(5001)324kbit/s-jako voip + TCP(8000)-jako HTTP + TCP(2000)-jako FTP. Łącze mam niby ograniczone do 512kbit/s komendą "traffic-shape rate 512000 12800 12800 1000". Przy wygenerowaniu powyższych trzech strumieni w tym samym czasie łącze się wysyca i pojawiają się straty pakietów około 20% w VoIP-ie. Po uruchomieniu:
policy-map OUTPUT
class VOIP_BW
bandwidth 384
class FTP_BW
police 64000
bandwidth 16
class HTTP_BW
bandwidth 32
police 128000
Straty pakietów dla VoIP wynoszą 0%, a ruch TCP jest ograniczony. Pytanie, czy to co mierzę ma sens i na fizycznym sprzęcie będzie działało tak samo?

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#6

#6 Post autor: lbromirs »

pacholekck pisze:Ok, rozumiem. Jak w takim razie mogę ograniczyć łącze np. do 512kbit/s ? Nie mogę przecież podpiąć pod Serial 0/0 dwóch różnych service-policy, a będę chciał np. skonfigurować CB-WFQ. Czy mogę użyć komendy "traffic-shape rate 512000 12800 12800 1000" na se 0/0 obu routerów?
Nadal nie. Wstaw w to łącze trzeci router, który wykona tylko taki shaping, policing lub cokolwiek uznasz za adekwatne. Albo wykorzystaj np. wirtualkę z ipfw, które jakoś-tam sobie daje radę z QoSem w środowiskach wirtualnych (pipe/etc, nie mierz jittera ;P).
pacholekck pisze:Dzięki popatrzę na tego CSR-a. Używam mniejszego ruchu przy symulacjach. Skonfigurowałem klasyfikacje po portach i markowanie dscp na interfejsie wchodzącym, a następnie kolejne class-mapy, w których markuję już po wartrościach dscp i przydzielam oraz ograniczam pasmo na interfejsie wychodzącym. Symuluję ruch UDP(5001)324kbit/s-jako voip + TCP(8000)-jako HTTP + TCP(2000)-jako FTP. Łącze mam niby ograniczone do 512kbit/s komendą "traffic-shape rate 512000 12800 12800 1000". Przy wygenerowaniu powyższych trzech strumieni w tym samym czasie łącze się wysyca i pojawiają się straty pakietów około 20% w VoIP-ie. Po uruchomieniu:
policy-map OUTPUT
class VOIP_BW
bandwidth 384
class FTP_BW
police 64000
bandwidth 16
class HTTP_BW
bandwidth 32
police 128000
Straty pakietów dla VoIP wynoszą 0%, a ruch TCP jest ograniczony. Pytanie, czy to co mierzę ma sens i na fizycznym sprzęcie będzie działało tak samo?
Może, choć dla głosu czy generalnie klasy priorytetowej, gwarancje realizuje się za pomocą polecenia 'priority' a nie bandwidth - o różnicach możesz poczytać sobie np. tutaj.

ODPOWIEDZ