Új hozzászólás Aktív témák

• #13445 józsi9995 tag Methionyl #13442

  Új Válasz 2017-08-10 13:47:27 #13445

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  józsi9995

  tag

  válasz Methionyl #13442 üzenetére

  sztem ez a link jó kiindulási alapnak, van benne minden mint a bucsuban

  https://learningnetwork.cisco.com/thread/40703

• #13444 kowika87 tag Methionyl #13442

  Új Válasz 2017-08-09 22:21:50 #13444

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  kowika87

  tag

  válasz Methionyl #13442 üzenetére

  Tenyleg ahogy soma irta ez jatszos tema.
  Ahogy en tudom L3 MTU = 1500 byte (alapeset) - 20 byte IPv4 header - 20 byte TCP header (ha TCP a packet)+ 1460 byte maradek. (IPv6 header 40 byte.)
  L2 MTU = 1518 vagy 1522 alabol, de platform fuggoen ez allithato es ide tartoznak a baby giant framek is ami nagyobb par byte-al mint a megengedett maximum de a switch nem dobja el, pl QinQ extra 4 byte eseten hasznos.

  Erre lehet rapakolni mindenfele csemeget viszont az MTU mereted nem mehet fole a maximumnak, ha ez megtortenik akkor fragmentalas tortenik.
  Szivas lehet ezzel ha pl a routeren van dot1q subinterface viszont az MTU nincs lecsokkentve 4 byte-al (VLAN tag) es a router nem tud kezelni 1518 nal nagyobb MTU-t. Tegyuk fel hogy a packet teljesen tele van 1500 byte (szep ez a magyar nyelv es a beallitott L3 MTU is 1500 byte. Ilyenkor a csomag kap 14 byte ethernet + 4 byte VLAN tag + 20 byte IP header + 1480 etc. A full packet igy mar 1522. En mar szivtam ezzel es a megoldas az volt hogy levenni a L3 MTU-t 1496-ra hogy elferjen az a plusz 4 byte.
  Es akkor itt jonnek meg a kulonbozo headerek PPP, GRE, IPSEC, amit eleg hosszan lehet elemezni ahogy azt soma emiltette.

  Az alap megerteshez meg wireshark sem feltetlen kell bar jobban nez ki

  1500 byte sima csomag:

  R8#debug ip packet
  R8#ping 1.1.1.2 si 1500 rep 1
  Type escape sequence to abort.
  Sending 1, 1500-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
  !
  Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms
  R8#
  IP: s=1.1.1.1 (local), d=1.1.1.2, len 1500, local feature, Logical MN local(14), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
  IP: s=1.1.1.1 (local), d=1.1.1.2 (Ethernet0/0), len 1500, sending
  IP: s=1.1.1.1 (local), d=1.1.1.2 (Ethernet0/0), len 1500, sending full packet
  IP: s=1.1.1.2 (Ethernet0/0), d=1.1.1.1, len 1500, input feature, MCI Check(101), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
  IP: tableid=0, s=1.1.1.2 (Ethernet0/0), d=1.1.1.1 (Ethernet0/0), routed via RIB
  IP: s=1.1.1.2 (Ethernet0/0), d=1.1.1.1 (Ethernet0/0), len 1500, rcvd 3
  IP: s=1.1.1.2 (Ethernet0/0), d=1.1.1.1, len 1500, stop process pak for forus packet

  1501byte csomag karamellaval toltve:

  R8#ping 1.1.1.2 si 1501 rep 1
  Type escape sequence to abort.
  Sending 1, 1501-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
  !
  Success rate is 100 percent (1/1), round-trip min/avg/max = 2/2/2 ms
  R8#
  IP: s=1.1.1.1 (local), d=1.1.1.2, len 1501, local feature, Logical MN local(14), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
  IP: s=1.1.1.1 (local), d=1.1.1.2 (Ethernet0/0), len 1501, sending
  IP: s=1.1.1.1 (local), d=1.1.1.2 (Ethernet0/0), len 1500, sending fragment
  IP: s=1.1.1.1 (local), d=1.1.1.2 (Ethernet0/0), len 1500, sending fragment
  IP: s=1.1.1.1 (local), d=1.1.1.2 (Ethernet0/0), len 21, sending last fragment
  IP: s=1.1.1.1 (local), d=1.1.1.2 (Ethernet0/0), len 21, sending last fragment
  IP: s=1.1.1.2 (Ethernet0/0), d=1.1.1.1, len 1500, input feature, MCI Check(101), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
  IP: tableid=0, s=1.1.1.2 (Ethernet0/0), d=1.1.1.1 (Ethernet0/0), routed via RIB
  IP: s=1.1.1.2 (Ethernet0/0), d=1.1.1.1 (Ethernet0/0), len 1500, rcvd 3
  IP: s=1.1.1.2 (Ethernet0/0), d=1.1.1.1, len 1500, stop process pak for forus packet
  IP: recv fragment from 1.1.1.2 offset 0 bytes
  IP: s=1.1.1.2 (Ethernet0/0), d=1.1.1.1, len 21, input feature, MCI Check(101), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
  IP: tableid=0, s=1.1.1.2 (Ethernet0/0), d=1.1.1.1 (Ethernet0/0), routed via RIB
  IP: s=1.1.1.2 (Ethernet0/0), d=1.1.1.1 (Ethernet0/0), len 21, rcvd 3
  IP: s=1.1.1.2 (Ethernet0/0), d=1.1.1.1, len 21, stop process pak for forus packet

  Az az egy byte mar nem fer el ezert uj packetbe kerul, 1 byte + 20 byte IP header. Micsoda pazarlas.

  Remelem segit.

• #13443 soma314 tag Methionyl #13442

  Új Válasz 2017-08-09 19:57:19 #13443

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  soma314

  tag

  válasz Methionyl #13442 üzenetére

  a legegyszerűbb megnézni saját szemmel egy wireshark capture-ből
  ez nem feltétlenül nagy feladat, mert vannak letölthető minták a wireshark oldalán:

  https://wiki.wireshark.org/SampleCaptures

  Ha nincs wireshark telepitve, akkor használhatod a cloudshark-ot is a packet-ek megtekintéséhez:

  https://www.cloudshark.org/

  Röviden a lényeg, hogy a GRE minimális overhead-del jár. Gyakorlatilag egy IPv4 header pluszban a packet-hez vágva.

  Az IPsec-re viszont nincs egyszerű válasz, mert az IPsec technológiák tömkelege. Attól függően, hogy milyen hashing-get, illetve milyen titkosítást használsz széles körben változhat az overhead-je.

  A PMTU alatt a path MTU discovery-re gondolhatsz. Az MTU a maximum transmission unit, azaz, hogy egy frame-ben, packetben mekkora lehet a fregmentáció nélkül a maximális mérték. Ennek más értéke lesz layer 2-re, frame-re és layer 3-ra, packetre. Ugye layer 3-ban is többféle rostokolt használunk, aminek mind más a header/(ha van trailer) mérete. Ugye még IP világon belül is lehet IPv4 vagy IPv6

  Az MSS a maximum segment size, ami a TCP window maximális méretét határozza meg. Értelem szerint ez csak TCP esetén van hatással (pl UDP esetén nincs). TCP esetén lehetne "layer 4 MTU-nak is tekinteni".
  Ennek értékét adod meg a tcp adjust-mss-el

  Ha igy kifejtve rákeresel a google millió hasznos oldalt hoz róluk, de ezek egy puzzle-nek a darabjai. Ahhoz, hogy a teljes képet lásd elég sok mindent el kell olvasni.

Új hozzászólás Aktív témák