Forum Debian Users Gang

Nicram · 2010-11-19 12:00:05

witam
mam na eth0 poodpalene interfejsy vlanowe.

Kod:

eth0      Link encap:Ethernet  HWaddr 00:0d:b9:18:c5:94  
          inet addr:192.168.2.109  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1779 errors:0 dropped:0 overruns:0 frame:0
          TX packets:884 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:502547 (490.7 KiB)  TX bytes:160100 (156.3 KiB)
          Interrupt:10 Base address:0x1000

interfejs ma mtu 1500. interfejsy vlanowe suma sumarum maja mniej aczkolwiek tez ustawione sa na 1500, z tym, ze przez interfejs vlanowy nie moge puscic pakietu 1500.
chce zwiększyć mtu dla sieciówki ale wywala błąd, ze zmniejszeniem nie ma problemu.

Kod:

alix:~# ifconfig eth0 mtu 1522
SIOCSIFMTU: Zły argument
alix:~# ifconfig eth0 mtu 1400
alix:~# ifconfig eth0|grep -i mtu
          UP BROADCAST RUNNING MULTICAST  MTU:1400  Metric:1
alix:~#

akurat na tym sprzecie mam taka sieciówke:

Kod:

00:09.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96)
    Subsystem: VIA Technologies, Inc. Device 0106
    Flags: bus master, stepping, medium devsel, latency 64, IRQ 10
    I/O ports at 1000 [size=256]
    Memory at e0000000 (32-bit, non-prefetchable) [size=256]
    Capabilities: [40] Power Management version 2
    Kernel driver in use: via-rhine
    Kernel modules: via-rhine

ale próbowałem też na innch, na intelowskich i efekt taki sam. zmniejszyc moge ale powiększyć już nie :(

więc moja pytanie. jak zwiększyć MTU?

Punisher999 · 2010-11-19 12:08:37

Mogę się mylić ale wydaje mi się, ze ponieważ spora część sprzętu nie potrafi działać z większym MTU niż 1500 to myślę ze ogranicza cię tu sprzęt i nie wiem czy jest to do przeskoczenia bez wymiany tego sprzętu.
Edit:
Przyszło mi do głowy że ze sprzętem i tak gada kernel, zatem może (podkreślam może) tam występuje to ograniczenie trzeba by zerknąć do kompilacji jajka czy jest coś tam związane z MTU. Kernel tak naprawdę ma kilkanaście/dziesiąt sterowników (w miarę uniwersalnych) na krzyż i się nimi posługuje. Zatem tam bym szukał w pierwszej kolejności możliwości zwiększenia MTU.

Ostatnio edytowany przez Punisher999 (2010-11-19 12:49:23)

Nicram · 2010-11-19 12:40:15

Punisher999 napisał(-a):
Mogę się mylić ale wydaje mi się, ze ponieważ spora część sprzętu nie potrafi działać z większym MTU niż 1500 to myślę ze ogranicza cię tu sprzęt i nie wiem czy jest to do przeskoczenia bez wymiany tego sprzętu.

tez tak myślałem, że ogranicza mnie sprzęt. dlatego też próbowałem na dosyć drogich intelowskich serwerowych sieciówkach i efekt był taki sam :( w necie jest kilka artów jak podnieść ale w żadnym nie znalazłem dlaczego tak się dzieje jak u mnie.

bercik · 2010-11-19 23:06:27

Nicram napisał(-a):
interfejsy vlanowe suma sumarum maja mniej aczkolwiek tez ustawione sa na 1500

pytanie dlaczego suma sumarum maja mniej?

Nicram napisał(-a):
więc moja pytanie. jak zwiększyć MTU?

strasznie sie uparles na zwiekszanie MTU ... MTU>1500 dla ethernetu 1) jest niezgodne z standardem 2) jest jakas patologia 3) raczej nie powinno dac sie ustawic ...

ogolnie:
* MTU okresla uzyteczny (dla warstyw 3 modelu OSI) ladunek ramki warstwy nizszej i dla ethernetu wynosi max. 1500
* dodatkowe 4 bajty zwiazane z tagowanymi vlan-ami standardu 802.1Q sa wkladane pomiedzy EtherType a pole danych a nie pole danych (ktore nadal moze byc maksymalnie 1500)
* powoduje to ze ramnka 802.1Q jako calosc moze miec maks. 1530 bajtow (czyli o 4 wiecej niz zwykle), ale ma sie to nijak do MTU (podstawowego interfejsu)
* jezeli nie ma zadnych bugow w sofcie / sprzecie zarowno interfejs podstawowy jak i vlan powinny moc miec mtu=1500
* jezli jest problem z przeslaniem 1500 bajtowego pakietu IP (1530 bajtowa ramka) jest to jakis bug ... pomoze zmniejszenie mtu na interfejsie majacym problem (czyli tagowanym) a nie zwiekszanie na nietagowanym

z moich doswidczen:
* na ogol tagowany VLAN chodzi z MTU 1500
* raz sie spotkalem z czyms takim ze wymagal mniejszego MTU - byl to WLA-5000AP v1.0 z OpenWRT (w wolnej chwili sproboje sprawdzic o ile dokladnie wymaga zmniejszenia i jak z duzymi pingami w tym wypadku)

dziwne jest ze w Twoim przypadku MTU na interfejsie VLANowym musi byc mniejsze o 8 bajtow (tagowany vlan doklada tylko 4)

* napisz z czym masz problem ze chesz miec koniecznie 1500 na interfejsie VLANowym?
* napisz cos wiecej o swojej konfiguracji/sieci - wesje jadra czy sa jakis switche po drodze (jakie), etc ...
* sproboj podlaczyc ta karte bezposrednio z drugim komuterem, ustawic vlan z mtu=1500 i przetestowac

Nicram · 2010-11-20 11:07:42

bercik napisał(-a):
strasznie sie uparles na zwiekszanie MTU ... MTU>1500 dla ethernetu 1) jest niezgodne z standardem 2) jest jakas patologia 3) raczej nie powinno dac sie ustawic ...

nie to, że się uparłem :) nie lubie zostawiać "nie domkniętych" tematów.

bercik napisał(-a):
ogolnie:
* dodatkowe 4 bajty zwiazane z tagowanymi vlan-ami standardu 802.1Q sa wkladane pomiedzy EtherType a pole danych a nie pole danych (ktore nadal moze byc maksymalnie 1500)

hmm. przy interfejsie vlanowym tcpdump pokazuje mi max wielkość 1480

bercik napisał(-a):
* jezli jest problem z przeslaniem 1500 bajtowego pakietu IP (1530 bajtowa ramka) jest to jakis bug ... pomoze zmniejszenie mtu na interfejsie majacym problem (czyli tagowanym) a nie zwiekszanie na nietagowanym.

powiem tak. problem nie jest z wysłaniem 1500bajtoweg pakiety. bo on wychodzi. komputer docelowy odpowiada "swoim" większym mtu i tego właśnie interfejs vlanowy nie przyjmuje.

