MTU/Overhead bei PPPoA

Alle technisch orientierten Fragen und Diskussionen rund um Internet-Zugänge via ADSL und xDSL (alle DSL-basierenden Technologien).
Forumsregeln
Alle technisch orientierten Fragen und Diskussionen rund um Internet-Zugänge via ADSL und xDSL (alle DSL-basierenden Technologien).

Diskussionen ĂĽber Provider (deren Produkte und Dienstleistungen) werden im Bereich PROVIDER gefĂĽhrt.

Beitragvon superracer » Mi 23 Mai, 2007 13:22

spiessb hat geschrieben:ich kann dir nur sagen was bei ispa-ta-dsl providern wie happynet/i3b/linea7, etel, inode-ta-dsl, uta-ta-dsl, net4you .... u.s.w. passiert.
wir alle bekommen von der telekom einen vpdn tunnel in dem als protokoll pptp gesprochen wird. dieser tunnel hat eine mtu size von 1500 byte - das pptp protokoll nimmt sich 40 byte weg, wobei 1460 ĂĽberbleiben.
die config mit pppoA ist die config die du machen musst, wenn du mit einem device auskommen willst und dsl-modem+router in einem gerät machst. das ändert aber nichts daran, dass trotzdem ein ppptp drüberläuft.
ich kenn die rfc´s nicht auswendig wie das protokolltechnisch exakt abläuft - was ich dir aber mit sicherheit sagen kann ist, dass ich von dem atm und pppoA nichts zu mir bekomme, sondern ich nur ein pptp im vpdn tunnel sehe - und somit sind die 1460 fix - egal was auch immer du ein deinem router treibst - du kannst maximal mtu-blackholes produzieren - aber sicher nicht die mtu size von gesamtlink nach oben beeinflussen


baaahhh...

TA reseller bekommen einen L2TP tunnel (genauer gesagt mehrere) - von PPTP sieht kein reseller irgendeine spur.

und reseller können diese tunnel durchaus per ATM übergeben bekommen, wodurch beim ent/einkapseln der IP-pakete keine MTU-probleme auftreten.
superracer
Board-User Level 3
Board-User Level 3
 
Beiträge: 1073
Registriert: So 04 Jul, 2004 11:18

Beitragvon spiessb » Mi 23 Mai, 2007 13:28

du hast zu 50% recht

es ist ein l2tp tunnel und der 40 byte header ist nicht der pptp header sondern der l2tp header - da hab ich mich vertan.

das wo du falsch liegst ist die atm ĂĽbergabe - wir hatten beides - es spielt keine rolle ob die uebernahme mit atm oder ethernet kommt - es ist in beiden faellen ein l2tp tunnel der 40 byte braucht - die mtu probleme im herbst bei der mtu verkuerzung hatten wir noch am atm - das ist jetzt am ethernet nicht anders

lg
bernd
spiessb
Board-Mitglied
Board-Mitglied
 
Beiträge: 123
Registriert: Mo 08 Jan, 2007 14:46

Beitragvon superracer » Mi 23 Mai, 2007 13:45

eigentlich hat L2TP ja einen noch höheren overhead als PPTP, und zwar kommen da zum L2TP-header nochmal ein IP- und ein UDP-header dazu (weil L2TP ja über UDP geht), somit ist die eigentliche MTU hier noch kleiner.

dank IP-fragmentierung können aber nichtsdestotrotz sowohl bei PPTP als auch bei L2TP frames mit größe 1500 übertragen werden - sie müssen nur in den darunterliegenden layern (de)fragmentiert werden.

und es spielt doch eine rolle, ob die übergabe per ethernet oder ATM passiert. ethernet hat eine MTU von 1500, ATM hat eine weit höhere MTU, somit können die IP/UDP/L2TP/PPP/IP/... pakete größer als 1500 bytes sein - die MTU am ATM-interface muß nur entsprechend gesetzt sein.
superracer
Board-User Level 3
Board-User Level 3
 
Beiträge: 1073
Registriert: So 04 Jul, 2004 11:18

Beitragvon cremor » Mi 23 Mai, 2007 17:10

Ok, wenn auch bei einer Direkteinwahl per Multiuser Modem ein PPTP/L2TP-Paket beim Provider ankommt habe ich einen Overhead von 40 (bzw. mehr) Byte.

