Dynamik des IP-Verkehrs
Dirk Bossenz
ich befasse mich mit "Traffic Engineering" speziell vor dem Hintergrund
der GMPLS/ASON/NGN/... kurz der zukünftigen Paketnetze. Der größte
Wissensquell in dieser Hinsicht ist wohl das Buch "Verkehrstheorie in
IP-Netzen" und die Dissertation: "A System-oriented Approach to
Efficiency and Quality of Service for Internet Service Providers"
Leider fehlt in den beiden Schriften eine Quellenangabe über Messungen
oder sonstige vorweisbare Fakten von Ereignis-Abhängigen des dynamischen
IP-Verkehrs. Ist darüber etwas bekannt, was sich auch als freie Quelle
eignet?
Ich hab von mind. 2 Consultings die Bezahl-Studien gefunden, kann die
aber nicht nutzen. Caida liefert hier auch keine weiteren Informationen
(oder habe ich was übersehen?)
Das es dynamische Verkehrsbewegungen gibt, gerade wenn Web-Angebote in
den Blickpunkt der Aufmerksamkeit geraten - ich kann mich erinnern an
Artikel über hohe Trafficlasten bei Slashdot oder ebay gelesen zu haben.
Zumal die Diskussion über die Kostenbeteiligung der Content-Anbieter
nicht von ungefähr kommt, leider ist dieses Halbwissen jedoch nicht im
Rahmen meiner Arbeit verwertbar.
danke für Hinweise
Dirk
Oliver Bartels
wrote:
>Das es dynamische Verkehrsbewegungen gibt, gerade wenn Web-Angebote in
>den Blickpunkt der Aufmerksamkeit geraten - ich kann mich erinnern an
>Artikel über hohe Trafficlasten bei Slashdot oder ebay gelesen zu haben.
Richtung der Privatkunden (also Access, Eyeballs) schaut das
eigentlich nach meiner konkreten Erfahrung sehr einfach aus
(MRTG, der Graph ist aber auch bei uns nicht öffentlich):
Der Traffic liegt nachts beim Saugesel-Grundrauschen, läuft so ab
7 Uhr früh langsam hoch, zickt manchmal noch Mittags etwas und
fängt dann ab ca. 14 Uhr an bis zur Spitze 18 bis 20 Uhr hochzulaufen.
Wenn dann Fussball im Fernsehen kommt ;-) , geht es schneller,
sonst langsamer wieder runter, um 2 bis 4 Uhr nachts ist ungefähr
das Minimum erreicht.
Eventuelle "Events" gehen in dieser Kurve _völlig_ unter, es sei
denn, der Event heißt Weihnachten, dann ist sie etwas verformt.
Selbst bei unserem kleinen Access Netz (einige tausend Kunden)
mittelt sich der Traffic _völlig_ aus, Preferenzen in bestimmte
Verkehrsrichtungen abhängig von aktuellen Events sind nicht
erkennbar.
Beim Content ist es so, dass in der Tat z.B. durch Fernsehwerbung
mal für 1-2 Wochen der Traffic in Richtung eines konkreten
Webangebots deutlich anschwellen kann, wenn das Angebot aber
keine Downloads oder Videos beinhaltet, wird man sich mit
stehenden Datenströmen in der Region einiger MBit/s für HTTP
schon als eher recht prominent einschätzen dürfen.
Die meisten Eigner von Websites überschätzen die Popularität
ihrer Sites restlos. Was glaubst Du wohl, warum die Hoster den
Kunden Angebote wie 1000GB inklusive machen, das läuft nach
dem Schema "erreichen sie eh nicht, falls doch, wird gedrosselt
oder gekündigt". Aber typisch "erreichen sie eh nicht", denn
_die_ Angebote, die wirklich Traffic bringen, stehen nicht bei
irgendeinem Massenhoster.
Gruß Oliver
P.s.: Gilt selbst für EBay, wenn die wirklich Traffic hätten, dann
täten sie nicht alles nach Sacramento an die Westküste der
USA routen. Kontrollwahn hin oder her, am Ende vom Tag
schauen nämlich speziell US-Firmen aufs Geld, und offenbar
ist es billiger, die Transatlantikstrecke mit zu bezahlen, als
ein weiteres Rechenzentrum in der EU zu betreiben.
Die großen Sites (selbst ARD, ZDF usw.) nutzen vielfach
Akamai, da sind die Server lokal, und Google, die sicher jetzt
mit Youtube (Videos!) ordentlich Traffic haben dürften,
nutzen ein eigenes Netz.
--
Oliver Bartels + Erding, Germany + obar...@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Clemens Zauner
> ich befasse mich mit "Traffic Engineering" speziell vor dem Hintergrund
> der GMPLS/ASON/NGN/... kurz der zukünftigen Paketnetze. Der größte
> Wissensquell in dieser Hinsicht ist wohl das Buch "Verkehrstheorie in
> IP-Netzen" und die Dissertation: "A System-oriented Approach to
> Efficiency and Quality of Service for Internet Service Providers"
Solche Studien sind meist "eigenwillig" bis völlig unbedeutend im
"echten Leben". Von der Auslastung her gibts einfach Schwellwerte
bei den pps als auch den Volumina die einen Technologiewechsel
erfordern, der zur Zeit den Wechsels hohe Kosten verursacht
(also z.B. 100Base vs. 1GBit vs 10 GigE; bei SDH ist es dann
halt das "n" bei STM-n).
Upstream ist billig, im Zweifelsfall nimmt man halt noch einen.
Teuer sind einfach Technologiewechsel. QoS wird in den Studien
oft heillos überschätzt; im Core oft bedeutungslos - Richtung Edge
(schmale Access-bandbreiten) aufgrund von VOIP und Konsorten eher
ein Thema.
> Das es dynamische Verkehrsbewegungen gibt, gerade wenn Web-Angebote in
> den Blickpunkt der Aufmerksamkeit geraten - ich kann mich erinnern an
> Artikel über hohe Trafficlasten bei Slashdot oder ebay gelesen zu haben.
Ja, hier tut sich manchmal was. Selten in einem Rahmen der wirklich
auffällt und geht im Normalfall unter. Die Ausnahme hier sind DDoS
Sachen. Sowas kann wirklich weh tun (wenn auf einmal multiple 100 MBit
am Netz anklopfen ist das unlustig).
> Zumal die Diskussion über die Kostenbeteiligung der Content-Anbieter
> nicht von ungefähr kommt, leider ist dieses Halbwissen jedoch nicht im
> Rahmen meiner Arbeit verwertbar.
Diese Diskussion ist ein künstliche. Meines Wissens haben sich Portal-
Angebote nicht durchgesetzt - also ich bezweifle dass ein ISP/Netz mit
einer eingeschränkten Verfügbarkeite von Google/YouTube oder so ernsthaft
lange halten könnte.
Dem Kunden ist das nämlich egal - wenn YouTube beim ISP A langsamer ist
als bei ISP B ist der ISP A halt scheisse. Deshalb wird der Provider
(auch der Tier-1) der als erstes YouTube runterregelt, weil die denen
nix Zahlen, Kunden verlieren (der Usptream halt seine ISPs, weil
deren Kunden dort den Support nerven und/oder kündigen).
Ich bin mir aber ebenso sicher, das es irgendwer probieren wird. Und das
ganze auf die harte Tour lernt. Klar wird es da grosses Geschrei geben,
und Nebenwirkungen. Aber nach ein paar Jahren hat sich das dann wieder
ausgewachsen.
cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS
Florian Weimer
> Dirk Bossenz <tig...@lipsia.de> wrote:
>> ich befasse mich mit "Traffic Engineering" speziell vor dem Hintergrund
>> der GMPLS/ASON/NGN/... kurz der zukünftigen Paketnetze. Der größte
>> Wissensquell in dieser Hinsicht ist wohl das Buch "Verkehrstheorie in
>> IP-Netzen" und die Dissertation: "A System-oriented Approach to
>> Efficiency and Quality of Service for Internet Service Providers"
>
> Solche Studien sind meist "eigenwillig" bis völlig unbedeutend im
> "echten Leben".
Das trifft nicht bloß auf sogenannte Studien zu, sondern auf echte,
ernsthafte Forschungsarbeit. 8-P
> Dem Kunden ist das nämlich egal - wenn YouTube beim ISP A langsamer ist
> als bei ISP B ist der ISP A halt scheisse. Deshalb wird der Provider
> (auch der Tier-1) der als erstes YouTube runterregelt, weil die denen
> nix Zahlen, Kunden verlieren (der Usptream halt seine ISPs, weil
> deren Kunden dort den Support nerven und/oder kündigen).
Das spielt aber nur eine Rolle, wenn im Access-Bereich Wettbewerb
stattfindet. Mit QoS hat das aber nichts zu tun; Anwendungen, die nicht
bandbreitenintensiv oder zeitkritisch sind, kann man gar nicht so
deutlich verschlechtern -- es kommt irgendwann der Punkt, an dem gar
nichts mehr funktioniert, und davor ist's meist noch erträglich.
(Oracle hatte z.B. lange Zeit einen elend langsamen öffentlichen
Webserver, ohne daß davon die Firmenumsätze offensichtlich betroffen
gewesen wären.)
Florian Weimer
> Dirk Bossenz <tig...@lipsia.de> wrote:
>> ich befasse mich mit "Traffic Engineering" speziell vor dem Hintergrund
>> der GMPLS/ASON/NGN/... kurz der zukünftigen Paketnetze. Der größte
>> Wissensquell in dieser Hinsicht ist wohl das Buch "Verkehrstheorie in
>> IP-Netzen" und die Dissertation: "A System-oriented Approach to
>> Efficiency and Quality of Service for Internet Service Providers"
>
> Solche Studien sind meist "eigenwillig" bis völlig unbedeutend im
> "echten Leben".
Das trifft nicht bloß auf sogenannte Studien zu, sondern auf echte,
ernsthafte Forschungsarbeit. 8-P
> Dem Kunden ist das nämlich egal - wenn YouTube beim ISP A langsamer ist
> als bei ISP B ist der ISP A halt scheisse. Deshalb wird der Provider
> (auch der Tier-1) der als erstes YouTube runterregelt, weil die denen
> nix Zahlen, Kunden verlieren (der Usptream halt seine ISPs, weil
> deren Kunden dort den Support nerven und/oder kündigen).
Das spielt aber nur eine Rolle, wenn im Access-Bereich Wettbewerb
stattfindet. Mit QoS hat das aber nichts zu tun; Anwendungen, die nicht
bandbreitenintensiv oder zeitkritisch sind, kann man gar nicht so
deutlich verschlechtern -- es kommt irgendwann der Punkt, an dem gar
nichts mehr funktioniert, und kurz davor ist's meist noch erträglich.
Patrick M. Hausen
Clemens Zauner <cz+u...@onlineloop.com> wrote:
> > Zumal die Diskussion über die Kostenbeteiligung der Content-Anbieter
> > nicht von ungefähr kommt, leider ist dieses Halbwissen jedoch nicht im
> > Rahmen meiner Arbeit verwertbar.
>
> Diese Diskussion ist ein künstliche. Meines Wissens haben sich Portal-
> Angebote nicht durchgesetzt - also ich bezweifle dass ein ISP/Netz mit
> einer eingeschränkten Verfügbarkeite von Google/YouTube oder so ernsthaft
> lange halten könnte.
> Dem Kunden ist das nämlich egal - wenn YouTube beim ISP A langsamer ist
> als bei ISP B ist der ISP A halt scheisse. Deshalb wird der Provider
> (auch der Tier-1) der als erstes YouTube runterregelt, weil die denen
> nix Zahlen, Kunden verlieren (der Usptream halt seine ISPs, weil
> deren Kunden dort den Support nerven und/oder kündigen).
Ich habe immer noch nicht verstanden, woher diese Idee der Zahlung
irgendwelcher Beträge an den Access-Lieferanten durch den Content-
Anbieter überhaupt kommt, bzw. wie das gerechtfertigt oder auch nur
implementiert werden soll.
Der Content-Anbieter bezahlt doch schon für seine Bandbreite.
Oder gibt's jetzt irgendwo Hosting kostenlos? Und da sind dann
N TB drin oder flat oder was auch immer, und dann blase ich meinen
Content eben ins Netz. Damit ist der Traffic doch bezahlt. Technisch
gibt es zwischen Content und Access sowieso keinen Unterschied.
Die Richtung, gut. So what?
Also wofür soll der Content-Anbieter jetzt nochmal bezahlen?
Gruß,
Patrick
--
punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
in...@punkt.de http://www.punkt.de
Gf: Jürgen Egeling AG Mannheim 108285
Juergen Ilse
Patrick M. Hausen <hau...@nospam.de> wrote:
> Ich habe immer noch nicht verstanden, woher diese Idee der Zahlung
> irgendwelcher Beträge an den Access-Lieferanten durch den Content-
> Anbieter überhaupt kommt, bzw. wie das gerechtfertigt oder auch nur
> implementiert werden soll.
Das geht dir nicht nur alleine so. Diese ganze Diskussion (und die
staatliche Einmischung, die offenbar in den USA nach Meinung mancher
Leute dort in Gesetze gegossen werden soll) erscheint mir so abartig,
dass mir einfach weitere Worte dazu fehlen ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Clemens Zauner
> irgendwelcher Beträge an den Access-Lieferanten durch den Content-
> Anbieter überhaupt kommt, bzw. wie das gerechtfertigt oder auch nur
> implementiert werden soll.
Die "Idee" kommt daher, dass z.B. YouTube halt den Traffic nicht bei
sagen wir mal der Netz X einkauft, jedoch sind die Manager von X halt
der Ansicht, dass eben YouTube keinen Fuss auf den Boden kriegen
würde, weil sie ja den Traffic an den Kunden bringen. Und YouTube
keinen einzigen Fuss auf den Boden kriegen würde wenn X nicht wäre
(weil: keine Kunden).
Die Überlegung dahinter hinkt vorne und hinten - ergibt allerdings
bei Personen, die durch logisches Denken sehr herausgefordert sind
sehr wohl Sinn. Weder du noch ich müssen das verstehen. Sonst hätten
wir ja ein vergleichbares Problem (mit dem Denken).
> Der Content-Anbieter bezahlt doch schon für seine Bandbreite.
Ja, schon. Aber manche Leute konnten sich vom Gedanken der Terminierungs-
entgelte nicht lösen. Das steckt *ganz* *tief* *drinnen*. Im Prinzip
geht es darum um ein altes Geschäftsmodell halt am Leben zu erhalten
respektive auf was anders zu übertragen.
Traffic-Hogs sind da jetzt der Aufhänger; klar haben manche Leute
Probleme und haben erkannt dass Terminierungsentgelte mit VOIP mglw.
ein kleines Problem haben werden weiter CashCow zu spielen (ENUM!).
Weil irgendwann ist die Telefonnummer nicht mehr an einen Carrier
gebunden, sondern nur mehr ein DNS-Eintrag.
> Also wofür soll der Content-Anbieter jetzt nochmal bezahlen?
Für die Terminierung beim Kunden klarerweise. Oder für was anders.
Hängt davon ab, wer danach schreit.
Dirk Bossenz
> Upstream ist billig, im Zweifelsfall nimmt man halt noch einen.
> Teuer sind einfach Technologiewechsel. QoS wird in den Studien
> oft heillos überschätzt; im Core oft bedeutungslos - Richtung Edge
> (schmale Access-bandbreiten) aufgrund von VOIP und Konsorten eher
> ein Thema.
ja in diese Richtung sollte es bei QoS auch gehn, reiner Datenverkehr
ist ja nun nicht zwangsläufig zeitkritisch.
Mir geht es darum den Mehrwert von (G)-MPLS zu betrachten. Ob damit eben
Bewegungen im IP-Traffic durch die Autokonfiguration der LSP abgefangen
werden können, um zeitkritische Anwendungen welche im IP mehr und mehr
zu nehmen auch zu schützen.
dirk
Clemens Zauner
> Mir geht es darum den Mehrwert von (G)-MPLS zu betrachten. Ob damit eben
> Bewegungen im IP-Traffic durch die Autokonfiguration der LSP abgefangen
> werden können, um zeitkritische Anwendungen welche im IP mehr und mehr
> zu nehmen auch zu schützen.
Hmmm. Also zu GMPLS ist zu sagen, dass es ein wesentlich trivialerer
Ansatz, nämlich TOS-based OSPF nicht geschaft hat; es wird mangels
Einsatz nicht mehr unterstützt (hier konnten TOS-basiert unterschiedliche
shortest paths kalkuliert werden).
MPLS per se ist eigentlich seltener als QoS-Instrumentarium anzutreffen,
sondern vielmehr als "pseudo-wire" (vgl: VPN); $ISP kann seinen Kunden
so L2-Lösungen verticken (oder virtuelle Firmennetze, usw).
Die so entstehenden Produkte können nämlich für echtes Geld verrechnet
werden, sie steigern auch die Kundenbindung (sind nicht trivial teilw.
abzusiedeln, sondern eigentlich nur als ganzes).
Edge: $ISP will (oft) nicht, dass zeitkritische Anwendungen per se
preferenziert werden, sondern eher dass *seine* "zeitkritische Anwendungen"
preferenziert werden (vgl: div. "triple-Play" oder nur VOIP-gedöns).
Realisiert wird sowas z.B. mittles 2. VC über die TAL. In der Backhaul
kann die Abführung natürlich über MPLS erfolgen, klar. Das ist allerdings
nur mittel zum Zweck (um eben quasi ein ein VOIP-PN im Providernetz
aufzubauen).
Denn vergiss nicht: für $ISP ist es reichlich uninteressant dass $Kunde
"besser" über z.B. SipGate telephonieren kann. Alles was hier zählt, ist
dass die eigene VOIP-"Lösung" besser funktioniert.
Die erste Regel in IP Netzen: Komplexität ist böse. Auch wenns jetzt
funktioniert, irgendwann fällt einem sowas auf den Kopf. Und im
Massenberieich wegen den paar Euro / Produkt auf Basis einens nicht
erkennbaren Mehrwerts fürs eigne Netz eine MPLS to the Customer Premise
Lösung aufzubauen, die im Backoffice abzubilden und was der Teufel was
noch alles ist mglw. technisch machbar. Aber wo liegt denn da der Sinn
(fürs Geldbörsel des ISP)?
Dirk Bossenz
> Dirk Bossenz <tig...@lipsia.de> wrote:
> Hmmm. Also zu GMPLS ist zu sagen, dass es ein wesentlich trivialerer
> Ansatz, nämlich TOS-based OSPF nicht geschaft hat; es wird mangels
> Einsatz nicht mehr unterstützt (hier konnten TOS-basiert unterschiedliche
> shortest paths kalkuliert werden).
Aha, ich dachte GMPLS ist der Ansatz die Provisionierung von WDM, SDH,
Paket (ATM, GE, FR, ...) zu vereinheitlichen durch eine
Managmentsoftware, wenn nicht gar Autoprovisionierung - der Gegenentwurf
von der ITU-T heißt ASON ...hm.
Langsam komm ich da auch nicht mehr klar. Die ISP's sagen nicht wirklich
welche Technik sie wie nun nutzen, die Literatur welche es zu lesen gibt
erzählt mir von vielen Ing. verständlichen und logischen Sachverhalten,
so wie von der klassischen PSTN bekannt - so und nicht anderes würde ich
zukünftige paketorientierte All-Incl. Netze wohl betreiben wollen. Fragt
man aber konkret nach ist das alles nur Müll. Und der Netzwerker wird
zum Cisco-Zusammensteck-Äffchen degradiert ohne wirklich zu wissen was
er macht...wozu muß dann ein Ing. für IT sein, Telematik-Vorlesungen,
etc.alles vergebene Zeit?
Und fragt man bei ISP nach der Netztechnik oder einen Job in diese
Richtung wird auch nur Rumgedruckst. Anderseits gibt es einen
Fachkräfte-Mangel?
Kann man doch ALG2ler in Cisco-Schulen stecken und fertsch.
Dirk
Dirk Bossenz
> man aber konkret nach ist das alles nur Müll. Und der Netzwerker wird
> zum Cisco-Zusammensteck-Äffchen degradiert ohne wirklich zu wissen was
> er macht...wozu muß dann ein Ing. für IT sein, Telematik-Vorlesungen,
> etc.alles vergebene Zeit?
> Kann man doch ALG2ler in Cisco-Schulen stecken und fertsch.
Nachtrag:
Ich will nicht zu groß Aufschneiden, aber wenn ich mir die
Schulungs-Unterlagen und die Übungs-Software betrachte, da ist die eine
Hälfte Grundlagenwissen aus einemStudium und die andere Hälfte
Fallbeispiele mit Schritt-für-Schritt-Anleitung. Und nach meinen
bisherigen Erfahrungen ist mit der Anwendung des Cisco-Equipments auch
nur im Rahmen dieser gesteckter Parameter möglich - Andernfalls wird der
Kundendienst angerufen. Kompliziert und Schwierig wird es wohl nur dann
(lt. hören-sagen) wenn unterschiedliche Versionen von IOS im Spiel sind,
bzw. bestimmte Features nur mit dezidierten Versionen möglich sind. Und
dann meist auch nur mit einem aktuellen Backup zu beheben (was dann neue
Probleme bringt) - ein funktionierendes Geschäftsmodell.
Und bisher weiß ich nicht wo hier eine geistige Herrausforderung ist,
mit IOS nach Try&Error irgendwie spielen, ohne das ganze Netz dabei
kaputt zumachen und es trotzdem funktioniert hat IMHO nix mit einer
systematischen Verfahrensweise zu tun.
Bei Juniper&Co. wird es wohl nicht anderes sein, oder?
Oder hab ich nur eine verschrobene Wahrnehmung von den Sachverhalten?
Dirk
Clemens Zauner
> Aha, ich dachte GMPLS ist der Ansatz die Provisionierung von WDM, SDH,
> Paket (ATM, GE, FR, ...) zu vereinheitlichen durch eine
> Managmentsoftware, wenn nicht gar Autoprovisionierung - der Gegenentwurf
> von der ITU-T heißt ASON ...hm.
Und für was genau soll das gut sein? Also ich weiss nicht wie anderes
hier das sehen (aber ich habe eine Vermutung) - bei allem was Auto-
irgendwas ist stellen sich mir die Haare auf und mich befällt zumindest
ein leichtes Frösteln.
Alos Netzwerker: My Network - my rules. Automagismen sind des Teufels &
fallen dir in den Rücken. Nur hangestrickte Access-Policies sind gute
(ausser eventuell BGP4-Prefixfilter).
> Langsam komm ich da auch nicht mehr klar. Die ISP's sagen nicht wirklich
> welche Technik sie wie nun nutzen, die Literatur welche es zu lesen gibt
Sie verwenden der Problemstellung angepasste Techniken.
> man aber konkret nach ist das alles nur Müll. Und der Netzwerker wird
> zum Cisco-Zusammensteck-Äffchen degradiert ohne wirklich zu wissen was
> er macht...wozu muß dann ein Ing. für IT sein, Telematik-Vorlesungen,
> etc.alles vergebene Zeit?
Nein. Der Netzwerker erschafft sein Netz im Kopf und baut das dann.
Gottgleich. Wie war das nochmal: "And God spoke: There shall be
packets. And there were Packets. And the Packets were good. Mostly."
Im Prinzip muss man einfach so weit sein in Netzen zu denken,
diverse Kurse & Vorlesungen helfen eventuell bei den Grundlagen um
das zu verstehen. Graphentheorie braucht man. Man muss sie wirklich
verstanden haben. Der Rest ist Erfahrung.
Was das QoS anbelangt - welche Traffikklassen braucht man den bitte schön?
1) keine Ahnung was das ist / neutral.
2) eher wichtig.
3) eher unwichtig.
4) junk (= Saugesel & Konsorten).
Man kann das natürlich noch feiner abstufen, aber die Reihenfolge ist
hier 2 - 1 - 3 - 4. Und für sowas sollte man sich Auto-Irgendwas-am-
besten-nicht-Vendor-Interoperable mit zillionen Seiteneffekten ans Bein
binden? Geh bitte. Sowas geht bei >2 promille um 8:00 (also tiefste Nacht)
im Halbschlaf.
> Und fragt man bei ISP nach der Netztechnik oder einen Job in diese
> Richtung wird auch nur Rumgedruckst. Anderseits gibt es einen
> Fachkräfte-Mangel?
> Kann man doch ALG2ler in Cisco-Schulen stecken und fertsch.
Wenn die Kraft die Anforderungen erfüllt - weshalb nicht? Aber mal im Ernst;
zum Teil ist einfacher komplett Unbeleckten was beizubringen, als jemanden
nach Jahren der Ausbildung mal dazu zu bringen, den ganzen gelernten
Ballast zu vergessen und eben anders zu machen. So betrachtet ist die
Cisco-Schulung eigentlich Kontraproduktiv.
Im Prinzip muss man einfach intuitiv beliebig komplexe Netze im Kopf
auf die jeweiligen Punkt-zu-Punkt (Multipoint) Strecken reduzieren können.
Und zwar für jede. Das wars dann.
Ich stelle gar nicht in Abrede, dass ab einer gewissen Grösse Hilfsmittel
praktisch sind; in 90% der Fälle sollte als Hilfsmittel aber Papier und
Bleistift reichen. Wenn ein Netz nicht mehr intuitiv verständlich ist, ist
das entweder saugross (und davon gibt es wenige) oder man hat im Design
gepfuscht.
Einen guten Netzwertechniker erkennst du daran, dass seine Ergüsse leicht
verständlich sind (zumindest theoretisch). Unnötige Komplexität wird oft
mit Eleganz verwechselt - ist aber eigentlich meiner Ansicht nach das
Gegenteil davon.
cu
Clemens.
PS: obiges in in vielen Punkten etwas zugespitzt. Aber ich hoffe die
Grundidee "weniger ist mehr" kommt rüber.
Clemens Zauner
>> Kann man doch ALG2ler in Cisco-Schulen stecken und fertsch.
>
> Schulungs-Unterlagen und die Übungs-Software betrachte, da ist die eine
> Hälfte Grundlagenwissen aus einemStudium und die andere Hälfte
> Fallbeispiele mit Schritt-für-Schritt-Anleitung. Und nach meinen
Genau - zahlreiche "Old-Dogs" haben das so gelernt. Nur waren die
Fallbeispiele halt eigene Fälle. Oder man hats damals über Mailing-
listen mitinhaliert.
Grundlagenwissen reicht vollkommen. Man muss sich dann nur Fallen
lassen - und im besonderen schon vorher verstanden haben, wie IP
eigentlich funktioniert (im Besonderen das forwarding). Ein grossteil
der Netzprobleme (im echten Leben) kommen daher, dass es wieder wer
nicht geschnallt hat, dass wenn A mit B reden will es *nicht* reicht,
wenn die Packets von A nach B kommen, sondern auch die Packets von B
nach A müssen.
> Kundendienst angerufen. Kompliziert und Schwierig wird es wohl nur dann
> (lt. hören-sagen) wenn unterschiedliche Versionen von IOS im Spiel sind,
> bzw. bestimmte Features nur mit dezidierten Versionen möglich sind. Und
Nein, nein - da gibts noch ganz andere Fallstricke. Sonder Zahl. Und
man muss über fast jeden mal drüberstolpern. Damit man es wirklich glaubt.
> Und bisher weiß ich nicht wo hier eine geistige Herrausforderung ist,
> mit IOS nach Try&Error irgendwie spielen, ohne das ganze Netz dabei
> kaputt zumachen und es trotzdem funktioniert hat IMHO nix mit einer
> systematischen Verfahrensweise zu tun.
Nein. Man man spielt nicht mit Try and Error. Man sieht ein Problem, erkennt
es, weiss in welche Richtung man marschieren muss & setzt das dann genau so
um. Klar geht dabei mal was in die Hoste weil $HARD / -SOFTWARE genau
da jetzt zickt (oder man was übersehen hat). Aber im Normalfall solltest du
"the way to do it" anhand der Aufgabenstellung sofort erkennen. Zumindest
die Richtung.
> Oder hab ich nur eine verschrobene Wahrnehmung von den Sachverhalten?
Ja. Du denkst in Features. Die interessieren aber nicht besonders.
Du bietest eine Dienstleistung. Die ist typischerweise sowas wie:
"Will surfen" oder "100 MBit von A nach B". Und für sowas braucht
man den ganzen aufgeblasenen Bockmist nicht wirklich. Im zweiten
Beispiel gibst den Kunden halt zwei 100Base - Interfaces (eines in
A und eins in B) und karrst den Traffic zwischen den beiden Ports
irgendwie hin- und her.
(G)MPLS, QoS, pseudo-wire, you name ist ist was für den Produktfolder.
Shiny Names halt. $KUNDE ist es scheiss-egal wie du das realisierst - es
muss einfach (am besten im Wortsinne) funktionieren.
Dirk Bossenz
> In article <fnkk19$1ecd$1...@geiz-ist-geil.priv.at>, cz+u...@onlineloop.com
> Was ist das Problem, auf das
> mpls eine Loesung darstellt?
Traffic Engineering ?. Ich habe zeitkritische Anwendungen im Netz, ich
habe einen Transitweg mit vertraglich vereinbarten SLA durch mein Netz,
ich brauche "hot standby" Backup Pfade im Netz?
Ich kann doch nicht alles mit Overprovisionierung erschlagen? Das geht
doch nicht und ist zudem wohl auch noch unwirtschaftlich?
Gerade wenn von der Affinität zu Netzen gesprochen wird:
Transport/Warenwirtschaftssimulationen-Spiele, wenn ich da priorisierten
Verkehr einführe, dezidierte Pfade, Tranportgrößen festlege kann ich
einfach übersichtlicher, besser transportieren. Und auch wenn ich mich
mit Theorie-geplänkel wiederhole: der stochastische Transport wie in
Paketnetzen ist einfach rein rechnerisch nur bis zu 70% im Idelfall
auslastbar. Bei TDM, determinierten Transport 100% (mit dem Nachteil
überflüssige Kapazitäten nicht zu nutzen)
Und die Datenströme im IP sind eben in ihrem Eigenschaften auch
unterschiedlich so das - in simulierter Umgebung - durch die Trennung
und Schaffung von Traffic-Klassen sich auch schon der Durchsatz erhöht.
Dies hängt auch mit dem optimalen Einstellen der HTB vom MPLS mit ab.
Dirk
Clemens Zauner
>> (G)MPLS, QoS, pseudo-wire, you name ist ist was für den Produktfolder.
>
> VPN Loesungen fuer Fillialisten und Corporate Kunden fiele mir kein Problem
> ein, auf das mpls eine sinnvolle Loesung darstellt.
Im Prinzip stellen das ja auch die Anwendungsgebiete dar. Wenn man es schon
hat, kann man seine Managementinterfaces der Infrastruktur nach RFC1918
nummerieren und so recht billig vom Rest des Netzes isolieren.
Wie oben schon geschrieben - gerne sieht man das auch um das (eigene)
VOIP quasi einzusperren & mit 2.VC QoS dafür machen. Die VPNs kriegt man
als klein/mittel - ISP auch billiger mit VRF auf *dem* DSL-Terminierungs-
router (also MPLS nur auf einer Kiste, grob vereinfacht).
> Geschaeftsmodell gehoeren? Oder anders gefragt: Was ist das Problem, auf das
> mpls eine Loesung darstellt?
Das Modell "haben Lösung - suchen Problem" ist in der IT ja nix neues,
oder? Schau dir einfach mal an, wie alt MPLS jetzt eigentlich ist, und
seit wann das jetzt effektiv in freier Wildbahn auch anzutreffen ist.
Alleine an der Zeitspanne erkennt man, wie dringend nötig die Lösung
war. Da ja alle total drauf gewartet haben, wurde ja das in rasender
Geschwindigkeit in den letzten 8 Jahren flächendeckend zum Einsatz
gebracht.
Und dann schau noch mal hin, wieviel von Rollouts tatsächlich MPLS
zur Bandbreitenprovisionierung / management nehmen und das nicht eher
am Terminierungsinterface draufpappen. Freihändig. In den meisten Fällen
ist das eben mal ein L2-Tunnel. Dafür ists ja brauchbar. Aber ein bischen
Overkill.
Hier wurden halt Merkmale, die schon zum totalen Erfolg von ATM (CIR, VBR,
UBR) beigetragen hatten (brauchte man unbedingt, desh. ist ATM auch
total unverzichtbar, wie man sieht) mit viel Gewalt auf was anders
übertragen um diese Successstory dort genauso forsetzen zu können.
Und Packetswitching war immer schon dubios. MPLS bieten in die komischen
Netzen endlich wieder Pseudo-Circuits. Voll krass.
Clemens Zauner
> Traffic Engineering ?. Ich habe zeitkritische Anwendungen im Netz, ich
Definiere "zeitkritisch". Und dann nimm einen Phy mit sagen wir mal
1 GBit/sec (die sind billisch) und einer max. queue von 1000 packets.
Wie lange dauert da maximal bis auch das letzte Packet aus der queue
am Kabel pickt?
Was gewinnst du?
> habe einen Transitweg mit vertraglich vereinbarten SLA durch mein Netz,
> ich brauche "hot standby" Backup Pfade im Netz?
Es hilft ungemein, die SLA passend zu gestalten. Und inwieweit bieten
die OSPF / BGP nicht ohnehin alternativen im routing? Mit MPLS kann
ich aus einem Kabel ja auch nicht 2 machen und hier Redundanzen züchten
wo keine sind. Die anderen sollte das Routingprotokoll der Wahl finden.
> Ich kann doch nicht alles mit Overprovisionierung erschlagen? Das geht
> doch nicht und ist zudem wohl auch noch unwirtschaftlich?
Glaubst du nicht, dass da andere auch schon gerechnet haben? MPLS und
konsorten kriegt man ja nicht umsonst. Das kostet - und wenns nur Manpower
ist. Mitarbeiter die sowas pflegen wollen im allegmeinen auch bezahlt
werden. Und in einem Netz hat der Tag nun mal 24 Stunden. Nix mit
nine to five.
Und wer sagt dir, dass dir mit MPLS das Overprovisioning erspart bleibt?
ein 100Base-Interface kann nun mal nur eine bestimmte Datenmenge
durchsetzen. Nur weil ich jetzt da ganz heftig QoS mache, krieg ich ja
auch nicht auf einmal das doppelte durch.
Und jetzt mal im Ernst - bei den Trafficzuwachsraten ist mir ein
theoretischer Mehrdurchsatz von ein paar Prozent egal. Das zögert das
Upgrade eventuell ein-zwei Monate hinaus.
> Gerade wenn von der Affinität zu Netzen gesprochen wird:
> Transport/Warenwirtschaftssimulationen-Spiele, wenn ich da priorisierten
> Verkehr einführe, dezidierte Pfade, Tranportgrößen festlege kann ich
> einfach übersichtlicher, besser transportieren. Und auch wenn ich mich
Ah super. Es gibt also eine Simulation, wo das dann alles besser,
übersichtlicher und einfacher geht. Nachdems in der Realität anscheinend
anders ist, ist also zwangläufig:
[ ] die Realität fehlerhaft
[ ] die Simulation fehlerhaft
(Hmmm ... wenn ich das lese, bin ich versucht 2 Kreuze zu machen, egal).
> mit Theorie-geplänkel wiederhole: der stochastische Transport wie in
> Paketnetzen ist einfach rein rechnerisch nur bis zu 70% im Idelfall
Ach. Dann erzähl das blos nicht den Netzen. Sonst merken die das noch.
Das was ONU hat, ist X-fach überbucht. Und X ist 2-stellig. Mindestens.
Und du kannst Interfaces vollmachen. Wie in >90% ohne MPLS. Ehrlich.
> auslastbar. Bei TDM, determinierten Transport 100% (mit dem Nachteil
> überflüssige Kapazitäten nicht zu nutzen)
Deshalb hat sich das TDM-Zeug ja auch flächendeckend durchgesetzt.
Und ATM hat den Siegeszug angetreten. Und Ethernet ist quasi nichtexistent
(Token Ring auch nicht mehr, aber erst nachdem es Ethernet in der Markt-
durchdringung aber sowas von abgehängt hatte).
Deine Simulationen in Ehren - aber ich krieg bei den Argumenten so
DejaVu-Anfälle. All diese Argumente, Berechnungen und so weiter hatten
wir schon. Des Öfteren. Schau dir einfach die ATM-Karte deines Computer
an. Was? Hat keine?
> Und die Datenströme im IP sind eben in ihrem Eigenschaften auch
> unterschiedlich so das - in simulierter Umgebung - durch die Trennung
> und Schaffung von Traffic-Klassen sich auch schon der Durchsatz erhöht.
Beweis durch Behauptung. Oder wie? Simulationen sind ja ganz lustig.
Aber mach mal auf echten Netzen. Traue keiner Simulation, die du nicht
selbst manipuliert hast.
> Dies hängt auch mit dem optimalen Einstellen der HTB vom MPLS mit ab.
Ah! Die sind also alle einfach zu blöde die optimale Einstellung der
HTP vom MPLS zu treffen. Wenn man das nämlich macht, fällen am anderen
Ende schlagartig ein Businesscase und fette Gewinne raus. Und dann ist
das alles auch auf einmal total einfach. Und Konfiguriert sich quasi
von selbst. Da poppt dann ein ein Requester auf:
--------------------------------------
| Wollen sie MPLS wirklich verwenden |
| |
| [ Ja ] [ Nein ] |
--------------------------------------
Mach man [ Ja ] kommt der HTB Einstellungsassistent, dann [ fertig stellen ]
und schon hat man ein MPLS Netz. Das auf einmal 100% der Leistung bringt.
Wenn man aber [ Nein ] klickt, saufen alle Interfaces auf einmal auf
70% load vom Maxium ab & man ist im A**** daham.
Mahlzeit
Patrick Schaaf
>Ich kann doch nicht alles mit Overprovisionierung erschlagen?
Theoretisch nicht. Praktisch schon.
Gruss
Patrick
Patrick M. Hausen
Dirk Bossenz <tig...@lipsia.de> wrote:
> ich brauche "hot standby" Backup Pfade im Netz?
Was bringt MPLS da, was man mit $FAVOURITE_IGP nicht erschlagen kann?
Dirk Bossenz
> Mach man [ Ja ] kommt der HTB Einstellungsassistent, dann [ fertig stellen ]
> und schon hat man ein MPLS Netz. Das auf einmal 100% der Leistung bringt.
> Wenn man aber [ Nein ] klickt, saufen alle Interfaces auf einmal auf
> 70% load vom Maxium ab & man ist im A**** daham.
ist ja schon gut...dann müssen eben div. Lee/hrbücher mal umgeschrieben
werden !?
Dirk
Florian Weimer
> Ich kann doch nicht alles mit Overprovisionierung erschlagen? Das geht
> doch nicht und ist zudem wohl auch noch unwirtschaftlich?
Die Planung kostet auch Geld, selbst für den Fall, daß sie stimmt. Wenn
man unterschiedliche Geschäftseinheiten hat, aber nur ein Kernnetz,
entsteht schnell ein erheblicher Koordinierungsaufwand (z.B. weil man
sich auf gewisse QoS-Parameter und ihre Bedeutung einigen muß).
Florian Weimer
> Der Content-Anbieter bezahlt doch schon für seine Bandbreite.
Meist ist das nicht der Fall, weil der Content-Anbieter lokal per
Peering übergibt. Der Verkehr zwischen den Proxy-Knoten läuft nicht über
das öffentliche Internet. Und wenn man das Peering kappt, schneidet man
sich nur selbst ins Fleisch, weil man den Verkehr nun über einen der
Upstreams hereinbekommt (oder bei einem anderen Peering der Verkehr aus
der Balance läuft).
Juergen Ilse
Ein kostenfreies Peering mit einem Content-Anbieter wird man doch aber
nur etablieren, wenn man sich Vorteile davon verspricht (z.B. seine
eigenen Traffic-Kosten reduziert). I.d.R. werden also bei einem solchen
"kostenneutralen Peering" beide PArtner davon profitieren. Warum soll
nun der Content-Provider noch zusaetzlich dafuer zahlen, dass sein Peer
weniger (zu bezahlenden) Traffic ueber seine kostenpflichtigen Uplinks
schicken muss? Hier wird doch versucht, eine irrige Meinung wie "die
Content-Provider profitieren doch nur davon, dass wir den Zugriff auf
ihren Content bereitstellen, und bisher verlangen wir noch nicht ein-
mal eine Gegenleistung!!!" zu etablieren, dabei profitiert doch auch
der Provider, denn dadurch dass der Zugriff auf diesen COntent moeglich
wird, steigt fuer die Kunden des Providers dessen Attraktivitaet:
Ein PRvider, der z.B. keinen akzeptablen Zugriff auf google gewaehr-
leisten kann, kann sich wohl Privatkunden abschminken ... Fuer anderen
Content gilt aehnliches: manche Kundengruppen werden keinen Provider
akzeptieren, der den Zugriff auf die erwuenschten Contents nicht ge-
waehrleisten kann.
Das erinnert mich irgendwie daran, dass das DFN mal versucht hat, sich
alle Peerings von den Peering-PArtnern bezahlen zu lassen (mit dem
Argument, dass ja alle nur auf die Angebote im DFN-Netz zugreifen
wuerden, und so ja nur alle anderen vom DFN-Netz profitieren ohne
dafuer zu bezahlen). Als daraufhin mal ein Grossteil der europaeischen
Provider alle direkten Peerings mit dem DFN-Netz fuer einen Tag abge-
schaltet haben, hat sich damals der Kurs des DFN doch IIRC geaendert:
Wenn fast aller Traffic in andere Netze zwangsweise ueber die USA
geroutet wird, laesst doch die Attraktivitaet des DFN-Netzes irgendwie
nach, wie man damals festgestellt hat ...
Das ganze (dass ich damals nur am Rande mitbekommen hatte) ist aller-
dings schon etliche Jahre her, aber vielleicht muessen nun andere erst
einmal aehnliche Erfahrungen machen, bis sie wieder zurueckrudern ...
Juergen P. Meier
> Was das QoS anbelangt - welche Traffikklassen braucht man den bitte schï¿œn?
z.B.:
- Moeglichst Geringe Latenz (onlinegames)
- moeglichst konstante Latenz (Video/Voice Bidirektionale Streams)
- Latenz ist egal, moeglichst hoher Durchsatz (downloads)
- Pakete letzter Klasse
- Paketverlust vermeiden, auch bei Staus (Verschluesseltes)
u.s.w.
> Geh bitte. Sowas geht bei >2 promille um 8:00 (also tiefste Nacht)
> im Halbschlaf.
Aha. SChon klar.
> PS: obiges in in vielen Punkten etwas zugespitzt. Aber ich hoffe die
> Grundidee "weniger ist mehr" kommt rï¿œber.
Manchmal ist weniger eben doch zu wenig.
Juergen P. Meier
> On Mon, 28 Jan 2008 18:46:37 +0000 (UTC) Juergen P. Meier wrote:
>> Clemens Zauner <cz+u...@onlineloop.com>:
>>
>> z.B.:
>> - Moeglichst Geringe Latenz (onlinegames)
>> - moeglichst konstante Latenz (Video/Voice Bidirektionale Streams)
>> - Latenz ist egal, moeglichst hoher Durchsatz (downloads)
>> - Pakete letzter Klasse
>> - Paketverlust vermeiden, auch bei Staus (Verschluesseltes)
>> u.s.w.
>
Falsch. Das wollen diejenigen, die sich mit VoIP herumaergern, weil
ihen von den Netzwerkausruestern gleiche Leistung zum einem Bruchteil
der Kosten von ATM versprochen wurde, am besten noch ueber
existierende IP Infrastrukturen.
>:-) Stellt das eigene Netz an keiner Stelle einen Engpass dar, wird der
> Kunde keinen Unterschied zwischen diesen Traffic Klassen einerseits und
> allen Packeten im einem grossen Topf transportiert andererseits
> festellen. Dass die Latenz in den Interface Queues bei GigE und
man Jitter
> aufwaerts irrelavant ist, hat Clemens dargelegt. Pro Interface
Die Latenz in Interfaces ist voellig egal. Latenz passiert dort, wo
sich irgendwer Pakete anschauen muss, oder wo Router mit ueber 50%
Last laufen.
> worin besteht das Geschaeftsmodell vom "mehr"? Der mpls Traffic
> Engineering Zip und Zap erhoeht die Kosten und verkauft wird primaer
> ueber den Preis.
MPLS hat nicht viel mit QoS zu tun, ausserhalb der Marketingwunderwelt.
MPLS ist eher ein Administratives und Organisatorisches Werkzeug, aber
keines der Netztechnik (zumindest nicht wenn es um QoS geht).
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Clemens Zauner
>> Die VPNs kriegt man
>> als klein/mittel - ISP auch billiger mit VRF auf *dem* DSL-Terminierungs-
>> router (also MPLS nur auf einer Kiste, grob vereinfacht).
>
> Besagter Kumpel vom BSI wollte aber darauf hinaus, die Tendenz dahin, mpls
> fuer interne Zwecke zu verwenden.
Sales & Marketing Effektiv vom Rest des Netzes trennen? Und drauf achten,
dass nur das Zeug was die wirklich zum Arbeiten brauchen drübergeht?
Ausserdem kann Sales & marketing dann gegenüber Kunden damit Posen, dass
man ja MPLS hat. Quasi als Unique Selling Point.
Clemens Zauner
> MPLS hat nicht viel mit QoS zu tun, ausserhalb der Marketingwunderwelt.
Sagen wir ja.
> MPLS ist eher ein Administratives und Organisatorisches Werkzeug, aber
> keines der Netztechnik (zumindest nicht wenn es um QoS geht).
Genau. Allerdings gings dem OP mehr oder weniger eben genau darum. Hier
wurde schon festgestellt, dass für was das im echten Leben tatsächlich
zum Einsatz kommt (einer meiner ersten followups - "pseudo wire").
cu
Clemens.
Clemens Zauner
>> Was das QoS anbelangt - welche Traffikklassen braucht man den bitte schön?
>
> z.B.:
> - Moeglichst Geringe Latenz (onlinegames)
> - moeglichst konstante Latenz (Video/Voice Bidirektionale Streams)
> - Latenz ist egal, moeglichst hoher Durchsatz (downloads)
> - Pakete letzter Klasse
> - Paketverlust vermeiden, auch bei Staus (Verschluesseltes)
> u.s.w.
Wah. Ein echter P.Meier. Da zähl ich doch tatsächlich die 4 üblichen
Klassen auf, du snippst sie und was kömmt: TOS-Field for Dummies.
Immerhin übersetzt. Reife Leistung.
>> Geh bitte. Sowas geht bei >2 promille um 8:00 (also tiefste Nacht)
>> im Halbschlaf.
>
> Aha. SChon klar.
Ja.
>> PS: obiges in in vielen Punkten etwas zugespitzt. Aber ich hoffe die
>> Grundidee "weniger ist mehr" kommt rüber.
>
> Manchmal ist weniger eben doch zu wenig.
Klar.
Aldo Valente
>> Die VPNs kriegt man
>> als klein/mittel - ISP auch billiger mit VRF auf *dem* DSL-Terminierungs-
>> router (also MPLS nur auf einer Kiste, grob vereinfacht).
>
> klar, fuer die Bereitstellung von Kunden VPNs macht mpls durchaus Sinn.
> Besagter Kumpel vom BSI wollte aber darauf hinaus, die Tendenz dahin, mpls
> fuer interne Zwecke zu verwenden.
Ja, MPLS als VRF ist in einigen Anwendungsfällen sehr
interessant. Übrigens auch als Alternative zu Sender-basiertem Routing
(PBR).
Aldo
--
"Back in the 1980's, when all music sucked and men dressed like
sissies, a bunch of sissy Europeans got together in a passionate
effort to overstandardize computer networking. They created this thing
called the Open Systems Interconnection (OSI) networking suite."
http://www.europa.com/~dogman/osi/
Clemens Zauner
Diverse: Ja sicher. Sogar die Meisten. Es gibt verdammt wenig gute
Literatur. Und auch dort ist manches gefärbt[1]. Klar gibt es
Anwendungsgebiete (pseudowire wurde bereits mehrfach genannt).
Allerdings wieviele ISP brauchen das - oder wollen das bieten? Und
wieviele Angestellte im Backbone-Bereich haben die? Und vergiss nicht:
wieviele davon operieren dann gleich Europa- oder Weltweit und wo ist
dann das NOC?
Den weltweiten Personalbedarf dafür deckt man aus dem Pool der wirklich
fähigen Packet-Plumbers. Du hast also einen geringen Ausbildungsbedarf.
Weshalb sollte es dann ein wirklich breites, gutes Ausbildungsangebot
geben. Wovon soll das Angebot denn leben?
cu
Clemens.
______________
[1] Die durchaus guten Bücher, die der Verlag Cisco Press zu diversen
Themen bietet werden nicht unbedingt darauf hinweisen, dass es nicht
the latest and greatest an Technologie sein muss. Verständlich, oder?
Florian Weimer
Warum? Die Forschung zu IP-Routing in Weitverkehrsnetzen hat meist nicht
viel mit der Wirklichkeit gemein (so Scherze wie global synchronisierte
Router-Uhren gibt's dort). Wenn die Lehrbücher darauf abgestimmt sind,
ist das doch für Hochschulzwecke in Ordnung.
Daniel Roesen
> Diverse: Ja sicher. Sogar die Meisten. Es gibt verdammt wenig gute
> Literatur. Und auch dort ist manches gefärbt[1]. Klar gibt es
> Anwendungsgebiete (pseudowire wurde bereits mehrfach genannt).
> Allerdings wieviele ISP brauchen das - oder wollen das bieten? Und
> wieviele Angestellte im Backbone-Bereich haben die? Und vergiss nicht:
> wieviele davon operieren dann gleich Europa- oder Weltweit und wo ist
> dann das NOC?
Sorry, aber ich denke Du unterschaetzt die "Marktdurchdringung" von MPLS
wirklich bei _weitem_. Fast jeder mom-and-pop ISP mit nem Backbone
jenseits von 5 Routern macht das heutzutage, und die Anwendungsbereiche
sind mannigfaltig. L3VPNs, L2VPNs (ob nun PWE oder VPLS), traffic
engineering und 6PE. Und es wird bestimmt nicht implementiert, weil es
"hip" ist, sondern weil konkrete Aufgaben zu loesen sind.
In dem Thread hier wird extremst geblubbert.
Gruss,
Daniel
Daniel Roesen
> L3VPNs, L2VPNs (ob nun PWE oder VPLS), traffic engineering und 6PE.
Achja, und so Geschichten wie Fast Reroute link/node protection
(Stichwort sub-second convergence) und BGP-freier Core.
Lutz Donnerhacke
> Achja, und so Geschichten wie Fast Reroute link/node protection
> (Stichwort sub-second convergence) und BGP-freier Core.
Wozu braucht man einen BGP freien Core? Ist das Internet2?
Dirk Bossenz
> jenseits von 5 Routern macht das heutzutage, und die Anwendungsbereiche
> sind mannigfaltig. L3VPNs, L2VPNs (ob nun PWE oder VPLS), traffic
> engineering und 6PE. Und es wird bestimmt nicht implementiert, weil es
> "hip" ist, sondern weil konkrete Aufgaben zu loesen sind.
Gibt es da Konkreteres, gerade in Hinblick auf die Anwendung von TE?
danke
Dirk
Clemens Zauner
> Sorry, aber ich denke Du unterschaetzt die "Marktdurchdringung" von MPLS
> wirklich bei _weitem_. Fast jeder mom-and-pop ISP mit nem Backbone
Einige haben was - ohne was damit damit zu machen. Weil sich eigentlich
nur einer damit einigermassen auskennt. Ich betreue ISPs (bin also nicht
nur bei einem angestellt) und bilde mir deshalb ein durchaus zumindest
hier den Marktanteil irgendwie abschätzen zu können.
> jenseits von 5 Routern macht das heutzutage, und die Anwendungsbereiche
> sind mannigfaltig. L3VPNs, L2VPNs (ob nun PWE oder VPLS), traffic
Die VPNs und pseudowire wurden erwähnt, allerdings ist mein Eindruck dass
die meisten das "klassisch" mit VPN-Boxen machen. Ich kenne zumindest
ein grosses Unternehmen, das soeben sein MPLS-VPN (durch den ISP) auf
die Halde befördert hat - überigends nicht wegen mir (ich hätte das da sogar
für sinnvoll erachtet) & jetzt über das Netz tunnelt.
> engineering und 6PE. Und es wird bestimmt nicht implementiert, weil es
Verwechselst du da nicht Die Ursache mit dem Zweck? Man setzt ja nicht
MPLS ein, um dann 6PE machen zu können. Einen V6 Edge kriegt man ganz
normal dualstacked. V6 Edge Connectivity braucht kein MPLS; wenn man
natürlich eins hat wirds eben wieder komplizierter, weil man das Zeug
dann über sein V4-basiertes MPLS anhängt.
> "hip" ist, sondern weil konkrete Aufgaben zu loesen sind.
Was genau bleibt denn abgesehen von der Lösung von VPN/Pseudowire und
verwandten an zu lösenden Aufgaben übrig? Insbesonders in einer Stückzahl,
die ein flächendeckends Rollout rechtfertigt.
Und klar - ich kann wenn ich mehr als einen DSL-Terminator habe die
irgendwie zusammenhängen um PNs zu generieren. VRF wurde ja von von
mir auch schon genannt (ist ja auch Teil von MPLS) - aber das sind
Inselchen.
Ich bleibe dabei, dass die wenigsten ISP MPLS im Core zu Dingen wie
Bandbreitenprovisioning einsetzen. Oder um QoS-Policies zu enforcen.
> In dem Thread hier wird extremst geblubbert.
In der Tat. Insbesonders von denen, die nicht wirklich mitlesen, und dann
isolierte Aussagen rausgreifen. Um halt irgendwas zu wiederlegen. Sorry,
eh. Aber vergleich mal die Studienwirklichkeit über die Anwendung von
MPLS mit der Realität. In letzterer wird das nämlich eigentlich halt
irgendwie zum Tunneln eingesetzt.
Das ist in etwa so, als wär die V4-Welt bei statischem routing stehen
geblieben. MPLS hat damals von Featuritis nur so getönt. Wenn ich deine
Kriterien anwende - ja, dan ist fast alles was ich unter den Fingern
habe von MPLS nur so durchtränkt.
Allerdings köme ich nie auf die Idee, nur weil ein paar router mehr als
eine FIB haben von einem MPLS-Core zu sprechen. Ich sag ja zu meinem
Heim-Lan auch nicht Backbone.
cu
Clemens.
Clemens Zauner
>
> Wozu braucht man einen BGP freien Core? Ist das Internet2?
Nein, das sind dann NextGenerationNetworks. Convergence! Lutz, du solltest
dringend wieder mal auf einem Verkaufsveranstaltung eines router-Vendors
gehen.
Du hast offensichtlich keine Ahnung was du alles total dringend brauchst,
damit du auch morgen noch deine EMail lesen kannst. Überhaupt sollte dir
klar sein, dass V6 eigentlich sowieso nur über MPLS machbar ist. Alles
andere tut nur so, als würde es funktionieren.
cu
Clemens.
Lutz Donnerhacke
> Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> Wozu braucht man einen BGP freien Core? Ist das Internet2?
>
> Nein, das sind dann NextGenerationNetworks. Convergence! Lutz, du solltest
> dringend wieder mal auf einem Verkaufsveranstaltung eines router-Vendors
> gehen.
Man merkt mir also meine Ignoranz an. Schlecht.
> Du hast offensichtlich keine Ahnung was du alles total dringend brauchst,
> damit du auch morgen noch deine EMail lesen kannst. Überhaupt sollte dir
> klar sein, dass V6 eigentlich sowieso nur über MPLS machbar ist. Alles
> andere tut nur so, als würde es funktionieren.
Stimmt. Ist mir schon aufgefallen. So einfach v6 und v4 auf dem gleichen
Layer2 zu fahren ist irgendwie derartig was von altbacken ...
Marc Haber
>Der Traffic liegt nachts beim Saugesel-Grundrauschen, läuft so ab
>7 Uhr früh langsam hoch, zickt manchmal noch Mittags etwas und
>fängt dann ab ca. 14 Uhr an bis zur Spitze 18 bis 20 Uhr hochzulaufen.
>Wenn dann Fussball im Fernsehen kommt ;-) , geht es schneller,
>sonst langsamer wieder runter, um 2 bis 4 Uhr nachts ist ungefähr
>das Minimum erreicht.
>
>Eventuelle "Events" gehen in dieser Kurve _völlig_ unter, es sei
>denn, der Event heißt Weihnachten, dann ist sie etwas verformt.
>
>Selbst bei unserem kleinen Access Netz (einige tausend Kunden)
>mittelt sich der Traffic _völlig_ aus, Preferenzen in bestimmte
>Verkehrsrichtungen abhängig von aktuellen Events sind nicht
>erkennbar.
Andererseits habe ich auch schon Traffickurven eines großen deutschen
Webportals gesehen, bei dem man die beiden Halbzeiten des
Fußball-EM-Spiels mit deutscher Beteiligung _sehr_ deutlich in der
mrtg-Grafik sehen konnte.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Sebastian Abt
> Andererseits habe ich auch schon Traffickurven eines großen deutschen
> Webportals gesehen, bei dem man die beiden Halbzeiten des
> Fußball-EM-Spiels mit deutscher Beteiligung _sehr_ deutlich in der
> mrtg-Grafik sehen konnte.
Das hat man bei uns auch sehr deutlich gesehen. Wenn ich mich nicht
irre, hat man das sogar sehr deutlich in den DE-CIX Graphen gesehen.
sebastian
--
SABT-RIPE PGPKEY-D008DA9C
Stefan Schmidt
Es ging um Fussball in Graphen...
> Das hat man bei uns auch sehr deutlich gesehen. Wenn ich mich nicht
> irre, hat man das sogar sehr deutlich in den DE-CIX Graphen gesehen.
An dieser Stelle moechte ich auf mein Blog verweisen weil das mit dem
graphengucken im Web doch ein wenig besser geht:
http://blog.zaphods.net/articles/2006/06/25/i-hate-soccer
Viertelfinale WM oder so wars.
Diese beiden finde ich aber auch ganz witzig:
http://blog.zaphods.net/articles/2007/02/08/gameservers-are-odd
http://blog.zaphods.net/articles/2007/01/11/how-often-does-your-mua-pop
Zap
--
"Hier ist mein Schild."
Oliver Bartels
<zap...@mandelbrot.zaphods.net> wrote:
>An dieser Stelle moechte ich auf mein Blog verweisen weil das mit dem
>graphengucken im Web doch ein wenig besser geht:
>http://blog.zaphods.net/articles/2006/06/25/i-hate-soccer
>Viertelfinale WM oder so wars.
Wenn man aber bedenkt, dass das ein Wirklich Großer Event (tm)
war, ist der Einbruch der Kurve auch nicht so dramatisch.
Ceterum Censeo: Im Normalfall gleicht sich das alles aus und
fast der gleiche Graph grüßt genauso täglich wieder wie das
Murmeltier.
Gruß Oliver
--
Oliver Bartels + Erding, Germany + obar...@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Oliver Bartels
<hau...@nospam.de> wrote:
>Ich habe immer noch nicht verstanden, woher diese Idee der Zahlung
>irgendwelcher Beträge an den Access-Lieferanten durch den Content-
>Anbieter überhaupt kommt, bzw. wie das gerechtfertigt oder auch nur
>implementiert werden soll.
Der Ansatz ist für gewöhnlichen Content (*) natürlich
hochgradig schwachsinnig, alleine schon deshalb, weil
das beste und billigste Medium für den Massen-
Broadcast immer noch der Satellit ist.
Und bei dem kann man mit wenigen Cent pro Jahr (!) und
Zuseher an Kosten rechnen.
Und: Der Content, welcher viel Bandbreite braucht, da
Real-Time Anforderung (auf einen Download kann man
warten ... ) ist entsprechend aufwendig zu produzieren,
ergo wird er nicht für einzelne Personen gemacht, sondern
_für_die_Masse_.
Und damit wird er früher oder später, aber dennoch sicher,
den Weg über einen Sat-Transponder finden.
Das ist der Massstab. Punkt.
Nein, Downloads zählen nicht wirklich, denn Bandbreite
kostet Geld im Netz, nicht Volumen. Für letzteres ist zu
Nicht-Spitzenzeiten immer noch genügend Platz, siehe
die MRTG Graphen.
>Also wofür soll der Content-Anbieter jetzt nochmal bezahlen?
Es gibt in der Branche einige Schlipse, die geglaubt haben,
dass statt der betriebswirtschaftlichen Kennzahl "Gewinn"
nunmehr Kennzahlen wie "Anzahl_der_Kunden" wesentlich
seien.
Die hat nun die Realität eingeholt, dass am Ende vom Tag
eben doch "Gewinn" zählt, was nützen mir Billisch-Kunden,
mit denen ich kein Geld mache und die noch nicht mal
als Adressaten von Werbung taugen.
"Geizgeilgeier 19-79" ist nicht wirklich der Hit als Zielgruppe,
die haben schon bewiesen, dass sie nix ausgeben möchten ;-/
Und nun versucht man halt, sich die Einnahmen anderweitig
zu holen, nur funktioniert das aus den hier diskutierten
Gründen (Kunden wandern dann ab, Content findet andere
Wege der Verbreitung) nicht wirklich.
Gruß Oliver
P.s.: (*) Denkbar wäre, dem Kunden _Zusatznutzen_
in einem Netz anzubieten, also z.B. das Fussballspiel
als Panorama mit 8000 Pixeln in ein Netz zu stellen und
lokal an den AC-Routern die Extraktion eines
kundenindividuellen (ggf. sogar 3D) Bildausschnitts zu
tätigen.
Allerdings könnte der _konkrete_ Vorschlag auch
einen Markt-Haken haben (neben dem, dass man es
entwickeln müßte usw.):
Der Zuschauer ist sehr ungerne Regisseur.
Und: Erwerben darf man _den_ Content trotzdem,
zahlen tut keiner von den Kickern für die Übertragung ;-)
Stefan Schmidt
>>http://blog.zaphods.net/articles/2006/06/25/i-hate-soccer
>>Viertelfinale WM oder so wars.
>
> Wenn man aber bedenkt, dass das ein Wirklich Großer Event (tm)
> war, ist der Einbruch der Kurve auch nicht so dramatisch.
Wikipedia [1] legt dann doch eher das Achtelfinale nahe, da hatte das
WM-Fieber mutmasslich noch nicht all unsere Kunden infiziert.
> Ceterum Censeo: Im Normalfall gleicht sich das alles aus und
> fast der gleiche Graph grüßt genauso täglich wieder wie das
> Murmeltier.
Tut er und das ist auch gut so, gestern habe ich dadurch einen Fibrecut
wahrgenommen (siehe blog ;-) und einen mardierenden DNS Tunnel
ueberfuehrt. Einfach unheimlich praktisch diese zappelnden Linien, man
sollte dem Herrn Oetiker einen Orden dafuer verleihen.
Zap
[1]http://de.wikipedia.org/wiki/Fu%C3%9Fball-Weltmeisterschaft_2006#Achtelfinale
Dirk Bossenz
> Ceterum Censeo: Im Normalfall gleicht sich das alles aus und
> fast der gleiche Graph grüßt genauso täglich wieder wie das
> Murmeltier.
ja...das deckt sich ja auch mit den Erkenntnissen des Selbst-Ähnlichen
Verkehrs. Der im langen Zeitraum fast eine Linie ist, im kurzen
Betrachtungszeitraum Bursts mit fast doppelter Amplitude aufweist.
Ich bin vielleicht auch etwas naiv an die Fragestellung heran gegangen,
zum einen bin ich mit von dem Einfluß von Voice ausgegangen, zum anderen
stellte ich mir auch großere Netzwerkdimensionen vor, die mindestens auf
überregionaler Ebene auch aktiv sind.
Nur wird hier keiner mit Arcor, T-Com, Vodafon, QSC, etc. Backround hier
an der Newsgroup teilhaben. Insofern uferte dies dann auch aus. (G)MPLS
und ASON haben Bedeutung, nur eben in gänzlich anderen Maßstäben. Siehe
hierzu auch ITG-VDE Tagungen wo z.B. Arcor ihr Netz vorstellten.
Dirk
Oliver Bartels
wrote:
>Ich bin vielleicht auch etwas naiv an die Fragestellung heran gegangen,
Ja ;-)
>zum einen bin ich mit von dem Einfluß von Voice ausgegangen, zum anderen
>stellte ich mir auch großere Netzwerkdimensionen vor, die mindestens auf
>überregionaler Ebene auch aktiv sind.
>
>Nur wird hier keiner mit Arcor, T-Com, Vodafon, QSC, etc. Backround hier
>an der Newsgroup teilhaben.
Täusch Dich da mal nicht.
Und auch für unser Netz kann ich schon eine vierstellige Zahl an
Privatkunden sowie eines (wenn nicht das) größte Online
Versicherungsportal in .de und einen Fernsehsender bieten.
> Insofern uferte dies dann auch aus. (G)MPLS
>und ASON haben Bedeutung, nur eben in gänzlich anderen Maßstäben.
Da muss ich Dich leider enttäuschen:
- MPLS im Core wird in der Tat primär für VPN/LAN-over-x/Privatnetze
eingesetzt.
- Der ursprüngliche Ansatz: An der Edge wird einmal eine Routing-
Entscheidung z.B. anhand der BGP Full Table getroffen, danach
führt der Label auf ATM PVCs oder zumindest auf kleine Tabellen
ist heute nicht mehr praxisrelevant. Die Router können mit der
Full Table umgehen.
Es hat m.W. nach Ansätze bei DTAG mit MPLS im Core gegeben,
inzwischen sehen die Traceroutes aber so aus, dass die Mode
wieder vorbei ist.
> Siehe
>hierzu auch ITG-VDE Tagungen wo z.B. Arcor ihr Netz vorstellten.
Papier ist geduldig.
Und Bandbreite auf Rennstrecken ist billig.
Gert Doering
>Und bisher weiß ich nicht wo hier eine geistige Herrausforderung ist,
>mit IOS nach Try&Error irgendwie spielen, ohne das ganze Netz dabei
>kaputt zumachen
Das *ist* die Herausforderung :-)
gert,
senior consultant for IOS version number understanding
--
ge...@greenie.muc.de - no phone, no fax, no noise -
18 24 61 B 17 17 4
Gert Doering
>Oder anders gefragt: Was ist das Problem, auf dass
>mpls eine Loesung darstellt?
Pseudowires ("Ethernet over MPLS irgendwo hinbridgen") sind manchmal
*sehr* nuetzlich.
Besser ist natuerlich, gar nicht erst bridgen zu muessen, aber gerade bei
Migrationen "diese Umgebung zieht jetzt Stueck-fuer-Stueck an den neuen
Standort, und die IP-Adressen koennen/duerfen/sollen sich dabei nicht
aendern" ist es nuetzlich.
L3 VPNs wurden auch schon genannt. Verkauft Dein Arbeitgeber auch,
zumindest behauptet das Euer Vertrieb ;-) (und nein, wir wollten das
nie kaufen, weil "Kontrollverlust").
gert
Gert Doering
sub-second convergence macht Dir $IGP_der_Wahl heute auch - das Problem
ist heute weniger das Routingprotokoll als die link-down-Erkennung.
BGP-freier Core ist eine nette Idee - allein, irgendwie sehe ich nicht
ganz, wie man das bezahlen kann "ueberall noch reine P-Router dazuzubauen".
Versteh' mich nicht falsch - wir haben auch MPLS irgendwo an einer Ecke,
weil PWE und L3VPNs bestimmte Kundenprobleme eleganter loesen als die
Alternativen, aber die allheilmachende Wundersau sehe ich darin trotzdem
nicht.
Daniel Roesen
>>Nur wird hier keiner mit Arcor, T-Com, Vodafon, QSC, etc. Backround hier
>>an der Newsgroup teilhaben.
>
> Täusch Dich da mal nicht.
Er taeuscht sich. Nur haben die wenigsten Lust in so eine Diskussion
einzusteigen. Ich verfluche mich auch schon wieder dafuer. :)
> Es hat m.W. nach Ansätze bei DTAG mit MPLS im Core gegeben,
> inzwischen sehen die Traceroutes aber so aus, dass die Mode
> wieder vorbei ist.
LOL. DTAG Core _ist_ ein MPLS Core.
http://www.cariden.com/technologies/papers/nanog-t-com-horneffer.pdf
http://www.imconf.net/imc-2007/papers/imc64.pdf
Das Du davon nichts im traceroute siehst ist sicherlich gewollt.
http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-mpls-apps/id-84818.html
Gruss,
Daniel
Gert Doering
>> Pseudowires ("Ethernet over MPLS irgendwo hinbridgen") sind manchmal
>> *sehr* nuetzlich.
>kann man machen, muss man aber nicht. Oft geht es nur darum, zur
>technischen Umsetzung irgendwelcher Fehlplanungen per mpls statische
>Tunnel durch sein Netz zu bohren. In letzter Zeit wird meiner
>Wahrnehmung nach mpls durch mittels cwdm oder dwdm realisierte DC-Wege
>abgeloest. Warum mit mpls Tunneln rumkruecken, wenn ich mir eine STM-16
>Multirate Lambda schalten kann, auf der STM-1, 4, 16 und GigE tut?
Weil ein MPLS PW automatisch re-routed wird, wenn Dir auf dem Weg
eine Leitung ausfaellt. Du muesstest also das PW mit einem fully
protected STM-x vergleichen - und *das* ist ueblicherweise relativ
teuer, ausser man hat ein reichlich unausgelastetes DWDM-/SDH-System
rumstehen.
>> L3 VPNs wurden auch schon genannt. Verkauft Dein Arbeitgeber auch,
>> zumindest behauptet das Euer Vertrieb ;-)
>hmm, seit zwei Jahren eigentlich nicht mehr. Sicher dass du Sales nicht
>mit der o2 Business Systems verwexelst?
Nachdem wir ihnen ein paarmal gesagt haben, wo sie sich das hinstecken
koennen, haben sie aufgehoert.
... dass es inzwischen nicht mehr verkauft wird, haben sie uns nicht
gesagt, denn das hiesse ja zuzugeben, dass wir Recht hatten... :-)
Lutz Donnerhacke
> Pseudowires ("Ethernet over MPLS irgendwo hinbridgen") sind manchmal
> *sehr* nuetzlich.
Nimmt man dafür nicht einfach DLSW+ oder bin ich schon wieder ein Jahrzehnt
raus?
Gert Doering
>> >kann man machen, muss man aber nicht. Oft geht es nur darum, zur
>> >technischen Umsetzung irgendwelcher Fehlplanungen per mpls statische
>> >Tunnel durch sein Netz zu bohren. In letzter Zeit wird meiner
>> >Wahrnehmung nach mpls durch mittels cwdm oder dwdm realisierte DC-Wege
>> >abgeloest. Warum mit mpls Tunneln rumkruecken, wenn ich mir eine STM-16
>> >Multirate Lambda schalten kann, auf der STM-1, 4, 16 und GigE tut?
>>
>> Weil ein MPLS PW automatisch re-routed wird, wenn Dir auf dem Weg=20
>> eine Leitung ausfaellt. Du muesstest also das PW mit einem fully
>> protected STM-x vergleichen - und *das* ist ueblicherweise relativ
>> teuer,
>warum nicht das automagische Rerouten im Stoerungsfall ganz geschmeidig
>seinem IGP ueberlassen?
Eh? Wir reden hier ueber Layer 2 point-to-point (pseudo) links. Da
gibt's normalerweise kein IGP, was Dir eine Alternative routed - und das
ist der Charme daran, sowas ueber MPLS zu machen: es ist auf einmal ein
geroutetes Netz drunter, was genau das tut.
Gert Doering
Ich weiss nicht *genau*, was DLSW+ tut - haette das jetzt aber spontan fuer
"komisches source-routed bridging fuer SNA" gehalten. Also Token Ring auf
Dope.
EoMPSL ist "Ethernet". Mit allen Vor- und Nachteilen.
(Oder im verallgemeinerten Fall auch ein virtueller PPP- oder ATM- oder
FR-Link. Irgendeine L2-Technologie halt, die man mangels echter Draehte
virtuell verkabeln moechte/muss)
Christoph
Clemens Zauner wrote:
> Daniel Roesen <d...@bofh.de> wrote:
>> Sorry, aber ich denke Du unterschaetzt die "Marktdurchdringung" von MPLS
>> wirklich bei _weitem_. Fast jeder mom-and-pop ISP mit nem Backbone
>
> Einige haben was - ohne was damit damit zu machen. Weil sich eigentlich
> nur einer damit einigermassen auskennt. Ich [...] bilde mir [...]
> ein durchaus zumindest hier den Marktanteil irgendwie abschätzen zu können.
Sehr mutig. Ich weiss aus denm Stegreif schon 2, die MPLS richtig intensiv
und auch komplex einsetzen - und ich wette - trotz Deiner Marktkenntnisse
- das da allein in D* nochmal mindestens 2-3 so'n Zeug in ähnlicher Intensität
nutzen.
> Die VPNs und pseudowire wurden erwähnt, allerdings ist mein Eindruck dass
> die meisten das "klassisch" mit VPN-Boxen machen. Ich kenne zumindest
> ein grosses Unternehmen, das soeben sein MPLS-VPN (durch den ISP) auf
> die Halde befördert hat - überigends nicht wegen mir (ich hätte das da sogar
> für sinnvoll erachtet) & jetzt über das Netz tunnelt.
Das ist eine Frage von Preisen und Diensten. Da haben sich dann die
Selbermacher in der Computerabteilung duirchgesetzt, vermutlich weil sie
die internen Kosten von Zusatzdensten verschwiegen haben. Klar kann
man - bei mäßigen Bandbreiten und eher begrenzten Standortzahlen -
IPSEC-VPNs recht preiswert bauen. Aber wenn dann alles andere dazukommt
ist der gute vollsortierte ISP doch wieder preiswerter.
Gruß
Christoph Weber-Fahr
Jens Link
> senior consultant for IOS version number understanding
Oh ja, da kann man viel Spass mit haben. @Home ist mir neulich ein Bug
ueber den weg gelaufen, bei dem der Debug-Output immer angezeigt hat,
dass alles in Ordnung sei, auch wenn dem nicht so war.
Jens
--
sage@guug Berlin: http://www.guug.de/lokal/berlin/index.html
FFG'08 Muenchen: http://guug.de/ffg
Lutz Donnerhacke
> Lutz Donnerhacke <lu...@iks-jena.de> writes:
>>Nimmt man dafür nicht einfach DLSW+ oder bin ich schon wieder ein Jahrzehnt
>>raus?
>
> Ich weiss nicht *genau*, was DLSW+ tut - haette das jetzt aber spontan fuer
> "komisches source-routed bridging fuer SNA" gehalten. Also Token Ring auf
> Dope.
Exakt. Und im Transparenten Modus mit einem Ethernetmedium macht es
klassisches Bridging.
> EoMPSL ist "Ethernet". Mit allen Vor- und Nachteilen.
DLSW+ benötigt nur den OS-Support am Bridgepunkt. MPLS auf der ganzen Strecke.
Christian Appenzeller
[Oliver Bartels schrieb:]
>- Der urspruengliche Ansatz: An der Edge wird einmal eine Routing-
>Entscheidung z.B. anhand der BGP Full Table getroffen, danach
>fuehrt der Label auf ATM PVCs oder zumindest auf kleine Tabellen
>ist heute nicht mehr praxisrelevant. Die Router koennen mit der
>Full Table umgehen.
Hast Du Dich nicht auch schon in der Vergangenheit darueber beklagt,
dass manche Routerhersteller zu geizig beim Speicher sind?
Koennte die MPLS-Frage nicht vielleicht gerade bei IPv6 (Stichwort:
noch groessere Routingtabellen) daher wieder relevant werden?
>Es hat m.W. nach Ansaetze bei DTAG mit MPLS im Core gegeben,
>inzwischen sehen die Traceroutes aber so aus, dass die Mode
>wieder vorbei ist.
Hm? Wuerde ich nicht so sehen. Schau mal:
> C:\>tracert www.spiegel.de
>
>Routenverfolgung zu www.spiegel.de [195.71.11.67] ueber
>maximal 30 Abschnitte:
>
> 1 <1 ms <1 ms <1 ms 192.168.2.1
> 2 * * * Zeitueberschreitung der Anforderung.
> 3 6 ms 6 ms 6 ms 87.186.243.130
> 4 12 ms 13 ms 12 ms f-ea5.F.DE.net.DTAG.DE [62.154.16.165]
> 5 12 ms 12 ms 12 ms 62.156.138.90
> 6 15 ms 14 ms 14 ms TDeutschland-6-1-0-0-grtfraix1-red.telefonica.wholesale.net.9.16.84.in-addr.arpa [84.16.9.102]
> 7 12 ms 14 ms 14 ms rmwc-frnk-de01-so-1-0-0-0.nw.mediaways.net [195.71.254.105]
> 8 18 ms 18 ms 18 ms rmwc-gtso-de01-pos-7-0.nw.mediaways.net [195.71.254.78]
> 9 20 ms 20 ms 19 ms xmws-gtso-de01-vlan-2.nw.mediaways.net [195.71.12.59]
> 10 20 ms 19 ms 17 ms 195.71.11.67
>
>Ablaufverfolgung beendet.
Mein Einwahlknoten (Rottweil) duerfte aber wohl kaum direkt an FFM
haengen... ;-)
Interessanterweise sieht ein Traceroute auch anders aus, wenn man den
vierten Hop traced:
C:\>tracert 62.154.16.165
>Routenverfolgung zu f-ea5.F.DE.net.DTAG.DE [62.154.16.165] ueber maximal 30 Abschnitte:
>
> 1 <1 ms <1 ms <1 ms 192.168.2.1
> 2 * * * Zeitueberschreitung der Anforderung.
> 3 6 ms 6 ms 6 ms 87.186.243.130
> 4 24 ms 23 ms 23 ms s-sa2.S.DE.net.DTAG.DE [62.154.4.202]
> 5 21 ms 21 ms 20 ms f-sa1.F.DE.net.DTAG.DE [62.154.0.29]
> 6 14 ms 12 ms 14 ms f-ea5.F.DE.net.DTAG.DE [62.154.16.165]
>
>Ablaufverfolgung beendet.
Hier tauchen auf dem Weg noch ein Hop in Stuttgart und ein weiterer
in FFM auf.
Warum sind aber diese Hops eigentlich im einen Fall sichtbar und im
anderen nicht?
>Und Bandbreite auf Rennstrecken ist billig.
Demnach braucht man MPLS fuer QoS also nicht (mehr?)?
Macht man es sich aber nicht vielleicht doch etwas zu einfach,
nur auf "Bandbreite im Ueberfluss" zu setzen, anstatt noch
zusaetzliche Sicherungsmassnahmen einzusetzen?
Es kann ja vielleicht auch mal durch Stoerungen (z.B. Ausfall
von einzelnen Strecken) zu Ueberlastungen etc. kommen, wo
ein funktionierendes QoS dann die Auswirkungen zumindest
etwas daempfen kann?
CU Christian
Gerald Krause
>> C:\>tracert www.spiegel.de
>>
>>Routenverfolgung zu www.spiegel.de [195.71.11.67] ueber
>>maximal 30 Abschnitte:
>>
>> 1 <1 ms <1 ms <1 ms 192.168.2.1
>> 2 * * * Zeitueberschreitung der Anforderung.
>> 3 6 ms 6 ms 6 ms 87.186.243.130
>> 4 12 ms 13 ms 12 ms f-ea5.F.DE.net.DTAG.DE [62.154.16.165]
>> 5 12 ms 12 ms 12 ms 62.156.138.90
>> 6 15 ms 14 ms 14 ms
>>
TDeutschland-6-1-0-0-grtfraix1-red.telefonica.wholesale.net.9.16.84.in-addr.arpa
>> [84.16.9.102]
>> 7 12 ms 14 ms 14 ms rmwc-frnk-de01-so-1-0-0-0.nw.mediaways.net
>> [195.71.254.105]
>> 8 18 ms 18 ms 18 ms rmwc-gtso-de01-pos-7-0.nw.mediaways.net
>> [195.71.254.78]
>> 9 20 ms 20 ms 19 ms xmws-gtso-de01-vlan-2.nw.mediaways.net
>> [195.71.12.59]
>> 10 20 ms 19 ms 17 ms 195.71.11.67
>>
>>Ablaufverfolgung beendet.
>
> Mein Einwahlknoten (Rottweil) duerfte aber wohl kaum direkt an FFM
> haengen... ;-)
Das liegt möglicherweise auch eher am L2TP als dass da MPLS im Spiel sein
muss.
> Interessanterweise sieht ein Traceroute auch anders aus, wenn man den
> vierten Hop traced:
>
> C:\>tracert 62.154.16.165
>
>>Routenverfolgung zu f-ea5.F.DE.net.DTAG.DE [62.154.16.165] ueber maximal
>>30 Abschnitte:
>>
>> 1 <1 ms <1 ms <1 ms 192.168.2.1
>> 2 * * * Zeitueberschreitung der Anforderung.
>> 3 6 ms 6 ms 6 ms 87.186.243.130
>> 4 24 ms 23 ms 23 ms s-sa2.S.DE.net.DTAG.DE [62.154.4.202]
>> 5 21 ms 21 ms 20 ms f-sa1.F.DE.net.DTAG.DE [62.154.0.29]
>> 6 14 ms 12 ms 14 ms f-ea5.F.DE.net.DTAG.DE [62.154.16.165]
>>
>>Ablaufverfolgung beendet.
>
> Hier tauchen auf dem Weg noch ein Hop in Stuttgart und ein weiterer
> in FFM auf.
>
> Warum sind aber diese Hops eigentlich im einen Fall sichtbar und im
> anderen nicht?
Das kann ebenso am IGP liegen und sieht auch nicht zwangsweise nach MPLS
aus. Eindeutig wäre zB sowas in der Art:
traceroute to www.interoute.com (62.50.8.210), 64 hops max, 40 byte packets
...
3 Gi4-2.ham-001-access-1.interoute.net (84.233.185.1) 1 ms 0 ms 0 ms
4 PO7-0.dus-001-access-1.interoute.net (84.233.146.9) [MPLS: Label 746 Exp
0] 18 ms 18 ms 18 ms
5 PO8-0.fra-006-core-2.interoute.net (84.233.146.14) [MPLS: Label 268 Exp
0] 18 ms 18 ms 18 ms
6 PO1-0.ams-koo-core-1.interoute.net (84.233.190.21) [MPLS: Label 38 Exp
0] 19 ms 18 ms 18 ms
7 Gi6-0-0.ams-koo-access-1.interoute.net (212.23.41.134) 19 ms 18 ms 18
ms
8 84.233.188.130 (84.233.188.130) 18 ms 18 ms 18 ms
...
Ciao,
--
Gerald (ax/tc)
Christian Appenzeller
[Gerald Krause schrieb:]
>> Mein Einwahlknoten (Rottweil) duerfte aber wohl kaum direkt an FFM
>> haengen... ;-)
>
>Das liegt moeglicherweise auch eher am L2TP als dass da MPLS im Spiel
>sein muss.
Ich glaube nicht, dass hier irgendwo L2TP im Spiel ist, denn es handelt
sich um einen T-DSL-Zugang mit Original Telekom-Backbone (also kein
Fremdprovider via ZISP oder ISP-Gate).
87.186.243.130 steht noch in Rottweil, der im ersten Traceroute
darauffolgende Hop aber schon in Frankfurt.
CU Christian
Oliver Boehmer
> Daniel Roesen schrieb:
>
> > jenseits von 5 Routern macht das heutzutage, und die Anwendungsbereiche
> > sind mannigfaltig. L3VPNs, L2VPNs (ob nun PWE oder VPLS), traffic
> > engineering und 6PE. Und es wird bestimmt nicht implementiert, weil es
> > "hip" ist, sondern weil konkrete Aufgaben zu loesen sind.
>
> Gibt es da Konkreteres, gerade in Hinblick auf die Anwendung von TE?
Klar. Gerade in Netzen von Mobile Carrier findet TE/FRR Anwendung im
deterministisch < 200msec-Konvergenz hinzubekommen. In diesen Netzen
wird auch L2VPN und L3VPN recht extensiv verwendet.
In den meisten anderen Netzen reicht IGP Fast-Convergence in der Regel
aus, um die SLAs einzuhalten, dort ist TE/FRR overkill (wenn man die
"ich will 50msec wie SONET/SDH"-Fraktion ueberzeugt oder ignoriert
hat)..
oli
Oliver Boehmer
cz+u...@onlineloop.com says...
> Ich bleibe dabei, dass die wenigsten ISP MPLS im Core zu Dingen wie
> Bandbreitenprovisioning einsetzen. Oder um QoS-Policies zu enforcen.
Ack. Dazu taugt MPLS/TE hoechstens auf dem Papier, TE ersetzt kein
DiffServ QoS.
oli
Bernd Eckenfels
>>Das liegt moeglicherweise auch eher am L2TP als dass da MPLS im Spiel
>>sein muss.
>
> Ich glaube nicht, dass hier irgendwo L2TP im Spiel ist, denn es handelt
> sich um einen T-DSL-Zugang mit Original Telekom-Backbone (also kein
> Fremdprovider via ZISP oder ISP-Gate).
T-DSL macht MPLS im Backbone (spätestens seit VDSL/T-Home)
Gruss
Bernd
Aldo Valente
> damit hast du natuerlich Recht. Fuer den "Eigenbedarf" faellt mir aber
> spontan kein rechter Einsatzfall dieser Layer 2 point-to-point (pseudo)
> Links ein. Nur um grosse Bandbreiten im IP Core von A nach B zu
> schalten, brauche ich mpls so dringend wie ein Geschwuer am Hintern.
Die Failoverlösungen die ich so kenne, verfolgen den Ansatz daß die
eine Kiste die IP Adresse der ausfallenden übernimmt. Was machst Du
jetzt, wenn Du die beiden Kisten recht weit auseinanderstellen willst
und Routingprotokolle nicht gesprochen werden?
Es gibt irgendwelche Lösungen auf der Cisco-Website, aber schöne habe
ich nicht gefunden.
Aldo
--
More faults: Billy Dee Williams confuses grinning with acting. The Yoda
scenes tend to drag the tenth time you've seen them. ("Stall we must.
Second act this is. Talk odd would you if puppet with hand up rear were
you.") --James Lileks
Christian Appenzeller
[Olaf Selke schrieb:]
>Nochmal zu mpls und der Telekom: Setzt die Telekom mpls auch in den
>neuen Access Netzen fuer vdsl ein? Ich koennte mir vorstellen, dass die
>DSLAMs keine mpls Boards stecken haben. Kostet ja alles und Ethernet
>Frames lassen sich vom DSLAM auch ganz ohne mpls bis zum BRAS
>transportieren.
Das ist eine interessante Frage.
Bei onlinekosten habe ich ein Traceroute eines VDSL-Nutzers zum
IPTV-Server von T-Online gefunden - siehe
http://www.onlinekosten.de/forum/showthread.php?t=103321&page=3
>Traceroute to 217.6.164.54 (217.6.164.54), 64 hops max, 40 byte packets
>1 speedport.ip (192.168.2.1) 1.012 ms 0.673 ms 0.491 ms
>2 217.0.119.249 (217.0.119.249) 19.772 ms 19.663 ms 19.766 ms
>3 217.0.92.166 (217.0.92.166) 20.206 ms 19.952 ms 20.178 ms
>4 0113751-1-1-gw.f.de.net.dtag.de (194.25.10.73) 29.694 ms 29.645 ms 29.427 ms
>5 217.89.74.2 (217.89.74.2) 30.022 ms 29.816 ms 30.265 ms
>6 vodf01004.iptv.t-online.de (217.6.164.54) 29.528 ms 29.700 ms 29.599 ms
Von meinem T-DSL-Anschluss am ATM-Konzentratornetz sieht das hingegen
so aus:
>C:\>tracert 217.6.164.54
>
>Routenverfolgung zu VODF01004.iptv.t-online.de [217.6.164.54] ueber maximal 30
>Abschnitte:
>
> 1 <1 ms <1 ms <1 ms 192.168.2.1
> 2 * * * Zeitueberschreitung der Anforderung.
> 3 7 ms 7 ms 6 ms 87.186.243.130
> 4 13 ms 13 ms 12 ms 0113751-1-1-gw.F.DE.net.DTAG.DE [194.25.10.73]
> 5 13 ms 12 ms 13 ms 217.89.74.2
> 6 13 ms 13 ms 13 ms VODF01004.iptv.t-online.de [217.6.164.54]
>
>Ablaufverfolgung beendet.
Bei beiden Traceroutes ist Hop 1 jeweils ein lokaler Router und Hop 4
bis 6 sind in beiden Faellen identisch.
Hop 2 muesste der lokale BBRAR sein (der in meinem Falle nicht
antwortet) und Hop 3 der Start ins MPLS-Core-Netz?
Was mir bei VDSL nicht ganz klar ist: Wenn dort IP-DSLAMs eingesetzt
werden, sind diese dann nicht quasi auch gleich der BBRAR? Die
Verbindung wird doch gleich im IP-DSLAM terminiert? Wozu dann
noch einen zusaetzlichen zentralen BBRAR? (Fuer den normalen
Data-Traffic, sodass nur die IP-TV-Session lokal terminiert wird?)
Ist der zweite Hop beim VDSL-Nutzer also evtl. der IP-DSLAM
in der Vst?
CU Christian
Christian Appenzeller
[Olaf Selke schrieb:]
Und wenn wir schon beim Thema MPLS sind: Kommt das im
Telefonica-Backbone nicht auch zum Einsatz? Siehe
http://www.onlinekosten.de/forum/showthread.php?p=1441969
CU Christian
Marc Langer
> Was mir bei VDSL nicht ganz klar ist: Wenn dort IP-DSLAMs eingesetzt
> werden, sind diese dann nicht quasi auch gleich der BBRAR? Die
> Verbindung wird doch gleich im IP-DSLAM terminiert?
Nein, IP-DSLAM heißt nur, dass er kein ATM mehr macht. Letztlich
ist das eine Art Ethernet-Switch. Nur für die eigentliche Kundenleitung
braucht er natürlich noch ATM, klar.
Jedenfalls gilt das für unsere Siemens IP-DSLAMs hiX5635.
Marc
Gert Doering
>Olaf Selke <olaf....@blutmagie.de> writes:
>> damit hast du natuerlich Recht. Fuer den "Eigenbedarf" faellt mir aber
>> spontan kein rechter Einsatzfall dieser Layer 2 point-to-point (pseudo)
>> Links ein. Nur um grosse Bandbreiten im IP Core von A nach B zu
>> schalten, brauche ich mpls so dringend wie ein Geschwuer am Hintern.
>Die Failoverlösungen die ich so kenne, verfolgen den Ansatz daß die
>eine Kiste die IP Adresse der ausfallenden übernimmt. Was machst Du
>jetzt, wenn Du die beiden Kisten recht weit auseinanderstellen willst
>und Routingprotokolle nicht gesprochen werden?
Routingprotokolle sprechen.
*Das* ueber Bridging zu loesen ist wie "als Heilung fuer die Pest den
Leuten noch Cholera zu verpassen".
Daniel Roesen
> Ist der zweite Hop beim VDSL-Nutzer also evtl. der IP-DSLAM
> in der Vst?
Nein, die machen hinten raus nur Ethernet. 1 Port = 1 VLAN. Aggregation-
Netz Ethernet bis zum BBRAR, der terminiert dann das PPPoE. Und das ist
dann auch der 1. IP Hop.
Hat irgendwer mal jemanden hierzulande gesehen, der DSLAMs in echter
IP-DSLAM Rolle nutzt? Ich sehe bislang nur s/ATM/Ethernet/g unter dem
Label "IP-DSLAM".
Gruss,
Daniel
Christian Appenzeller
[Marc Langer schrieb:]
>Nein, IP-DSLAM heisst nur, dass er kein ATM mehr macht. Letztlich
>ist das eine Art Ethernet-Switch. Nur fuer die eigentliche Kundenleitung
>braucht er natuerlich noch ATM, klar.
Der BB-RAR spricht also die Kundenmodems auf Ethernet-Basis mit ihren
MAC-Adressen an?
Und Multicast (z.B. fuer IP-TV) ist kein IP-Multicast, sondern Ethernet-
Multicast?
Wenn aber im Grunde nur der Layer 2 ein anderer ist (Ethernet statt
ATM), dann ist das ja eigentlich (wie schon gesagt wurde) eher ein
"Ethernet-DSLAM" als ein "IP-DSLAM".
CU Christian
Christian Appenzeller
[Daniel Roesen schrieb:]
>> Ist der zweite Hop beim VDSL-Nutzer also evtl. der IP-DSLAM
>> in der Vst?
>
>Nein, die machen hinten raus nur Ethernet. 1 Port = 1 VLAN.
Jeder Kunde bekommt ein eigenes VLAN? Damit sich die Nutzer nicht
gegenseitig auf Ethernet-Basis ansprechen koennen?
Oder spielen da andere Faktoren auch noch mit rein (ausser dass
man damit auch unterschiedliche Anwendungen (Data, Voice,
IPTV) und vielleicht auch unterschiedliche Nutzer (Privat vs.
Business) unterschiedlich priorisieren kann?
>Hat irgendwer mal jemanden hierzulande gesehen, der DSLAMs in echter
>IP-DSLAM Rolle nutzt? Ich sehe bislang nur s/ATM/Ethernet/g unter dem
>Label "IP-DSLAM".
Mir scheint, bei dem Thema "IP-DSLAM" ist auch ein kleines bisschen
Show dabei...? ;-)
CU Christian
Marc Langer
> Der BB-RAR spricht also die Kundenmodems auf Ethernet-Basis mit ihren
> MAC-Adressen an?
Ja genau, das wird schon seit Jahren so gemacht, auch mit den
Vorläufer-DSLAMs, die sich tatsächlich "Ethernet-DSLAMs" nannten
bzw. von uns so genannt werden *g* Der Unterschied zu den "IP-DSLAMs"
ist, dass bei denen die Verarbeitung noch grundsätzlich auf
ATM-Basis erfolgt und nur die Schnittstelle nach außen zum
Aggregationsnetz Ethernet ist. Bei den "IP-DSLAMs" wurde in der
internen Logik dann nochmehr auf Ethernet umgestellt.
> Und Multicast (z.B. fuer IP-TV) ist kein IP-Multicast, sondern Ethernet-
> Multicast?
Doch, das wird schon IP-Multicast sein (ohne das jetzt selbst
einzusetzen). Entweder über die PPPoE-Verbindung oder auf einem
getrennten PVC/VLAN, wo per DHCP eine private IP-Adresse dafür
vergeben wird.
> Wenn aber im Grunde nur der Layer 2 ein anderer ist (Ethernet statt
> ATM), dann ist das ja eigentlich (wie schon gesagt wurde) eher ein
> "Ethernet-DSLAM" als ein "IP-DSLAM".
Ja ;-)
Es ist nunmal PPPoEthernet, nicht PPPoIP (was sich dann glaube ich
PPTP nennt oder so).
Marc
Christian Appenzeller
[Olaf Selke schrieb:]
>und das ganze moeglicherweise noch mit ein wenig vlan Zauber in den
>Backhaul hinein verziert. Die Netzwerk Ausruester preisen fuer ihre "IP-
>DSLAMs", bei denen es sich wie oben bereits erwaehnt in Wirklichkeit um
>Ethernet DSLAMs handelt, als Addon tatsaechlich Boards mit BRAS
>Funktionalitaet an.
Das zeigt immerhin, dass ich mit meiner Idee gar nicht sooo falsch
lag... ;-)
Zu diesem Thema steht uebrigens auch etwas im folgenden PDF:
http://cp.literature.agilent.com/litweb/pdf/5989-4766EN.pdf
| Nevertheless it is important to note that the industry trend
| is definitely towards more advanced Layer-3 IP functionality
| on the DSLAMs and possibly towards the DSLAM/B-RAS
| convergence in the future high-capacity DSL network
| implementations.
Mal schauen, wo da die Entwicklung noch hinfuehren wird...
CU Christian
Christian Appenzeller
[Marc Langer schrieb:]
>> Und Multicast (z.B. fuer IP-TV) ist kein IP-Multicast, sondern Ethernet-
>> Multicast?
>
>Doch, das wird schon IP-Multicast sein (ohne das jetzt selbst
>einzusetzen). Entweder ueber die PPPoE-Verbindung oder auf einem
>getrennten PVC/VLAN, wo per DHCP eine private IP-Adresse dafuer
>vergeben wird.
Meines Wissens wird doch mit Multicast angestrebt, das Backbone
und eben auch das Zufuehrungs-/Konzentratornetz vom IPTV-Traffic
zu entlasten, um nicht denselben Stream fuer x Kunden auch x-mal
uebertragen zu muessen.
Wenn das dann aber als IP-Multicast geschehen soll, muss doch der
"IP-DSLAM" eine entsprechende "IP-Intelligenz" haben und zumindest
die IPTV-Session dort terminiert werden?
Wenn man das nicht will, bleibt doch nur noch Ethernet-Multicast?
Im Dokument http://cp.literature.agilent.com/litweb/pdf/5989-4766EN.pdf
heisst es auf Seite 5:
| Following this trend the new generation of DSLAMs
| has appeared that used Ethernet uplinks for DSL traffic
| aggregation. These devices have become known as
| Ethernet DSLAMs or IP-DSLAMs. In it’s simplest
| implementation IP-DSLAMs function as Layer-2 switches
| that backhaul subscriber traffic to Metro B-RASs or
| Broadband Network Gateways (BBNGs) using Ethernet
| VLANs in combination with Ethernet Multicast capability.
Das ist ja quasi der Fall, den Du angesprochen hast: DSLAM
als einfacher Layer 2-Switch (der eben Ethernet-Multicast
einsetzt).
Weiter auf Seite 6:
| However, as various industry surveys indicate (such as
| Heavy Reading 2005 Next-Generation DSL Equipment:
| The Path to Profitability Report), those truly IP-enabled
| IP-DSLAMs or IP-DSLAM/B-RAS hybrid devices are still a
| minority and most of IP-DSLAMs being deployed today are
| really Ethernet DSLAMs with basic multicast and IGMP
| Snooping or IGMP Proxy support.
Der DSLAM hoert also die IGMP-Nachrichten (Layer 3)
mit und passt dementsprechend seine (Ethernet-)Multicast-
Tabellen (Layer 2) an?
CU Christian
Andreas Schwarz
Appenzeller) wrote:
> Der BB-RAR spricht also die Kundenmodems auf Ethernet-Basis mit ihren
> MAC-Adressen an?
Ja, bzw. gibt es noch die Moeglichkeit auf dem DSLAM die MAC Adressen
umzuschreiben, sozusagen NAT fuer Ethernet. Kann unter Umstaenden
sinnvoll
sein.
> Und Multicast (z.B. fuer IP-TV) ist kein IP-Multicast, sondern Ethernet-
> Multicast?
Wie multicastet man denn "IP-Multicast" ueber das Ethernet Medium? 8)
Muss ja so sein, sonst haette man ein Bandbreiten Problem zwischen
BRAS und des dahinterhaengenden DSLAMs.
> Wenn aber im Grunde nur der Layer 2 ein anderer ist (Ethernet statt
> ATM), dann ist das ja eigentlich (wie schon gesagt wurde) eher ein
> "Ethernet-DSLAM" als ein "IP-DSLAM".
Ist es ja auch, bei uns nennen wir die Dinger Ethernet-DSLAM. Der
Ausdruck
"IP-DSLAM" kommt aus wohl dem Marketing, es gibt in der Tat boards um
sie
mit der IP Funktionalitaet auszuruesten, kenne aber auch niemanden der
sowas macht. Das ist aus verschiedenen Gruenden nicht praktikabel, denn
wer moechte schon Produktions IP bis in die HVTs ziehen?
--
PGP: 0x661AB571
Andreas Schwarz
> * Christian Appenzeller <chappe...@hotmail.com>:
> > Ist der zweite Hop beim VDSL-Nutzer also evtl. der IP-DSLAM
> > in der Vst?
>
> Nein, die machen hinten raus nur Ethernet. 1 Port = 1 VLAN. Aggregation-
Ich denke das skaliert nicht, die Anzahl der VLANs ist begrenzt, selbst
mit QinQ oder so ein Zeug geht das nicht auf. Die DSLAMs haben
ausreichende
Schutzfunktionen so das man gleiche Gruppen auch in die selben VLANs
packen
kann. Wie man aufteilt haengt natuerlich sehr stark von der eigenen
DSLAM
Struktur ab.
> Netz Ethernet bis zum BBRAR, der terminiert dann das PPPoE. Und das ist
> dann auch der 1. IP Hop.
>
> Hat irgendwer mal jemanden hierzulande gesehen, der DSLAMs in echter
> IP-DSLAM Rolle nutzt? Ich sehe bislang nur s/ATM/Ethernet/g unter dem
> Label "IP-DSLAM".
Nein, das kann ich mir hoechtens fuer lokal begrenzte Anwendungen
vorstellen.
--
PGP: 0x661AB571
Clemens Zauner
> Ist es ja auch, bei uns nennen wir die Dinger Ethernet-DSLAM. Der
> Ausdruck
> "IP-DSLAM" kommt aus wohl dem Marketing, es gibt in der Tat boards um
> sie
> mit der IP Funktionalitaet auszuruesten, kenne aber auch niemanden der
> sowas macht. Das ist aus verschiedenen Gruenden nicht praktikabel, denn
> wer moechte schon Produktions IP bis in die HVTs ziehen?
Die DSLAMs waren zwar nur Ethernet, aber ja - ich hatte das schon gemacht.
Vollkommen uninteressant ist das natürlich bei reinem billig-offer. Oder
wenn man überregional tätig ist.
Aber für das eine oder andere duzend Ämter ist das drinnen. Ist zwar
etwas teurer, allerdings hat man z.B. quasi kein Problem mit multicast.
Ausfälle sind auch oft kleinräumiger (= nur ein Amt). Natürlich
skaliert das wegen (z.B. aus finanziellen Gründen) nur bedingt.
Also so daneben ist das nicht, wie du tust.
cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS
Andreas Schwarz
> Andreas Schwarz <Andreas...@usenet2.schwarzes.net> wrote:
> > Ist es ja auch, bei uns nennen wir die Dinger Ethernet-DSLAM. Der
> > Ausdruck
> > "IP-DSLAM" kommt aus wohl dem Marketing, es gibt in der Tat boards um
> > sie
> > mit der IP Funktionalitaet auszuruesten, kenne aber auch niemanden der
> > sowas macht. Das ist aus verschiedenen Gruenden nicht praktikabel, denn
> > wer moechte schon Produktions IP bis in die HVTs ziehen?
>
> Die DSLAMs waren zwar nur Ethernet, aber ja - ich hatte das schon gemacht.
> Vollkommen uninteressant ist das natürlich bei reinem billig-offer. Oder
> wenn man überregional tätig ist.
Ist der Einsatz von xDSL letztendlich nicht immer "billig-offer"? Die
ganze Technik gibt es doch nur weil Kupferaltlasten ueberall rumliegen.
> Aber für das eine oder andere duzend Ämter ist das drinnen. Ist zwar
> etwas teurer, allerdings hat man z.B. quasi kein Problem mit multicast.
Welche multicast Probleme meinst du?
> Ausfälle sind auch oft kleinräumiger (= nur ein Amt). Natürlich
> skaliert das wegen (z.B. aus finanziellen Gründen) nur bedingt.
>
> Also so daneben ist das nicht, wie du tust.
Ich habe "nicht parktikabel" geschrieben, in meinem anderen post dazu
habe ich ein Szenario beschrieben wo ich mir den Einsatz vorstellen
kann.
--
PGP: 0x661AB571
Bernd Eckenfels
> Und Multicast (z.B. fuer IP-TV) ist kein IP-Multicast, sondern Ethernet-
> Multicast?
T-Home macht IP Multicast mit IGMP. Aber natürlich können die Access
Verteiler das mittels Ethernet Multicast verteilen.
Gruss
Bernd
Carsten Krueger
> bei wenigen parallelen Streams wird es wirtschaftlicher sein, den IPTV
> Traffic stumpf mehrfach durch das Backhaul Netz zu schicken. Erst ab
> einer gewissen kritischen Masse an IPTV Kunden pro ASB wird sich
> Multicasting lohnen.
Multicasting ist sowieso nicht so sehr clever, weil man darauf verzichtet
die Daten zu personalisieren.
Der große Nachteil an SAT-TV-Streams ist doch, daß sich das DRM leicht
knacken lässt weil jeder Empfänger die gleichen symmetrischen Schlüssel
hat.
Premiere und andere PayTV-Sender merken das regelmäßig.
Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
Oliver Bartels
>MAC-Adressen an?
Ja.
Hier im Keller hängt u.a. auch so ein Draytek Vogor Access Teil
im Rack, mit dem wir ein DSL Netz nachbilden, der macht das.
Die Teile sind garnicht mal schlecht und schön klein.
Hintendran hängt dann nur unser BRAS und schon sieht das
aus wie ganz normales x-DSL, einschließlich Modem und PPPOE
Einwahl.
ATM gibt es da nur noch zwischen DSLAM und Kunden-Modem,
priorisieren kann der DSLAM den Traffic trotzdem.
>Und Multicast (z.B. fuer IP-TV) ist kein IP-Multicast, sondern Ethernet-
>Multicast?
Ethernet kann in der Tat gesteuertes Multicast, es gibt dafür
einen speziellen Block MAC Adressen, der auch von sehr vielen
Netzwerkbausteinen unterstützt wird.
Der Draytek kann dazu zwecks selektiver Weiterleitung z.B.
IGMP snooping, und ja, das funktioniert. Auf der Layer 3
wird der Traffic einfach an eine Multicast-Zieladresse
geschickt, das abgebende Interface setzt das dann auf
den fraglichen MAC Block um.
Gruß Oliver
--
Oliver Bartels + Erding, Germany + obar...@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Marc Langer
> On 03 Feb 2008 15:39:47 +0100 Andreas Schwarz wrote:
>> Ja, bzw. gibt es noch die Moeglichkeit auf dem DSLAM die MAC Adressen
>> umzuschreiben, sozusagen NAT fuer Ethernet. Kann unter Umstaenden
>> sinnvoll sein.
>
> wofuer nutzt man dieses Feature?
Zuordnung einer Session zu einem DSLAM(-Port) im Radius-Accounting.
Ist aber praktischer über ein Vendor-specific Tag im PPPoE-Paket
("Circuit-ID") übermittelbar.
Marc
Oliver Bartels
<use.net....@neverbox.com> wrote:
>Multicasting ist sowieso nicht so sehr clever, weil man darauf verzichtet
>die Daten zu personalisieren.
Das ist kein Argument, man kann teilweise mit einer privaten
TCP Session personalisieren und einen sehr schnell
wechselnden Schlüssel übergeben.
Ein komplett kundenspezifische live-Encryption ist zwar
heute möglich, man findet sie wegen des Aufwands
aber eher selten.
>Der große Nachteil an SAT-TV-Streams ist doch, daß sich das DRM leicht
>knacken lässt weil jeder Empfänger die gleichen symmetrischen Schlüssel
>hat.
Wenn man schnell genug wechselt und die Verarbeitung
der Schlüssel beim Empfänger schützt, dann nicht.
Ersteres kann man bei IP-TV, da der Empfänger infolge
des Rückkanals den neuen Schlüssel sofort instantan
anfordern kann.
Die Bildung eines Session Keys ist durchaus auch bei
anderen Verschlüsselungen üblich, z.B. weil asymmetrische
Verfahren wie RSA einen extrem hohen Rechenaufwand
benötigen.
Natürlich könnte man den Schlüssel dann aus dem
Empfänger abgreifen und an ein Schwarzseher-Peer-
Netz verteilen, nur ist das:
a) für den Abgreifer juristisch sehr gefährlich und
auch leicht nachvollziehbar, er muss Daten schicken.
b) mit geeignerter Hardware auch leicht abstellbar.
Für ein halbwegs sicheres System gehört die Schlüssel-
Verarbeitung zusammen mit dem "ich muss große
Datenmengen handhaben" MPEG Decoder oder
zumindest CAM auf _einen_ integrierten Schaltkreis,
der Schlüssel wird am besten mit den bekannten
Schlüsseltauschverfahren (DH, RSA usw.)
gebildet und/oder teilweise chipindividuell eingebrannt.
Das Konzept muss halt so sein, dass man es
veröffentlichen kann (mit Ausnahme der Keys) und
es trotzdem sicher ist.
Dann herrscht Ruhe, denn den decodierten MPEG
Datenstrom neu live zu encodieren und zu senden,
macht wenig Spass, und bei jedem Schwarzseher
individuell IC's zu manipulieren, ist wirtschaftlich für
die bösen Buben einfach zu aufwendig.
>Premiere und andere PayTV-Sender merken das regelmäßig.
Die haben auch keinen parallele TCP Session mit
"ich hab den neuen Key sicher bekommen" bestätigendem
_Rückkanal_. Deshalb können sie nicht so wechseln, wie
sie es gerne täten.
Außerdem leidet Premiere noch unter dem alten Betacrypt,
welches immer noch aus Hardware-Kompatibilitätsgründen
unter dem Nagra liegt. Das war nur "Security by Obscurity"
und damit nicht wirklich sicher.
Dass das ein _wesentliches_ Problem ist (da Premiere
bisher die CAM Modulen nicht getauscht hat und die
Kommunikation zum CAM ungesichert ist), das auch
Nagra beim besten Willen nicht lösen kann, sieht man
daran, dass z.B. NDS von BSkyB bisher nicht geknackt
wurde. Allerdings müsste man dann sehr viel Hardware
im Feld tauschen, was auch ein wirtschaftliches Problem
darstellt.
Bernd Eckenfels
> Wenn man schnell genug wechselt und die Verarbeitung
> der Schlüssel beim Empfänger schützt, dann nicht.
Das schuetzt allerdings nur von Life-Mitsehern (Fussball), nicht davor den
Stream aufzuzeichnen und Offline zu entschluesseln (Kinofilm).
Gruss
Bernd
Thomas Gemmer
> Hallo Marc,
>
> [Marc Langer schrieb:]
>
>> Nein, IP-DSLAM heisst nur, dass er kein ATM mehr macht. Letztlich
>> ist das eine Art Ethernet-Switch. Nur fuer die eigentliche Kundenleitung
>> braucht er natuerlich noch ATM, klar.
>
> Der BB-RAR spricht also die Kundenmodems auf Ethernet-Basis mit ihren
> MAC-Adressen an?
Korrekt.
> Und Multicast (z.B. fuer IP-TV) ist kein IP-Multicast, sondern Ethernet-
> Multicast?
Korrekt.
> Wenn aber im Grunde nur der Layer 2 ein anderer ist (Ethernet statt
> ATM), dann ist das ja eigentlich (wie schon gesagt wurde) eher ein
> "Ethernet-DSLAM" als ein "IP-DSLAM".
Auch korrekt, aber anscheinend meint alle Welt, daß sich IP-DSLAM
hochwertiger anhört.
Gruß,
Thomas
Oliver Bartels
<Andreas...@usenet2.schwarzes.net> wrote:
>Ist es ja auch, bei uns nennen wir die Dinger Ethernet-DSLAM. Der
>Ausdruck
>"IP-DSLAM" kommt aus wohl dem Marketing, es gibt in der Tat boards um
>sie
>mit der IP Funktionalitaet auszuruesten, kenne aber auch niemanden der
>sowas macht. Das ist aus verschiedenen Gruenden nicht praktikabel, denn
>wer moechte schon Produktions IP bis in die HVTs ziehen?
Eigentlich möchte man das schon, um z.B. lokale VoIP oder P2P
Verbindungen lokal zu belassen und den übrigen Traffic besser
lastmäßig verteilen zu können. Im IP-Medienzeitalter kann das
den gewissen Unterschied ausmachen.
Wir machen das in dem von uns betreuten Wimax Netz auch so,
die AC Router terminieren die PPPOE Sessions lokal.
D.h. "Klein Kleckersdorf" hat seinen eigenen ferngewarteten BRAS.
Funktioniert bestens ;-)
Das Kostenargument ist für uns keines, da die AC-Router auf
einer Eigenentwicklung (eigene PPPOE/L2TP Plattform auf einer
schnellen 16 Core CPU) basieren, die wir natürlich zu guten
Konditionen kalkulieren können.
Thomas Gemmer
> Hallo Marc,
>
> [Marc Langer schrieb:]
>
>>> Und Multicast (z.B. fuer IP-TV) ist kein IP-Multicast, sondern Ethernet-
>>> Multicast?
>> Doch, das wird schon IP-Multicast sein (ohne das jetzt selbst
>> einzusetzen). Entweder ueber die PPPoE-Verbindung oder auf einem
>> getrennten PVC/VLAN, wo per DHCP eine private IP-Adresse dafuer
>> vergeben wird.
>
> Meines Wissens wird doch mit Multicast angestrebt, das Backbone
> und eben auch das Zufuehrungs-/Konzentratornetz vom IPTV-Traffic
> zu entlasten, um nicht denselben Stream fuer x Kunden auch x-mal
> uebertragen zu muessen.
>
> Wenn das dann aber als IP-Multicast geschehen soll, muss doch der
> "IP-DSLAM" eine entsprechende "IP-Intelligenz" haben und zumindest
> die IPTV-Session dort terminiert werden?
>
> Wenn man das nicht will, bleibt doch nur noch Ethernet-Multicast?
Letzeres ist richtig. Es gibt kaum DSLAMs, die wirklich auf IP Ebene
arbeiten. Daher ist der Multicast ein Ethernet Multicast. Das hat dann
aber zur Folge, daß für IP Streams innerhalb einer PPPoE Session kein
Multicast erfolgt, sondern daß dies nur für IP over Ethernet (IPoE)
unterstützt wird.
> Der DSLAM hoert also die IGMP-Nachrichten (Layer 3)
> mit und passt dementsprechend seine (Ethernet-)Multicast-
> Tabellen (Layer 2) an?
Jo.
Gruß,
Thomas