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

• #6484 rdi veterán GuB3Ra #6481

  Új Válasz 2008-08-30 08:24:03 #6484

  Ú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

  

  rdi

  veterán

  válasz GuB3Ra #6481 üzenetére

  Router típusa?

  Fej! Tor! Potroh!

• #6504 rdi veterán GuB3Ra #6497

  Új Válasz 2008-09-03 19:42:36 #6504

  Ú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

  

  rdi

  veterán

  válasz GuB3Ra #6497 üzenetére

  kicsit féle, hogy túl hosszú de:

  "PPPoE and MTU sizes

  The Maximum Transmission Unit (MTU) is the largest size packet that a network link can carry. Ethernet's MTU is 1500 bytes. When an IP packet is carried on ethernet, the full 1500 bytes is available to carry IP information. However, when running IP over PPP over Ethernet, an extra layer is introduced. PPPoE requires an 8 byte header. This means that a host running IP over PPPoE must set its MTU to 1492.

  The Maximum Segment Size (MSS) is the largest segment of user data that a TCP connection can carry. It is typically 40 bytes smaller than the underlying link's MTU. This is because a packet's IP header and TCP header are normally 20 bytes each. So when running TCP over IP on ethernet, every 1500 bytes of user data in the ethernet frame contains just 1460 bytes of TCP user data. When running TCP over IP over PPPoE, the MTU is 1492, so the maximum amount of user data that can be sent between TCP end-points is 1452 bytes.

  By default, all PPPoE clients set their MTU to 1492, so a PPPoE client will open all TCP connections with MSS advertisements of 1452. The TCP stack at the other side will honour this MSS, and will never send an IP packet larger than 1492 bytes. So everything is fine on the PPPoE client. What causes some people trouble is when they try to share their DSL line by putting other PCs on a LAN behind their PPPoE connection.

  When this happens, the PCs behind the client probably have MTUs of 1500, TCP will offer an MSS of 1460 to remote sites. When these remote sites try to send back packets, they run into difficulty because when the packets reach the ADSL connection, the MTU on the link is too small. An ICMP error will be generated telling them that their packets are too large and should be fragmented. This is a process known as Path MTU Discovery (PMTU-D). In theory, they should get this ICMP message and resend. In practice, this doesn't always happen. Unfortunately, many sites block ICMP, and this breaks the PMTU-D process. Mark Slemko has written a commonly referenced document on PMTU-D and ICMP.

  If the client PCs have their MTU set to that of the host running PPPoE (typically 1492 - but could be lower in the case of L2TP), this problem will never happen. TCP will ensure that the MSS is set appropriately low so that all packets will get through. However, a better solution is not to change all the internal PC's MTUs, but to use a gateway with a PPPoE implementation that is aware of the problem and can dynamically modify the MSS of a client PC's outgoing TCP packets. Most modern PPPoE routers and Unix PPPoE/NAT implementations can do this.

  Renaud Waldura's article on using PPPoE with FreeBSD has a good discussion of this.
  How bad is PPPoE?

  People offer lots of reasons for why PPPoE is a bad thing. Unfortunately, many of these don't stand up to very much scrutiny. Here's a few common arguments and counter-arguments.

  * PPPoE - it's just perverse!
  True, but the whole ADSL stack is perverse - IP over PPPoE over Ethernet over ATM over ADSL. PPPoE is just solving a problem with ADSL that already existed (data people want ethernet, telcos want ATM).
  * Too much overhead
  What you lose on bandwidth running IP over PPPoE (maybe 2%) is completely dwarfed by what you lose at the underlying layer running IP over ATM (about 15%), so this is the least good reason for not using PPPoE. In fact, by using PPPoE instead of PPPoA, there is an option to remove the underlying ATM layer in future without affecting the customer. Some people would argue that this is the best reason for ethernet based network configuration protocols such as PPPoE i.e. as an alternative to PPPoA. PPPoA ties the customer to the ATM infrastructure, and if your view is that ATM is a legacy access technology, then ATM should not be visible to customers in the form of PPPoA.
  * Why do I have to log in to an always-on service?!
  PPP (and hence PPPoE) allows authentication on a link, regardless of whether the link is up permanently or not. While default client software installations are configured to have you manually log in every time you want to use the Internet (and "preserve the dialup experience!"), automatic login on boot can be configured within the PPPoE client's settings. On a router or Unix box, this is exactly what happens, the PPPoE link is brought up automatically in the background with authentication taking place transparently.
  * I need extra software! DHCP doesn't!
  DHCP has been around longer than PPPoE. All recent operating systems have PPPoE built-in, so adding ISP software such as Enternet will not be necessary in the future. Remember that before Win95, TCP/IP was not part of Windows - it was an extra piece of 3rd party software.
  * What about the MTU problems?
  The lower MTU can cause problems, but these problems usually occur because of configuration errors in other parts of the network. If everyone followed the rules, it wouldn't matter what MTU was used. Unfortunately, incorrect assumptions are made, and things can break. But fundamentally, the Internet is an interconnection of many diverse networks, and MTU sizes will always differ across this network.
  "

  Fej! Tor! Potroh!

• #6514 rdi veterán GuB3Ra #6509

  Új Válasz 2008-09-06 16:26:13 #6514

  Ú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

  

  rdi

  veterán

  válasz GuB3Ra #6509 üzenetére

  Alapból, minden PPPoE ügyfél 1492-re veszi az MTUjukat, úgyhogy egy PPPoE ügyfél ki fog nyitni mindent TCP kapcsolatok az 1452-es MSS -el. Az TCP stack a másik oldalon el fogja fogadni ezt a MSS-et és soha nem fog küldeni nagyobb IP-csomagot 1492-nél. Tehát minden a PPPoE ügyfélen van. Ez, kérédéses okokból néhány ember aggaszt, mikor megpróbálják megosztani a DSL sorozatukat azáltal, hogy a PPPoE kapcsolatuk mögé tesznek további PC-ket egy LAN-on.

  Amikor ez történik, a PC-knek az ügyfél mögött valószínűleg 1500 éves MTUjuk van, a TCP fel fog ajánlani egy 1460 éves MSSot a távoli helyszíneknek. Amikor ezek a távoli helyszínek csomagokat próbálnak visszaküldeni , szembetalálják magukat azzal a nehézséggel, hogy amikor a csomagok elérik az ADSL kapcsolatot, a MTU azokon a kapcsolatokon túl kicsik. Ez egy ICMP hibát fog létrehozni miközben arrólértesíti őket, hogy a csomagjaik túl nagyok és darabolni kell. Ez egy eljárás, amit Path MTU Discoveryként ismert, (PMTU-D). Mark Slemko írt erről egy általános, jegyzetekkel ellátott dokumentumot..

  Ha az ügyfél PC-knek az MTU -jukat be tudja állítja mint az a tulajdonos , aki futtatja PPPoE-t, (ami jellemzően 1492 - de alacsonyabb tis lehet L2TP ügyében), ez a probléma soha nem fog megtörténni. A TCP biztosítani fogja azt az alacsony megfellelően beállított MSS-ot , hogy minden csomag beleférjen.

  valami ilyesmi

  Fej! Tor! Potroh!

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