Was ich aber dann noch nicht verstehe: ATM ist ja nicht an die MTU Grenze von Ethernet gekoppelt, sollte also auch "mein" IP-Paket + den Header übertragen können. Wenn also das Paket durchgehend von meinem Modem bis zum Provider über ATM übertragen wird, warum dann die Beschränkung am Speedtouch WAN-Interface :-?

mfg cremor
A1 Festnetz-Internet 8 Mbit/s
SpeedTouch 585v6 - Firmware 5.3.9.0
cremor
Board-Mitglied
Board-Mitglied
 
Beiträge: 167
Registriert: Mo 22 Mai, 2006 10:02

Beitragvon BillSuxx » Mi 23 Mai, 2007 17:18

irgendwas ist "mir" noch immer nicht klar. wenn der L2TP-tunnel 40 bytes "frisst", warum zeigt mir einerseits das atm-interface eine MTU von 1500 an und warun kann ich andererseits 1500 bytes unfragmentiert ĂĽbertragen?
Code: Alles auswählen
C877>sh int atm0
ATM0 is up, line protocol is up
  Hardware is PQUICC_SAR (with Alcatel ADSL Module)
  MTU 1500 bytes, sub MTU 1500, BW 512 Kbit, DLY 80 usec,
     reliability 255/255, txload 12/255, rxload 1/255
  Encapsulation ATM, loopback not set
  Encapsulation(s): AAL5  AAL2, PVC mode
  10 maximum active VCs, 64 VCs per VP, 1 current VCCs
  VC Auto Creation Disabled.
  VC idle disconnect time: 300 seconds
  Last input never, output 00:00:02, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Per VC Queueing
  5 minute input rate 1000 bits/sec, 2 packets/sec
  5 minute output rate 25000 bits/sec, 1 packets/sec
     243884 packets input, 62580558 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     266737 packets output, 269390740 bytes, 0 underruns
     0 output errors, 0 collisions, 3 interface resets
     0 output buffer failures, 0 output buffers swapped out

:-?
BillSuxx
Board-Mitglied
Board-Mitglied
 
Beiträge: 160
Registriert: Mi 16 Jun, 2004 14:40

Beitragvon spiessb » Do 24 Mai, 2007 08:31

eine atm ĂĽbergabe hat wenn ich das jetzt noch richtig im kopf habe 4096 byte anstatt 1500 wie beim ethernet.
das ganze ist aber trotzdem nur theorie weil die 4096 meiner erfahrung nach trotzdem nicht end-to-end durchgehen -
mindestens eine komponente ist in der ta uebertragungsstrecke, die das auf 1500 beschraenkt.
insofern ist es egal ob der backhaul link jetzt mit atm oder ethernet gebaut wird. die telekom ist was mtu sizes groesser als 1500 betrifft, mehr als nur kompliziert.
bis zu dieser schon mehrfach erwaehnten umstellung der telekom austria am 18.10.2006 von einer cisco bras lösung auf eine juniper erx lösung war es möglich, mit dos ping netto 1472 = brutto 1500 durchzupingen - trotz l2tp tunnel - das ging deshalb weil der cisco intern "irgendwie" fragmentiert hat, ohne dass es aufgefallen ist (dont-fragment-bit wirkungslos).
der juniper macht das nicht mehr - der hat seine mtu von 1500 minus den 40 byte fĂĽr den l2tp tunnel.
ob das auch fĂĽr aon kunden gilt weiss ich nicht - ispa-ta-dsl ist jedenfalls bei allen providern auf 1460.

@billsuxx - der physische ĂĽbertragungslink wird immer 1500 anzeigen - dein paket das vom router weggeht, hat auch auch volle 1500 byte - nur hast davon "logisch" 40 verloren - d.h. logisch durchbringen tust brutto nur 1460 - daher kann es sein dass du 1500 siehst aber nur 1460 hast.
wegen dem 1500er ping unfragmentier: hast du aon oder ispa-dsl ?
spiessb
Board-Mitglied
Board-Mitglied
 
Beiträge: 123
Registriert: Mo 08 Jan, 2007 14:46

Beitragvon wernerkl » Do 24 Mai, 2007 08:43

so das schreibt meiner im vergleich:


