hier als beispiel *ein* ftp-download mit 2x6Mbps gebündelt:
- Code: Alles auswählen
name: eoip-wo1 eoip-wo2 pppoe-wobond
rx-packets-per-second: 467 466 933
rx-drops-per-second: 0 0 0
rx-errors-per-second: 0 0 0
rx-bits-per-second: 381.0kbps 379.7kbps 566.7kbps
tx-packets-per-second: 468 468 936
tx-drops-per-second: 0 0 0
tx-errors-per-second: 0 0 0
tx-bits-per-second: 5.5Mbps 5.5Mbps 10.5Mbps
man sieht, daß sich die bandbreiten der mono-links nicht exakt am bonding-link aufsummieren, weil durch das bündeln ein overhead entsteht. die erfahrung zeigt, daß der "effektive" bündelungsfaktor (i.e. der bündelungsfaktor bezogen auf die nominalraten der leitungen) unter guten bedingungen so bei 1,8 liegt.
und weils so schön zum thema paßt, noch ein paar worte zum thema "bonding system vs. backup system". diese beiden begriffe haben wenig miteinander zu tun, werden aber manchmal verwechselt. denn:
I. bonding system:
bei einem typischen bonding system wird man folgendes tun:
1. 2 anschlüsse mit derselben bandbreite.
das macht man aus effizienzgründen. liegen 2 anschlüsse mit verschiedenen bandbreiten vor, funkt zwar die bündelung, aber die überschüssige bandbreite des stärkeren anschlusses bleibt wertlos aufm asphalt liegen. der alu hat das eh schon erwähnt.
2. beide anschlüsse mit derselben zugangstechnologie und beim selben provider.
das macht man, um den latenzunterschied (zum bündelungsserver) der beiden leitungen zu minimieren. wird der latenzunterschied zu hoch, rasselt der bündelungsfaktor in den keller, weil der zugangsrouter in dem fall hauptsächlich damit beschäftigt ist, die out-of-order reinkommenden pakete neu zu ordnen.
II. backup sytem
bei diesem ansatz wird man fast diametral entgegengesetzt vorgehen:
1. die bandbreiten der mono-links spielen keine rolle (, weil man in dem fall höchstens load balancing macht)..
2. man zieht sich 2 verschiedene carrier von verschiedenen providern rein.
das macht man aus der einfachen überlegung heraus, daß ein gleichzeitiger ausfall von verschiedenen carriern bei 2 verschiedenen providern weniger wahrscheinlich ist als der ausfall eines providers mit einem carrier.
damit haut man sich aber auch automatisch die bonding fähigkeiten des systems zusammen, s. #I.
so, und um diese grauen fakten ein wenig aufzulockern, eine "lustige" episode aus den niederungen des alltags:
ich hab einen lieben freund, der früher einen anschluß von ascus und einen von telematica hatte und wie ich beide anschlüsse bündelte. das ganze graffl funkte zufriedenestellend, bis telematica wieder mal auf die geniale idee kam, die ip ranges zu ändern. ip-änderungen per se sind nicht dramatisch, blöderweise änderte sich aber bei dieser aktion von telematica auch das routing.
folge:
der latenzunterschied der beiden leitungen stieg auf einen faktor ~2 an und der bündelungsfaktor tauchte von 1,7 - 1,8 auf läppische ~1,2 ab, was praktisch wertlos is.
tja, und da mein freund das bonding dringender braucht als ich, tauschten wir (wieder mal btw.) provisorisch unsre zugänge. nach dem tausch war mein freund also mit 2x ascus und einem latenzunterschied von praktisch 0 unterwegs, und das bonding funkte bei ihm wieder einwandfrei.
blöderweise straft gott sofort, wenn ihm fad in der birn is. es gab anfang oktober mitten in der nacht einen (und bei dem blieb es leider nicht)
totalausfall bei ascus. gut, ein totalausfall mitten in der nacht is für für vati und mutti nicht mal wahrnehmbar, blöd wird so'n vorfall nur dann, wenn man übers inet z.b. computersimulationen steuert, deren ergebnise man am nächsten tag bei einer tagung braucht. die tagung konnte sich mein freund abschminken...
hätten wir unsre zugänge nicht getauscht, dann hätte mein freund zwar net gscheit bündeln können, es hätte aber der fallback auf den intakten anschluß von telematica gegriffen, seine simulationen wären sauber beendet worden, ja, und er hätte wirklich zu der tagung fliegen können...
hab ich schon erwähnt, daß bonding != backup/fallback gilt?
lg
zid
- bei Speedtest geht es schon