bercik napisał(-a):
dziwne jest ze w Twoim przypadku MTU na interfejsie VLANowym musi byc mniejsze o 8 bajtow (tagowany vlan doklada tylko 4)

tego to ja nie wiem. pisałem co zaobserwowałem

bercik napisał(-a):
* napisz z czym masz problem ze chesz miec koniecznie 1500 na interfejsie VLANowym?

nie musze mieć koniecznie 1500 chce zeby to działało. jak puszcze pinga -s 2048 i wiekszego w ethernecie to mam odpowiedzi.
ale jak puszcze większego pinga do hosta w vlanie z "serwera" z interfejsem vlan to niestety ten ping "nie wraca". jak pisałem wyżej, host w sieci odpowiada ale "serwer" z valnem nie obiera go. ale jeśli interfejs był w trybie promisc (przyjmował wisio) to taki ping wracał. interfejs go odbieral.

bercik napisał(-a):
* napisz cos wiecej o swojej konfiguracji/sieci - wesje jadra czy sa jakis switche po drodze (jakie), etc ...

dla tych celow to wyglada tak.

Kod:

[serwer]eth0-
    -vlan100 -\
    -vlan150 \  
    -vlan200  - switch LinkSys tag port 24

        porty 10-13 należą do vlan100
        do portu 10 - host10
        ..
        do portu 13 - host13
    
    port 23 tego switcha trunkuje do drugiego
    identycznego switcha Linksysa. w którym
    również są porty należące do vlan100
    
    a na switchu 2gim
    port 2-1 - host14 z vlan100
    port 2-2 - host15 z vlan100

i teraz tak(wszystki puszczane pingi -s 2048 ):
* puszczam pinga pomiędzy host14 a host15 = idzie
* puszczam pinga pomiędzy host10 a host13 = idzie
* puszczam pinga pomiędzy host 14 a host10 = idzie
czyli komunikacja między switachami po tagowanych portach jest ok.
* puszczam pinga z serwera do któregoś z hostX = nie idzie (nie przyjmuje odpowiedzi)
* puszczam "normalnego" pinga z serwera do któreghoś z hostX = idzie

obecnie w moich vlanach biegaja tunele PPPoE tak więc z tym wielkiego problemu nie ma. serwer-pppoe sluch na każdym z interfejsów vlan.
ale musze dorobić kilka vlanów gdzie po drugiej stronie bedzie normalny ethernet.
konkretnie to na swoim serwerze bede musiał zrobic interfejs vlan. postawić na nim serwer dhcp a po drugiej stronie jakieś komputerki. tak dla kilku lokalizacji. no i jeśli bedzie taki problem z mtu jak mam teraz to wówczas beda kłopoty :(

jeśli chodzi o kernele to we wszystich akrurat jest debian 5 z gałęzi stabilnej. kernele dystrybucyjne.

bercik napisał(-a):
* sproboj podlaczyc ta karte bezposrednio z drugim komuterem, ustawic vlan z mtu=1500 i przetestowac

hehe. to rozwiązanie działa. ale ping idzie z interfejsu vlanowego do interfejsu vlanowego

bercik · 2010-11-20 15:14:37

Nicram napisał(-a):
bercik napisał(-a):
strasznie sie uparles na zwiekszanie MTU ... MTU>1500 dla ethernetu 1) jest niezgodne z standardem 2) jest jakas patologia 3) raczej nie powinno dac sie ustawic ...
nie to, że się uparłem :) nie lubie zostawiać "nie domkniętych" tematów.

tyle ze zwiekaszanie MTU na interfejsie podstawowym nie ma nic do rzeczy ...

Nicram napisał(-a):
przy interfejsie vlanowym tcpdump pokazuje mi max wielkość 1480

pokaz komende i output gdzie to widzisz ...

Nicram napisał(-a):
bercik napisał(-a):
* jezli jest problem z przeslaniem 1500 bajtowego pakietu IP (1530 bajtowa ramka) jest to jakis bug ... pomoze zmniejszenie mtu na interfejsie majacym problem (czyli tagowanym) a nie zwiekszanie na nietagowanym.
powiem tak. problem nie jest z wysłaniem 1500bajtoweg pakiety. bo on wychodzi.

jako jeden pakiet czy podzielony na kawalki ... jezeli pofragmentowany to z przeslaniem ramki 1530 bajtow jest problem

Nicram napisał(-a):
komputer docelowy odpowiada "swoim" większym mtu i tego właśnie interfejs vlanowy nie przyjmuje.

rozwiazaniem tego problemu jest zmniejszenie MTU po drugiej stronie ...

bercik napisał(-a):
dziwne jest ze w Twoim przypadku MTU na interfejsie VLANowym musi byc mniejsze o 8 bajtow (tagowany vlan doklada tylko 4)

tego to ja nie wiem. pisałem co zaobserwowałem

Nicram napisał(-a):
ak puszcze większego pinga do hosta w vlanie z "serwera" z interfejsem vlan to niestety ten ping "nie wraca". jak pisałem wyżej, host w sieci odpowiada ale "serwer" z valnem nie obiera go. ale jeśli interfejs był w trybie promisc (przyjmował wisio) to taki ping wracał. interfejs go odbieral.

sugeruje jakis bug w sofcie serwera ...

Nicram napisał(-a):
jeśli chodzi o kernele to we wszystich akrurat jest debian 5 z gałęzi stabilnej. kernele dystrybucyjne.

to dlaczego interfejsy vlanowe nazywaja sie "vlan7" a nie eth0.7 ? i skad ta rozbierznosc vlan7 vs. vlan 100

z Twojego opisu sieci rozmiem ze:
* tagowanych vlanow uzywa tylko serwer i trunk switchy ... w pozostalych wypadkach tag jest zdejmowany przez switch (jest wystawiany odtagowany vlan)
* komunikacja pomiedzy hostami w takim odtagowanym vlanie jest ok
* duze pakiety pomiedzy serwerem a hostami w odtagowanych vlanach nie ida

Nicram napisał(-a):
bercik napisał(-a):
* sproboj podlaczyc ta karte bezposrednio z drugim komuterem, ustawic vlan z mtu=1500 i przetestowac
hehe. to rozwiązanie działa. ale ping idzie z interfejsu vlanowego do interfejsu vlanowego

a jest fragmentowany?

Nicram · 2010-11-21 13:47:04

bercik napisał(-a):
Nicram napisał(-a):
przy interfejsie vlanowym tcpdump pokazuje mi max wielkość 1480
pokaz komende i output gdzie to widzisz ...

Kod:

 ifconfig vlan7 
vlan7     Link encap:Ethernet  HWaddr 00:a1:b0:41:07:f9  
          inet addr:172.21.7.1  Bcast:172.21.7.255  Mask:255.255.255.0
          inet6 addr: fe80::2a1:b0ff:fe41:7f9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4346372 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10717981 errors:0 dropped:1603 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2507590135 (2.3 GiB)  TX bytes:1269909614 (1.1 GiB)

ping 172.21.7.10 -c1 -s 2048
PING 172.21.7.10 (172.21.7.10) 2048(2076) bytes of data.

--- 172.21.7.10 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms



:~# tcpdump -pni vlan7 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan7, link-type EN10MB (Ethernet), capture size 96 bytes
13:19:58.989081 IP 172.21.7.1 > 172.21.7.10: ICMP echo request, id 54842, seq 1, length 1480
13:19:58.989097 IP 172.21.7.1 > 172.21.7.10: icmp

a to tcpdump na hoscie wewnatrz vlanu. ten ktorego pinguje

Kod:

:~# tcpdump -pni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:22:35.914247 IP 172.21.7.1 > 172.21.7.10: icmp

czyli doszedł tylko fragment.

zarzucilem tcpdumpa na fizycznym interfejsie do ktorego podpiety jest vlan

Kod:

:~# tcpdump -pni eth2 |grep "vlan 7"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
14:33:54.677123 vlan 7, p 0, IP 172.21.7.1 > 172.21.7.10: ICMP echo request, id 20539, seq 1, length 1480
14:33:54.677136 vlan 7, p 0, IP 172.21.7.1 > 172.21.7.10: icmp

przy ustawionym MTU 1500, jak widac wychodzi 1480.
jak puszczam mniejszy pakiet to lenght mam puszczona_wielkosc+8, np. jak pinga puszcze z -s 1000 to w lenght mam 1008.

Ustawiam MTU 1480 na interfejsie vlan7 na serwerze. puszczam tego samego pinga. efekt taki sam, brak widocznej odpowiedzi, ale host docelowy odpowiada

Kod:

13:23:25.694295 IP 172.21.7.1 > 172.21.7.10: ICMP echo request, id 55610, seq 1, length 1456
13:23:25.694323 IP 172.21.7.1 > 172.21.7.10: icmp
13:23:25.694384 IP 172.21.7.10 > 172.21.7.1: ICMP echo reply, id 55610, seq 1, length 1480
13:23:25.694391 IP 172.21.7.10 > 172.21.7.1: icmp

do hosta w vlanie dochodzi 1456+20+4=1480, czyli tak jak ustawione mtu.

bercik napisał(-a):
Nicram napisał(-a):
komputer docelowy odpowiada "swoim" większym mtu i tego właśnie interfejs vlanowy nie przyjmuje.
rozwiazaniem tego problemu jest zmniejszenie MTU po drugiej stronie ...

teoretycznie. praktycznie jest to malo wykonalne.
powiedziec (wymusic) od kazdego usera zeby zmniejszyl MTU. w moim przypadku beda to 4 pracownie komputerowe w szkolach. caly dhcp itd. bedzie u mnie na serwerku. dlatego tez musze to zrobic w vlanach, kazda pracownia osobny vlan.

bercik napisał(-a):
Nicram napisał(-a):
ak puszcze większego pinga do hosta w vlanie z "serwera" z interfejsem vlan to niestety ten ping "nie wraca". jak pisałem wyżej, host w sieci odpowiada ale "serwer" z valnem nie obiera go. ale jeśli interfejs był w trybie promisc (przyjmował wisio) to taki ping wracał. interfejs go odbieral.
sugeruje jakis bug w sofcie serwera ...

we wszystkich?? nie możliwe. testuje to na kilku hostach i na wszystkich efekt ten sam.

bercik napisał(-a):
Nicram napisał(-a):
jeśli chodzi o kernele to we wszystich akrurat jest debian 5 z gałęzi stabilnej. kernele dystrybucyjne.
to dlaczego interfejsy vlanowe nazywaja sie "vlan7" a nie eth0.7 ? i skad ta rozbierznosc vlan7 vs. vlan 100

rozbierzności miedzy vlan7 a vlan100 sa z tego iz vlan7 jest na serwerze produkcyjnym a vlan100 w mojej "testowej" lokalizacji, że tak powiem na biurkowej sieci. a dlaczego vlan7 a nie eth0.7. vlany tworze za pomoca ip:
ip link add link eth0 name vlan7 type vlan id 7 gvrp on
ale czy robie to przez ip czy vconfig, efekt taki sam. zreszta w vconfig, tez można ustawić aby interfejs byl nazywany vlanX.

bercik napisał(-a):
z Twojego opisu sieci rozmiem ze:
* tagowanych vlanow uzywa tylko serwer i trunk switchy ... w pozostalych wypadkach tag jest zdejmowany przez switch (jest wystawiany odtagowany vlan)
* komunikacja pomiedzy hostami w takim odtagowanym vlanie jest ok
* duze pakiety pomiedzy serwerem a hostami w odtagowanych vlanach nie ida

* tak
* tak
* tak

bercik napisał(-a):
* sproboj podlaczyc ta karte bezposrednio z drugim komuterem, ustawic vlan z mtu=1500 i przetestowac
Nicram napisał(-a):
hehe. to rozwiązanie działa. ale ping idzie z interfejsu vlanowego do interfejsu vlanowego
a jest fragmentowany?

tak, jest fragmentowany.