Werner#sh int a0
ATM0 is up, line protocol is up
Hardware is MPC ATMSAR (with Alcatel ADSL Module)
Description: - ADSL Verbindung
MTU 4470 bytes, sub MTU 4470, BW 384 Kbit, DLY 960 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5 AAL2, PVC mode
10 maximum active VCs, 1024 VCs per VP, 2 current VCCs
VC Auto Creation Disabled.
VC idle disconnect time: 300 seconds
Last input never, output 00:00:08, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1453642
Queueing strategy: Per VC Queueing
30 second input rate 1000 bits/sec, 1 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
9527701 packets input, 2114110206 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
4260698 packets output, 710420865 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
wernerkl
Board-Guru
Board-Guru
 
Beiträge: 6575
Registriert: So 08 Jan, 2006 17:56
Wohnort: Deutschlandsberg

Beitragvon BillSuxx » Do 24 Mai, 2007 08:45

Hab ISPA-ADSL bei LINEA7. Ein Ping mit 1472 wird nicht fragmentiert. Ab 1473 wird fragmentiert. Dies entspricht einer MTU von 1500 (Header 28 Bytes)
Code: Alles auswählen
Ping host3.linea7.net [195.16.241.170] mit 1472 Bytes Daten:

Antwort von 195.16.241.170: Bytes=1472 Zeit=52ms TTL=59
Antwort von 195.16.241.170: Bytes=1472 Zeit=51ms TTL=59
Antwort von 195.16.241.170: Bytes=1472 Zeit=48ms TTL=59
Antwort von 195.16.241.170: Bytes=1472 Zeit=50ms TTL=59

Ping-Statistik fĂĽr 195.16.241.170:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 48ms, Maximum = 52ms, Mittelwert = 50ms

C:\Dokumente und Einstellungen\Hartmut>ping -f -l 1473 www.linea7.com

Ping host3.linea7.net [195.16.241.170] mit 1473 Bytes Daten:

Paket mĂĽsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket mĂĽsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket mĂĽsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket mĂĽsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Ping-Statistik fĂĽr 195.16.241.170:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),
BillSuxx
Board-Mitglied
Board-Mitglied
 
Beiträge: 160
Registriert: Mi 16 Jun, 2004 14:40

Beitragvon superracer » Do 24 Mai, 2007 08:48

@billsuxx: auf deiner seite gibt's ja noch kein L2TP, nur PPPoA. auĂźerdem hast du ja noch ein dialer-interface, das dem PPP-interface entspricht. dort wirst du deine kleinere MTU haben.
superracer
Board-User Level 3
Board-User Level 3
 
Beiträge: 1073
Registriert: So 04 Jul, 2004 11:18

Beitragvon BillSuxx » Do 24 Mai, 2007 11:01

superracer hat geschrieben:@billsuxx: auf deiner seite gibt's ja noch kein L2TP, nur PPPoA. auĂźerdem hast du ja noch ein dialer-interface, das dem PPP-interface entspricht. dort wirst du deine kleinere MTU haben.

so - jetzt habe ich mir das dialer-interface angeschaut. auch hier MTU 1500 per default:
Code: Alles auswählen
C877>sh int d1
Dialer1 is up, line protocol is up (spoofing)
  Hardware is Unknown
  Internet address is 195.16.251.46/32
  MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, loopback not set
  DTR is pulsed for 1 seconds on reset
  Interface is bound to Vi2
  Last input never, output never, output hang never
  Last clearing of "show interface" counters 02:33:37
  Input queue: 0/224/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/0/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 42 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     68803 packets input, 12798721 bytes
     78256 packets output, 83649084 bytes
Bound to:
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  MTU 1500 bytes, BW 56 Kbit, DLY 100000 usec,
     reliability 255/255, txload 57/255, rxload 36/255
  Encapsulation PPP, LCP Open
  Listen: CDPCP
  Open: IPCP
  PPPoATM vaccess, cloned from Dialer1
  Bound to ATM0 VCD: 1, VPI: 8, VCI: 48, loopback not set
  DTR is pulsed for 5 seconds on reset
  Interface is bound to Di1 (Encapsulation PPP)
  Last input 00:00:03, output never, output hang never
  Last clearing of "show interface" counters 02:32:59
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 8000 bits/sec, 7 packets/sec
  5 minute output rate 102000 bits/sec, 7 packets/sec
     68813 packets input, 12798951 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     78265 packets output, 83650674 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

was nu? :-? ich nehme nichts als "gegeben" hin. ich möchte immer den causalen und nachvollziehbaren zusammenhang wissen.
Zuletzt geändert von BillSuxx am Do 24 Mai, 2007 11:09, insgesamt 1-mal geändert.
BillSuxx
Board-Mitglied
Board-Mitglied
 
Beiträge: 160
Registriert: Mi 16 Jun, 2004 14:40

Beitragvon jutta » Do 24 Mai, 2007 11:06

<OT>

C877>sh int atm0

C837>sh int d1

wieviele ciscos hast du dzt angeschlossen?
jutta
Administrator
Administrator
 
Beiträge: 30485
Registriert: Do 15 Apr, 2004 10:48
Wohnort: wien

Beitragvon BillSuxx » Do 24 Mai, 2007 11:10

jutta hat geschrieben:<OT>

C877>sh int atm0

C837>sh int d1

wieviele ciscos hast du dzt angeschlossen?

an sich einen mit 2 logins (bzw configs)! habs zur allgemeinen ĂĽbersichtlichkeit korrigiert.
die eine config ist zum testen und basteln.
BillSuxx
Board-Mitglied
Board-Mitglied
 
Beiträge: 160
Registriert: Mi 16 Jun, 2004 14:40

Beitragvon superracer » Do 24 Mai, 2007 11:15

check zur sicherheit auch mal sh ip int d1

und sonst: beim rauspingen mit größeren paketen, von wem (welcher ip) kriegst du das icmp fragmentation needed? (mitsniffen!)
superracer
Board-User Level 3
Board-User Level 3
 
Beiträge: 1073
Registriert: So 04 Jul, 2004 11:18

Beitragvon BillSuxx » Do 24 Mai, 2007 11:30

superracer hat geschrieben:check zur sicherheit auch mal sh ip int d1

und sonst: beim rauspingen mit größeren paketen, von wem (welcher ip) kriegst du das icmp fragmentation needed? (mitsniffen!)

auch damit schauts nicht anders aus:
Code: Alles auswählen
C877>sh ip int d1
Dialer1 is up, line protocol is up
  Internet address is 195.16.251.46/32
  Broadcast address is 255.255.255.255
  Address determined by IPCP
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is enabled
  Local Proxy ARP is disabled
  Security level is default
  Split horizon is enabled
  ICMP redirects are always sent
  ICMP unreachables are always sent
  ICMP mask replies are never sent
  IP fast switching is enabled
  IP fast switching on the same interface is enabled
  IP Flow switching is disabled
  IP CEF switching is disabled
  IP Fast switching turbo vector
  IP multicast fast switching is enabled
  IP multicast distributed fast switching is disabled
  IP route-cache flags are Fast
  Router Discovery is disabled
  IP output packet accounting is disabled
  IP access violation accounting is disabled
  TCP/IP header compression is disabled
  RTP/IP header compression is disabled
  Policy routing is disabled
  Network address translation is disabled
  WCCP Redirect outbound is disabled
  WCCP Redirect inbound is disabled
  WCCP Redirect exclude is disabled
  BGP Policy Mapping is disabled

etherreal sagt mir dass die ip vom dialer fragmentiert (ab 1472 payload aufwärts). da hab ich schon heute früh gecheckt. nachdem das forum länger down war hatte ich genügend zeit. war etwas schwierig da im LAN überall 1500 als MTU eingetragen ist.
das hab ich schon heute frĂĽch gecheckt.
BillSuxx
Board-Mitglied
Board-Mitglied
 
Beiträge: 160
Registriert: Mi 16 Jun, 2004 14:40

Beitragvon superracer » Do 24 Mai, 2007 11:37

ähm naja, ist eigentlich eh klar... 1500er paket kommt auf ethernet rein, der cisco routet's ins Dialer1 rein (auch MTU 1500), packt's entsprechend in PPP/PPPoA ein, paket wird entsprechend größer und muß dann übers ATM0 verschickt werden -- geht nicht, weil ATM0 MTU 1500 hat. eigentlich eh klar, oder?
superracer
Board-User Level 3
Board-User Level 3
 
Beiträge: 1073
Registriert: So 04 Jul, 2004 11:18

VorherigeNächste

ZurĂĽck zu ADSL & xDSL

Wer ist online?

Mitglieder in diesem Forum: Google [Bot] und 156 Gäste