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.
GNS3 - QoS - Iperf problem z portami
-
- fresh
- Posty: 3
- Rejestracja: 11 kwie 2015, 23:27
Re: GNS3 - QoS - Iperf problem z portami
Dziwne.
Pokaż skąd wiesz że to ruch na porcie 0 i jakiej konkretnie konfiguracji używasz na routerach do klasyfikacji ruchu/matchowania go.
Pokaż skąd wiesz że to ruch na porcie 0 i jakiej konkretnie konfiguracji używasz na routerach do klasyfikacji ruchu/matchowania go.
-
- fresh
- Posty: 3
- Rejestracja: 11 kwie 2015, 23:27
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
*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
I to są porty, ale logują się prawidłowo dopiero, gdy ACLka logująca również zawiera specyfikację portów. Taki niuanspacholekck 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.
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: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
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.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?
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.
-
- fresh
- Posty: 3
- Rejestracja: 11 kwie 2015, 23:27
Dobrze wiedzieć, dzięki za wyjaśnienielbromirs pisze: I to są porty, ale logują się prawidłowo dopiero, gdy ACLka logująca również zawiera specyfikację portów. Taki niuans
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: 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).
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: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.
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?
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: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?
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.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?