zastanawiam się jeszcze nad jednym.
utorze interfejs br7 do którego dołącze vlan7. z vlan7 zdejme adresacje i ustawie na br7.
teoretycznie pakiet 1500 wyjdzie br7 -> zostanie odtagowany na vlan7, pozniej na switchach tag zostanie zdjęty i teoretycznie powinno zadziałać, ale to bede mógł przetestować jutro.
jak to nie pomoże to bedzie kaplica :( nawet na mikrotiku vlany lepiej by działały :(

Ostatnio edytowany przez Nicram (2010-11-21 14:40:04)

bercik · 2010-11-21 16:14:42

Nicram napisał(-a):
13:19:58.989081 IP 172.21.7.1 > 172.21.7.10: ICMP echo request, id 54842, seq 1, length 1480

ale to nie MTU ... tylko ilosc bajtow w pakiecie IP bez jego naglowka ... a MTU to wraz z nglowkiem IP (czyli +20 lub 24 bajty jezeli jest sosowane dopelnienie) ... mozesz sobie sporawdzic ze na nie vlanowym interfejsie bedzie tak samo ...

Nicram napisał(-a):
lenght mam puszczona_wielkosc+8, np. jak pinga puszcze z -s 1000 to w lenght mam 1008.

to 8 bieze sie z dlugosci naglowka ICMP

Nicram napisał(-a):
bercik napisał(-a):
sugeruje jakis bug w sofcie serwera ...
we wszystkich?? nie możliwe. testuje to na kilku hostach i na wszystkich efekt ten sam.

raczej nie we wszystkich ... pozatym skoro jajko fabryczne z Lenny to na 100% powinno tam chodzic (mam kilka hostow uzywajacych vlanow tagowanych gdzie po drugiej stronie jest odtagfowany na switchu i wszystko chodzi z MTU 1500)

jak wspomnialem jedyny problem tego typu spotkalem na WLA-5000AP v1.0 z OpenWRT ... nie wypuszczal ramek ethernetowych o wielkosci 1530 bajtow i trzeba bylo zmniejszyc MTU o 4 (tyle bajtow doklada tagowanie vlan'u)

pozatym skoro jak pisales polaczenie tagowany vlan - tagowany vlan dziala z MTU 1500 to znaczy ze takie ramki (1530 bajtow) host wypuszcza i akceptuje ... wiec moze cos w konfiguracji switcha lub w jego firmware ... nie powinno miec znaczenia czy generuje je drugi host czy tez switch poprzez dolozenie 4 bajtow do golej (1526 bajtowej) ramki ethernetowej

sproboj:
* przetestowac polaczenie: kompA:eth0.7 - switchA:port_ztagowanym_vlan7 - switchA:port_roztalogwany - switchB:port_roztagowany - switchB:port_ztagowanym_vlan7 - kompB:eth0.7 oczywiscie bez manipulowania MTU
* wychwycic cala (z naglowkiem ethernetowsim i suma kontrolna) ta ramke powrotna ktora jest widoczna tylko w trybie promisc (z lenght 1480) i popatrzec o z nia jest nie tak (suma kontrolna?) ze normalnie jest ignorowana

Nicram napisał(-a):
zastanawiam się jeszcze nad jednym.
utorze interfejs br7 do którego dołącze vlan7. z vlan7 zdejme adresacje i ustawie na br7.
teoretycznie pakiet 1500 wyjdzie br7 -> zostanie odtagowany na vlan7, pozniej na switchach tag zostanie zdjęty i teoretycznie powinno zadziałać, ale to bede mógł przetestować jutro.
jak to nie pomoże to bedzie kaplica :( nawet na mikrotiku vlany lepiej by działały :(

raczej nie wiele da bo i tak jadro musi uznac ze ta dluga tagowana ramka jest dla niego (czego z jakiegos powodu nie robi) ...

Nicram · 2010-11-21 18:32:36

bercik napisał(-a):
sproboj:
* przetestowac polaczenie: kompA:eth0.7 - switchA:port_ztagowanym_vlan7 - switchA:port_roztalogwany - switchB:port_roztagowany - switchB:port_ztagowanym_vlan7 - kompB:eth0.7 oczywiscie bez manipulowania MTU
* wychwycic cala (z naglowkiem ethernetowsim i suma kontrolna) ta ramke powrotna ktora jest widoczna tylko w trybie promisc (z lenght 1480) i popatrzec o z nia jest nie tak (suma kontrolna?) ze normalnie jest ignorowana

jutro pokombinuje z tymi switchami.
jak moge wychwycic kompletnie cala ramke??

---
oj chyba muszę przyznać rację. na biurkowej sieci wsio normalnie działa jak książka pisze a na produkcyjnym nie.

Ostatnio edytowany przez Nicram (2010-11-22 12:36:44)

bercik · 2010-11-22 19:31:42

Nicram napisał(-a):
jak moge wychwycic kompletnie cala ramke??

z suma kontrolna to chyba nie tak latwo ... ale z naglowkiem itd to np.:

Kod:

tcpdump -i eth0 -XX -e -vvv -s 2000 icmp

Nicram napisał(-a):
oj chyba muszę przyznać rację. na biurkowej sieci wsio normalnie działa jak książka pisze a na produkcyjnym nie.

to teraz trzeba ustalic czym roznia sie te srodowiska ...

Nicram · 2010-11-22 20:03:59

bercik napisał(-a):
to teraz trzeba ustalic czym roznia sie te srodowiska ...

qrde, cale zycie bylem przekonany, ze na tym co mam problemy mam stabilnego debiana. a teraz sprawdzam i sam oczom nie wierze - zainstalowalem testinga :(
w sumie mialbyc to taki serwerek do testow itp, a zostal przeznaczony na serwer do vpn. moze ten testing mam problem.
no chyba ze szukac przyczyny gdzie indziej?
zastanawiajace jest to ze po zmniejszeniu mtu do 1496 ruch tcp dziala normalnie, a ping > 1500 tylko jesli karta jest w trybie promisc no i mtu tez zmniejszone.

dzis jeszcze dla testu odpalilem kilka interfejsow valnowych na innych serwerkach i tam tez normalnie dziala bez grzebania w mtu :)

bercik · 2010-11-22 23:58:58

Nicram napisał(-a):
bercik napisał(-a):
to teraz trzeba ustalic czym roznia sie te srodowiska ...
qrde, cale zycie bylem przekonany, ze na tym co mam problemy mam stabilnego debiana. a teraz sprawdzam i sam oczom nie wierze - zainstalowalem testinga :(
w sumie mialbyc to taki serwerek do testow itp, a zostal przeznaczony na serwer do vpn. moze ten testing mam problem.
no chyba ze szukac przyczyny gdzie indziej?

jakie jadro w tym testing? ... mam jednego testinga (jadro 2.6.32-5-xen-amd64) oraz kilka stable z tym samym jadrem i problemow tam nie ma ...

Nicram napisał(-a):
zastanawiajace jest to ze po zmniejszeniu mtu do 1496 ruch tcp dziala normalnie

moze dziala jakis mechanizm negocjacji wielkosci MTU w sciezce ... zobacz czy nie pojawiaja sie pakiety ICMP "Fragmentation required" ...

Nicram napisał(-a):
a ping > 1500 tylko jesli karta jest w trybie promisc no i mtu tez zmniejszone.

a to jest dziwne - pakiet jest, ale host nie uznaje ze do niego :-/

Nicram napisał(-a):
dzis jeszcze dla testu odpalilem kilka interfejsow valnowych na innych serwerkach i tam tez normalnie dziala bez grzebania w mtu :)

bo tak powinno dzialac :-)

Nicram · 2010-11-23 09:10:28

bercik napisał(-a):
jakie jadro w tym testing? ... mam jednego testinga (jadro 2.6.32-5-xen-amd64) oraz kilka stable z tym samym jadrem i problemow tam nie ma ...

Linux sat 2.6.32-trunk-686 #1 SMP Sun Jan 10 06:32:16 UTC 2010 i686 GNU/Linux

bercik napisał(-a):
moze dziala jakis mechanizm negocjacji wielkosci MTU w sciezce ... zobacz czy nie pojawiaja sie pakiety ICMP "Fragmentation required" ...

no właśnie nie. pakiety sa normalnie fragmentowane

bercik napisał(-a):
Nicram napisał(-a):
a ping > 1500 tylko jesli karta jest w trybie promisc no i mtu tez zmniejszone.
a to jest dziwne - pakiet jest, ale host nie uznaje ze do niego :-/

:/

qluk · 2010-11-23 12:45:09

Jeśli chcesz wykluczyć błąd softu to zrób mu pętle, czyli jednym interfejsem poprzez krossa jak i potem switch puść na drugi interfejs. Jeśli to nie chwyci to możesz szukać błędu w systemie.

bercik · 2010-11-23 15:28:26

Nicram napisał(-a):
bercik napisał(-a):
jakie jadro w tym testing? ... mam jednego testinga (jadro 2.6.32-5-xen-amd64) oraz kilka stable z tym samym jadrem i problemow tam nie ma ...
Linux sat 2.6.32-trunk-686 #1 SMP Sun Jan 10 06:32:16 UTC 2010 i686 GNU/Linux

sproboj na jakims nowszym ... moze pomoze ...

Nicram napisał(-a):
bercik napisał(-a):
moze dziala jakis mechanizm negocjacji wielkosci MTU w sciezce ... zobacz czy nie pojawiaja sie pakiety ICMP "Fragmentation required" ...
no właśnie nie. pakiety sa normalnie fragmentowane

na pewno? ... co sie dzieje jak host po drugiej stronie zaczyna jakis duzy transfer (tak rzeby dac 1500 bajtowy pakiet)?

Nicram · 2010-11-23 18:15:55

bercik napisał(-a):
na pewno? ... co sie dzieje jak host po drugiej stronie zaczyna jakis duzy transfer (tak rzeby dac 1500 bajtowy pakiet)?

oto proba przesłania pliku z hosta wewnątrz vlan7 (172.21.7.10) do swerwera (172.21.7.1):
pierwszy listing tcpdump -pni eth0 - na .7.10- z hosta który wysyła:

Kod:

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
18:06:32.468431 IP 172.21.7.10.50820 > 172.21.7.1.22: P 805927975:805928119(144) ack 812064200 win 330 <nop,nop,timestamp 541709732 541705629>
18:06:32.507634 IP 172.21.7.1.22 > 172.21.7.10.50820: . ack 144 win 190 <nop,nop,timestamp 541710134 541709732>
18:06:32.551174 IP 172.21.7.1.22 > 172.21.7.10.50820: P 1:33(32) ack 144 win 190 <nop,nop,timestamp 541710144 541709732>
18:06:32.551186 IP 172.21.7.10.50820 > 172.21.7.1.22: . ack 33 win 330 <nop,nop,timestamp 541709753 541710144>
18:06:32.554706 IP 172.21.7.10.50820 > 172.21.7.1.22: P 144:272(128) ack 33 win 330 <nop,nop,timestamp 541709754 541710144>
18:06:32.554869 IP 172.21.7.1.22 > 172.21.7.10.50820: . ack 272 win 215 <nop,nop,timestamp 541710145 541709754>
18:06:32.556576 IP 172.21.7.1.22 > 172.21.7.10.50820: P 33:81(48) ack 272 win 215 <nop,nop,timestamp 541710146 541709754>
18:06:32.556768 IP 172.21.7.10.50820 > 172.21.7.1.22: P 272:400(128) ack 81 win 330 <nop,nop,timestamp 541709754 541710146>
18:06:32.557337 IP 172.21.7.1.22 > 172.21.7.10.50820: P 81:161(80) ack 400 win 239 <nop,nop,timestamp 541710146 541709754>
18:06:32.563955 IP 172.21.7.1.22 > 172.21.7.10.50820: P 161:209(48) ack 400 win 239 <nop,nop,timestamp 541710148 541709754>
18:06:32.564039 IP 172.21.7.10.50820 > 172.21.7.1.22: . ack 209 win 330 <nop,nop,timestamp 541709756 541710146>
18:06:32.564197 IP 172.21.7.10.50820 > 172.21.7.1.22: P 400:464(64) ack 209 win 330 <nop,nop,timestamp 541709756 541710146>
18:06:32.564560 IP 172.21.7.1.22 > 172.21.7.10.50820: P 209:257(48) ack 464 win 239 <nop,nop,timestamp 541710148 541709756>
18:06:32.575340 IP 172.21.7.10.50820 > 172.21.7.1.22: . 464:7704(7240) ack 257 win 330 <nop,nop,timestamp 541709759 541710148>
18:06:32.771657 IP 172.21.7.1.22 > 172.21.7.10.50820: P 209:257(48) ack 464 win 239 <nop,nop,timestamp 541710200 541709756>
18:06:32.771724 IP 172.21.7.10.50820 > 172.21.7.1.22: . ack 257 win 330 <nop,nop,timestamp 541709808 541710200,nop,nop,sack 1 {209:257}>
18:06:32.781848 IP 172.21.7.10.50820 > 172.21.7.1.22: . 464:1912(1448) ack 257 win 330 <nop,nop,timestamp 541709811 541710200>
18:06:33.197841 IP 172.21.7.10.50820 > 172.21.7.1.22: . 464:1912(1448) ack 257 win 330 <nop,nop,timestamp 541709915 541710200>
18:06:34.029857 IP 172.21.7.10.50820 > 172.21.7.1.22: . 464:1912(1448) ack 257 win 330 <nop,nop,timestamp 541710123 541710200>
18:06:35.693847 IP 172.21.7.10.50820 > 172.21.7.1.22: . 464:1912(1448) ack 257 win 330 <nop,nop,timestamp 541710539 541710200>
18:06:39.021848 IP 172.21.7.10.50820 > 172.21.7.1.22: . 464:1912(1448) ack 257 win 330 <nop,nop,timestamp 541711371 541710200>
18:06:45.677849 IP 172.21.7.10.50820 > 172.21.7.1.22: . 464:1912(1448) ack 257 win 330 <nop,nop,timestamp 541713035 541710200>
18:06:58.989860 IP 172.21.7.10.50820 > 172.21.7.1.22: . 464:1912(1448) ack 257 win 330 <nop,nop,timestamp 541716363 541710200>
18:07:20.567620 arp who-has 172.21.7.10 tell 172.21.7.1
18:07:20.567644 arp reply 172.21.7.10 is-at 00:0e:2e:f0:97:76
18:07:25.613848 IP 172.21.7.10.50820 > 172.21.7.1.22: . 464:1912(1448) ack 257 win 330 <nop,nop,timestamp 541723019 541710200>




listening on vlan7, link-type EN10MB (Ethernet), capture size 96 bytes
18:06:32.468505 IP 172.21.7.10.50820 > 172.21.7.1.22: Flags [P.], seq 805927975:805928119, ack 812064200, win 330, options [nop,nop,TS val 541709732 ecr 541705629], length 144
18:06:32.507599 IP 172.21.7.1.22 > 172.21.7.10.50820: Flags [.], ack 144, win 190, options [nop,nop,TS val 541710134 ecr 541709732], length 0
18:06:32.551131 IP 172.21.7.1.22 > 172.21.7.10.50820: Flags [P.], seq 1:33, ack 144, win 190, options [nop,nop,TS val 541710144 ecr 541709732], length 32
18:06:32.551226 IP 172.21.7.10.50820 > 172.21.7.1.22: Flags [.], ack 33, win 330, options [nop,nop,TS val 541709753 ecr 541710144], length 0
18:06:32.554784 IP 172.21.7.10.50820 > 172.21.7.1.22: Flags [P.], seq 144:272, ack 33, win 330, options [nop,nop,TS val 541709754 ecr 541710144], length 128
18:06:32.554834 IP 172.21.7.1.22 > 172.21.7.10.50820: Flags [.], ack 272, win 215, options [nop,nop,TS val 541710145 ecr 541709754], length 0
18:06:32.556529 IP 172.21.7.1.22 > 172.21.7.10.50820: Flags [P.], seq 33:81, ack 272, win 215, options [nop,nop,TS val 541710146 ecr 541709754], length 48
18:06:32.556838 IP 172.21.7.10.50820 > 172.21.7.1.22: Flags [P.], seq 272:400, ack 81, win 330, options [nop,nop,TS val 541709754 ecr 541710146], length 128
18:06:32.557285 IP 172.21.7.1.22 > 172.21.7.10.50820: Flags [P.], seq 81:161, ack 400, win 239, options [nop,nop,TS val 541710146 ecr 541709754], length 80
18:06:32.563912 IP 172.21.7.1.22 > 172.21.7.10.50820: Flags [P.], seq 161:209, ack 400, win 239, options [nop,nop,TS val 541710148 ecr 541709754], length 48
18:06:32.564100 IP 172.21.7.10.50820 > 172.21.7.1.22: Flags [.], ack 209, win 330, options [nop,nop,TS val 541709756 ecr 541710146], length 0
18:06:32.564252 IP 172.21.7.10.50820 > 172.21.7.1.22: Flags [P.], seq 400:464, ack 209, win 330, options [nop,nop,TS val 541709756 ecr 541710146], length 64
18:06:32.564516 IP 172.21.7.1.22 > 172.21.7.10.50820: Flags [P.], seq 209:257, ack 464, win 239, options [nop,nop,TS val 541710148 ecr 541709756], length 48
18:06:32.771605 IP 172.21.7.1.22 > 172.21.7.10.50820: Flags [P.], seq 209:257, ack 464, win 239, options [nop,nop,TS val 541710200 ecr 541709756], length 48
18:06:32.771769 IP 172.21.7.10.50820 > 172.21.7.1.22: Flags [.], ack 257, win 330, options [nop,nop,TS val 541709808 ecr 541710200,nop,nop,sack 1 {209:257}], length 0
18:07:20.567586 ARP, Request who-has 172.21.7.10 tell 172.21.7.1, length 28
18:07:20.567679 ARP, Reply 172.21.7.10 is-at 00:0e:2e:f0:97:76, length 46

ze strony wysyłającego mam --stalled--
jak na serwerze 172.21.7.1 na vlan7 zmienie mtu 1496 to transfer idzie.

bercik · 2010-11-23 23:50:34

1. pokazane listingi nie sa od poczatku (bark najistotniejszego fragmentu - nawiazywania polaczenia TCP)
2. w tym wypadku istotnie nie fragmentuje sie pakietow IP (nie ma zastosowania mechanizm ustalania MTU sciezki w oparciu o ICMP*), natomaist ma zastosowanie mechanizm wbudowany w TCP - ustalenia MSS (hosty podaja swoje MSS ktore wynosi w tym przypadku MTU-40 ... wiec w ten sposob druga strona wie zeby nie wysylac za duzych pakietow):

Kod:

22:47:21.648898 IP 172.16.16.29.33936 > 172.16.16.30.4022: S 1555559137:1555559137(0) win 5808 <mss 1452,sackOK,timestamp 420273 0,nop,wscale 6>
22:47:21.649177 IP 172.16.16.30.4022 > 172.16.16.29.33936: S 1395707437:1395707437(0) ack 1555559138 win 1392 <mss 360,sackOK,timestamp 3941565595 420273,nop,wscale 7>

*) detekcja PMTU dziala (mozna ja obserwowac np. w wyniku komendy tracepath) w przypadku gdy mamy sytuacjie:
host A (mtu=1500) --- intA (mtu=1500) router int B (mtu=500) -- host B (mtu=500)
natomiast gdy nie ma routingu host docelowy nie zwraca stosownego ICMP (widac rozne MTU w ramach jednej sieci fizycznej sa zbyt duza patologia aby oprogramowanie przejmowalo sie taka sytuacja)

Nicram · 2010-11-24 09:23:32

bercik napisał(-a):
1. pokazane listingi nie sa od poczatku (bark najistotniejszego fragmentu - nawiazywania polaczenia TCP)

no w sumie tak, nie wziąłem pod uwagę samego logowania :)
oto kompletny wydruk z obu hostów:

Kod:

~# tcpdump -pni eth0 host 172.21.7.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:18:56.367722 IP 172.21.7.10.33708 > 172.21.7.1.22: S 542391042:542391042(0) win 5840 <mss 1460,sackOK,timestamp 555395707 0,nop,wscale 5>
09:18:56.367852 IP 172.21.7.1.22 > 172.21.7.10.33708: S 545323640:545323640(0) ack 542391043 win 5792 <mss 1460,sackOK,timestamp 555396099 555395707,nop,wscale 6>
09:18:56.367887 IP 172.21.7.10.33708 > 172.21.7.1.22: . ack 1 win 183 <nop,nop,timestamp 555395707 555396099>
09:18:56.377335 IP 172.21.7.1.22 > 172.21.7.10.33708: P 1:33(32) ack 1 win 91 <nop,nop,timestamp 555396101 555395707>
09:18:56.377530 IP 172.21.7.10.33708 > 172.21.7.1.22: . ack 33 win 183 <nop,nop,timestamp 555395709 555396101>
09:18:56.377637 IP 172.21.7.10.33708 > 172.21.7.1.22: P 1:33(32) ack 33 win 183 <nop,nop,timestamp 555395709 555396101>
09:18:56.377816 IP 172.21.7.1.22 > 172.21.7.10.33708: . ack 33 win 91 <nop,nop,timestamp 555396101 555395709>
09:18:56.377892 IP 172.21.7.10.33708 > 172.21.7.1.22: P 33:825(792) ack 33 win 183 <nop,nop,timestamp 555395710 555396101>
09:18:56.378159 IP 172.21.7.1.22 > 172.21.7.10.33708: . ack 825 win 116 <nop,nop,timestamp 555396101 555395710>
09:18:56.379205 IP 172.21.7.1.22 > 172.21.7.10.33708: P 33:817(784) ack 825 win 116 <nop,nop,timestamp 555396102 555395710>
09:18:56.379382 IP 172.21.7.10.33708 > 172.21.7.1.22: P 825:849(24) ack 817 win 232 <nop,nop,timestamp 555395710 555396102>
09:18:56.382149 IP 172.21.7.1.22 > 172.21.7.10.33708: P 817:969(152) ack 849 win 116 <nop,nop,timestamp 555396102 555395710>
09:18:56.384747 IP 172.21.7.10.33708 > 172.21.7.1.22: P 849:993(144) ack 969 win 281 <nop,nop,timestamp 555395711 555396102>
09:18:56.407944 IP 172.21.7.1.22 > 172.21.7.10.33708: P 969:1689(720) ack 993 win 140 <nop,nop,timestamp 555396109 555395711>
09:18:56.411364 IP 172.21.7.10.33708 > 172.21.7.1.22: P 993:1009(16) ack 1689 win 330 <nop,nop,timestamp 555395718 555396109>
09:18:56.450245 IP 172.21.7.1.22 > 172.21.7.10.33708: . ack 1009 win 140 <nop,nop,timestamp 555396120 555395718>
09:18:56.450259 IP 172.21.7.10.33708 > 172.21.7.1.22: P 1009:1057(48) ack 1689 win 330 <nop,nop,timestamp 555395728 555396120>
09:18:56.450358 IP 172.21.7.1.22 > 172.21.7.10.33708: . ack 1057 win 140 <nop,nop,timestamp 555396120 555395728>
09:18:56.450485 IP 172.21.7.1.22 > 172.21.7.10.33708: P 1689:1737(48) ack 1057 win 140 <nop,nop,timestamp 555396120 555395728>
09:18:56.450634 IP 172.21.7.10.33708 > 172.21.7.1.22: P 1057:1121(64) ack 1737 win 330 <nop,nop,timestamp 555395728 555396120>
09:18:56.453519 IP 172.21.7.1.22 > 172.21.7.10.33708: P 1737:1801(64) ack 1121 win 140 <nop,nop,timestamp 555396120 555395728>
09:18:56.453663 IP 172.21.7.10.33708 > 172.21.7.1.22: P 1121:1361(240) ack 1801 win 330 <nop,nop,timestamp 555395728 555396120>
09:18:56.454719 IP 172.21.7.1.22 > 172.21.7.10.33708: P 1801:1865(64) ack 1361 win 165 <nop,nop,timestamp 555396121 555395728>
09:18:56.493842 IP 172.21.7.10.33708 > 172.21.7.1.22: . ack 1865 win 330 <nop,nop,timestamp 555395739 555396121>
09:19:01.626370 IP 172.21.7.10.33708 > 172.21.7.1.22: P 1361:1505(144) ack 1865 win 330 <nop,nop,timestamp 555397022 555396121>
09:19:01.666241 IP 172.21.7.1.22 > 172.21.7.10.33708: . ack 1505 win 190 <nop,nop,timestamp 555397424 555397022>
09:19:01.709039 IP 172.21.7.1.22 > 172.21.7.10.33708: P 1865:1897(32) ack 1505 win 190 <nop,nop,timestamp 555397434 555397022>
09:19:01.709050 IP 172.21.7.10.33708 > 172.21.7.1.22: . ack 1897 win 330 <nop,nop,timestamp 555397042 555397434>
09:19:01.709229 IP 172.21.7.10.33708 > 172.21.7.1.22: P 1505:1633(128) ack 1897 win 330 <nop,nop,timestamp 555397042 555397434>
09:19:01.709344 IP 172.21.7.1.22 > 172.21.7.10.33708: . ack 1633 win 215 <nop,nop,timestamp 555397434 555397042>
09:19:01.714395 IP 172.21.7.1.22 > 172.21.7.10.33708: P 1897:1945(48) ack 1633 win 215 <nop,nop,timestamp 555397436 555397042>
09:19:01.714498 IP 172.21.7.10.33708 > 172.21.7.1.22: P 1633:1761(128) ack 1945 win 330 <nop,nop,timestamp 555397044 555397436>
09:19:01.715117 IP 172.21.7.1.22 > 172.21.7.10.33708: P 1945:2025(80) ack 1761 win 239 <nop,nop,timestamp 555397436 555397044>
09:19:01.721517 IP 172.21.7.1.22 > 172.21.7.10.33708: P 2025:2073(48) ack 1761 win 239 <nop,nop,timestamp 555397437 555397044>
09:19:01.721544 IP 172.21.7.10.33708 > 172.21.7.1.22: . ack 2073 win 330 <nop,nop,timestamp 555397045 555397436>
09:19:01.721777 IP 172.21.7.10.33708 > 172.21.7.1.22: P 1761:1825(64) ack 2073 win 330 <nop,nop,timestamp 555397045 555397436>
09:19:01.722128 IP 172.21.7.1.22 > 172.21.7.10.33708: P 2073:2121(48) ack 1825 win 239 <nop,nop,timestamp 555397437 555397045>
09:19:01.722913 IP 172.21.7.10.33708 > 172.21.7.1.22: . 1825:9065(7240) ack 2121 win 330 <nop,nop,timestamp 555397046 555397437>
09:19:01.922275 IP 172.21.7.1.22 > 172.21.7.10.33708: P 2073:2121(48) ack 1825 win 239 <nop,nop,timestamp 555397488 555397045>
09:19:01.922334 IP 172.21.7.10.33708 > 172.21.7.1.22: . ack 2121 win 330 <nop,nop,timestamp 555397096 555397488,nop,nop,sack 1 {2073:2121}>
09:19:01.929850 IP 172.21.7.10.33708 > 172.21.7.1.22: . 1825:3273(1448) ack 2121 win 330 <nop,nop,timestamp 555397098 555397488>
09:19:02.345840 IP 172.21.7.10.33708 > 172.21.7.1.22: . 1825:3273(1448) ack 2121 win 330 <nop,nop,timestamp 555397202 555397488>
09:19:03.177843 IP 172.21.7.10.33708 > 172.21.7.1.22: . 1825:3273(1448) ack 2121 win 330 <nop,nop,timestamp 555397410 555397488>
09:19:04.841846 IP 172.21.7.10.33708 > 172.21.7.1.22: . 1825:3273(1448) ack 2121 win 330 <nop,nop,timestamp 555397826 555397488>
09:19:08.169847 IP 172.21.7.10.33708 > 172.21.7.1.22: . 1825:3273(1448) ack 2121 win 330 <nop,nop,timestamp 555398658 555397488>
09:19:14.825848 IP 172.21.7.10.33708 > 172.21.7.1.22: . 1825:3273(1448) ack 2121 win 330 <nop,nop,timestamp 555400322 555397488>
^C
46 packets captured
46 packets received by filter
0 packets dropped by kernel




~# tcpdump -pni vlan7 host 172.21.7.10 and not host 172.17.2.6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan7, link-type EN10MB (Ethernet), capture size 96 bytes
09:18:56.369156 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [s], seq 542391042, win 5840, options [mss 1460,sackOK,TS val 555395707 ecr 0,nop,wscale 5], length 0
09:18:56.369196 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [S.], seq 545323640, ack 542391043, win 5792, options [mss 1460,sackOK,TS val 555396099 ecr 555395707,nop,wscale 6], length 0
09:18:56.369306 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [.], ack 1, win 183, options [nop,nop,TS val 555395707 ecr 555396099], length 0
09:18:56.378664 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 1:33, ack 1, win 91, options [nop,nop,TS val 555396101 ecr 555395707], length 32
09:18:56.378958 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [.], ack 33, win 183, options [nop,nop,TS val 555395709 ecr 555396101], length 0
09:18:56.379063 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 1:33, ack 33, win 183, options [nop,nop,TS val 555395709 ecr 555396101], length 32
09:18:56.379163 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [.], ack 33, win 91, options [nop,nop,TS val 555396101 ecr 555395709], length 0
09:18:56.379465 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 33:825, ack 33, win 183, options [nop,nop,TS val 555395710 ecr 555396101], length 792
09:18:56.379507 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [.], ack 825, win 116, options [nop,nop,TS val 555396101 ecr 555395710], length 0
09:18:56.380383 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 33:817, ack 825, win 116, options [nop,nop,TS val 555396102 ecr 555395710], length 784
09:18:56.380814 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 825:849, ack 817, win 232, options [nop,nop,TS val 555395710 ecr 555396102], length 24
09:18:56.383461 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 817:969, ack 849, win 116, options [nop,nop,TS val 555396102 ecr 555395710], length 152
09:18:56.386201 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 849:993, ack 969, win 281, options [nop,nop,TS val 555395711 ecr 555396102], length 144
09:18:56.409137 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 969:1689, ack 993, win 140, options [nop,nop,TS val 555396109 ecr 555395711], length 720
09:18:56.412796 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 993:1009, ack 1689, win 330, options [nop,nop,TS val 555395718 ecr 555396109], length 16
09:18:56.451590 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [.], ack 1009, win 140, options [nop,nop,TS val 555396120 ecr 555395718], length 0
09:18:56.451689 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 1009:1057, ack 1689, win 330, options [nop,nop,TS val 555395728 ecr 555396120], length 48
09:18:56.451703 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [.], ack 1057, win 140, options [nop,nop,TS val 555396120 ecr 555395728], length 0
09:18:56.451819 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 1689:1737, ack 1057, win 140, options [nop,nop,TS val 555396120 ecr 555395728], length 48
09:18:56.452071 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 1057:1121, ack 1737, win 330, options [nop,nop,TS val 555395728 ecr 555396120], length 64
09:18:56.454851 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 1737:1801, ack 1121, win 140, options [nop,nop,TS val 555396120 ecr 555395728], length 64
09:18:56.455135 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 1121:1361, ack 1801, win 330, options [nop,nop,TS val 555395728 ecr 555396120], length 240
09:18:56.456051 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 1801:1865, ack 1361, win 165, options [nop,nop,TS val 555396121 ecr 555395728], length 64
09:18:56.495264 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [.], ack 1865, win 330, options [nop,nop,TS val 555395739 ecr 555396121], length 0
09:19:01.627826 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 1361:1505, ack 1865, win 330, options [nop,nop,TS val 555397022 ecr 555396121], length 144
09:19:01.667589 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [.], ack 1505, win 190, options [nop,nop,TS val 555397424 ecr 555397022], length 0
09:19:01.710379 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 1865:1897, ack 1505, win 190, options [nop,nop,TS val 555397434 ecr 555397022], length 32
09:19:01.710472 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [.], ack 1897, win 330, options [nop,nop,TS val 555397042 ecr 555397434], length 0
09:19:01.710678 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 1505:1633, ack 1897, win 330, options [nop,nop,TS val 555397042 ecr 555397434], length 128
09:19:01.710692 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [.], ack 1633, win 215, options [nop,nop,TS val 555397434 ecr 555397042], length 0
09:19:01.715727 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 1897:1945, ack 1633, win 215, options [nop,nop,TS val 555397436 ecr 555397042], length 48
09:19:01.715950 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 1633:1761, ack 1945, win 330, options [nop,nop,TS val 555397044 ecr 555397436], length 128
09:19:01.716446 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 1945:2025, ack 1761, win 239, options [nop,nop,TS val 555397436 ecr 555397044], length 80
09:19:01.722850 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 2025:2073, ack 1761, win 239, options [nop,nop,TS val 555397437 ecr 555397044], length 48
09:19:01.722966 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [.], ack 2073, win 330, options [nop,nop,TS val 555397045 ecr 555397436], length 0
09:19:01.723215 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [P.], seq 1761:1825, ack 2073, win 330, options [nop,nop,TS val 555397045 ecr 555397436], length 64
09:19:01.723465 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 2073:2121, ack 1825, win 239, options [nop,nop,TS val 555397437 ecr 555397045], length 48
09:19:01.923604 IP 172.21.7.1.22 > 172.21.7.10.33708: Flags [P.], seq 2073:2121, ack 1825, win 239, options [nop,nop,TS val 555397488 ecr 555397045], length 48
09:19:01.923759 IP 172.21.7.10.33708 > 172.21.7.1.22: Flags [.], ack 2121, win 330, options [nop,nop,TS val 555397096 ecr 555397488,nop,nop,sack 1 {2073:2121}], length 0
^C
39 packets captured
39 packets received by filter
0 packets dropped by kernel

bercik · 2010-11-24 19:21:01

ale to jest w tej konfiguracji gdzie musisz zmniejszac mtu na vlanie czy w tej gdzie wszystko chodzi jak trzeba? bo juz sie gubie ...

Nicram · 2010-11-24 20:53:17

bercik napisał(-a):
ale to jest w tej konfiguracji gdzie musisz zmniejszac mtu na vlanie czy w tej gdzie wszystko chodzi jak trzeba? bo juz sie gubie ...

w tej co musze zmieniac mtu na interfejsie vlanowym. 7.1 - serwer na ktorym jest interfejs vlan7. 7.10 - host w vilanie za switchem.

Forum Debian Users Gang

Ogłoszenie

#1 2010-11-19 12:00:05

Nicram - Użytkownik

zwiekszenie MTU

Kod:

Kod:

Kod:

#2 2010-11-19 12:08:37

Punisher999 - Użytkownik

Re: zwiekszenie MTU

#3 2010-11-19 12:40:15

Nicram - Użytkownik

Re: zwiekszenie MTU

Punisher999 napisał(-a):

#4 2010-11-19 23:06:27

bercik - Moderator Mamut

Re: zwiekszenie MTU

Nicram napisał(-a):

Nicram napisał(-a):

#5 2010-11-20 11:07:42

Nicram - Użytkownik

Re: zwiekszenie MTU

bercik napisał(-a):

bercik napisał(-a):

bercik napisał(-a):

bercik napisał(-a):

bercik napisał(-a):

bercik napisał(-a):

Kod:

bercik napisał(-a):

#6 2010-11-20 15:14:37

bercik - Moderator Mamut

Re: zwiekszenie MTU

Nicram napisał(-a):

bercik napisał(-a):

Nicram napisał(-a):

Nicram napisał(-a):

bercik napisał(-a):

Nicram napisał(-a):

bercik napisał(-a):

Nicram napisał(-a):

Nicram napisał(-a):

Nicram napisał(-a):

bercik napisał(-a):

#7 2010-11-21 13:47:04

Nicram - Użytkownik

Re: zwiekszenie MTU

bercik napisał(-a):

Nicram napisał(-a):

Kod:

Kod:

Kod:

Kod:

bercik napisał(-a):

Nicram napisał(-a):

bercik napisał(-a):

Nicram napisał(-a):

bercik napisał(-a):

Nicram napisał(-a):

bercik napisał(-a):

bercik napisał(-a):

Nicram napisał(-a):

#8 2010-11-21 16:14:42

bercik - Moderator Mamut

Re: zwiekszenie MTU

Nicram napisał(-a):

Nicram napisał(-a):

Nicram napisał(-a):

bercik napisał(-a):

Nicram napisał(-a):

#9 2010-11-21 18:32:36

Nicram - Użytkownik

Re: zwiekszenie MTU

bercik napisał(-a):

#10 2010-11-22 19:31:42

bercik - Moderator Mamut

Re: zwiekszenie MTU

Nicram napisał(-a):

Kod: