Nieuw algoritme optimaliseert netwerkverkeer

Onderzoekers hebben een methode ontwikkeld om netwerkverkeer in dynamische netwerken effectiever te routeren. Zij slaagden hierin door minder belangrijke delen van het netwerk te negeren en niet alle veranderingen te verspreiden.

De informatici van de universiteit van Californië zeggen met hun methode de efficiëntie van het routeren van netwerkverkeer aanzienlijk te verbeteren. Zij maken hierbij gebruik van het door hen ontwikkelde XL-algoritme. De verbindingen binnen het netwerk die XL legt, zijn vrijwel even goed of even direct als de routering die zou plaatsvinden bij volledig in kaart gebrachte netwerken. Een XL-netwerk negeert echter een deel van de veranderingen in het netwerk, zodat het systeem minder overhead kent om het overzicht te bewaren van alle mogelijke routes en bestemmingen.

Een netwerk verandert constant van samenstelling, zo leggen de auteurs van het algoritme uit. Computers, servers en andere apparatuur worden steeds aan het netwerk verbonden of weer ontkoppeld. Veel van die veranderingen zijn echter triviaal voor het routeren van verkeer, maar traditionele netwerken houden alle veranderingen bij en verspreiden die informatie naar alle punten. Het toevoegen van, bijvoorbeeld, een laptop via internet zal echter weinig impact hebben op het routeren van het netwerkverkeer. Door dergelijke apparatuur met weinig bandbreedte goeddeels te negeren, kan het netwerk met minder overhead zijn data routeren. Het XL-algoritme is ontwikkeld om te bepalen welke veranderingen wel, en welke niet aan andere knooppunten doorgegeven moeten worden.

Reacties (51)

[matthijsberg]

Vraag; de meeste dynamische routerings protocollen houden alleen waarden van de verbindingen tussen routers bij (een verbinding van een laptop aan een netwerk is een geswitchte verbinding en wordt toch niet door het routerings protocol bijgehouden???)

Waar komt dan het wel of niet inpluggen van een laptop naar voren? Dit heeft volgens mij geen invloed op de verbindigen tussen de routers.
In het originele artikel zie ik ook niets over laptops (met nodes bedoelen ze routers in het netwerk)

Zaken als afstand en snelheid van de lijnen tussen de routers worden in waarden in een route tabel opgenomen en op basis van die waarde kan de snelste route worden bepaald. Als er een lijn vervalt dan wordt de tabel geupdate, en wordt er een andere route gebruikt. Deze wijziging wordt naar alle nodes in het netwerk gestuurd. Als je dit beperkt tot de nodes die de informatie ook echt gebruiken kan je de overhead beperken.

Ik kan me wel voorstellen dat het protocol de load van de verbinding beter kan inschatten en bij een hoge load op een snelle verbinding toch voor de minder snelle verbinding kan kiezen. (dacht dat bestaande protocollen dat ook al kunnen)

Wie roept?

[Electrowolf]

Deze optimalisatie van het routing algoritme staat los van load balancing.

Het algoritme kijkt nu naar het nut van het doorgeven van een wijziging in de netwerk structuur.

Als iemand een klein netwerk van een paar honderd workstations in China aansluit dan is dat niet interessant voor de switches van een vergelijkbaar netwerk in Canada. Daarentegen is die wijziging wel interessant voor de switches van de Chinese ISP en misschien ook nog wel voor een paar andere grote switches(zie een AIX) in de wereld.

Het moeilijke is om te bepalen wat wel en wat niet interessante informatie is voor een bepaalde switch/router. In de bron stelt men dat ze dat doen aan de hand van 3 regels, maar helemaal duidelijk wordt nog niet.
Maar probeer het zelf maar, een nuttige regel te bedenken waarmee je kan bepalen welke informatie wel en welke informatie niet nuttig is voor een bepaalde switch aan de hand van de graaf genaamd internet .

[Reactie gewijzigd door Electrowolf op 27 juli 2024 02:15]

[TrailBlazer]

Je beschrijving klopt inderdaad. Er is een protocol, EIGRP, wat inderdaad in staat is om de load op een link mee te nemen in zijn berekeningen. Cisco en ieder ander weldenkend mens raadt dit echter af om dit toe te passen.
Stel je voor een link zit vol dus opeens ga je verkeer ook over een ander pad sturen. Vervolgens wordt de primaire link minder belast dus wordt die weer geprefereerd. Nu kan je uiteraard allerlei ingewikkelde dempingsmechanismes bedenken maar stabiel krijgen is echt een drama.

[MSalters]

Het hoeft ook niet stabiel te zijn. Internet is packed-based. So what dat je het ene moment 100% van je pakketten over je primary stuurt, daarna 99%, en daarna weer 100%? Elk pakket gaat nog steeds over 1 verbinding.

Oh, en je moet het natuurlijk niet implementeren als "de secondary link draait nu op 0% load, dus daar gaan 100% van de pakketjes heen".

[Verwijderd]

Dat geldt alleen als de primary en secondary allebei op dezelfde router zitten. Als ze op 2 verschillende routers zitten, moet je elke keer als de routering wijzigt je routing-protocol updates laten versturen, dan moeten alle routers in het netwerk deze update gaan verwerken, een nieuwe routetabel aanmaken, zelf weer updates gaan versturen. Gevolg is dat je netwerk nooit convergeert en nooit stabiel wordt. Voor een netwerkje met een stuk of 10 routers zal dat nog wel gaan, maar een netwerk met honderden of duizenden routers gaat dat hopeloos fout.

Jij hebt het zelfs over het Internet. De volledige Internet-routingtabel bestaat op het moment uit 300 000 routes. (routes, niet routers), zelfs zonder updates op basis van link-utilization krijgt elke router op Internet op dit moment gemiddeld 2,5 routing updates per seconde te verwerken, tijdens grote verstoringen loopt dat op naar 15000 updates per seconde. [bron]. Als je daar ook nog eens voor al die 300 000 routes wijzigingen in gaat maken als de link wel of niet gebruikt wordt gaat het hele Internet onderuit.

[Dennizz]

Ik heb even een stukje gelezen, omdat ik van mening was dat huidige routing protocollen voldoende in staat zijn om problemen op te vangen. Het geen wat dit protocol lijkt te doen in plaats van full link-state tables uit te wisselen binnen 1 routing area, is approximate link-state onderhouden. Hierbij wisselen de routers alleen volgens het algoritme belangrijke informatie uit. Daardoor onstaat geen full link-state table zoals bij OSPF bijvoorbeeld, waar elke router het hele netwerk kent, maar slechts whereabouts van de beste paden....

Wat dit te doen heeft met het aansluiten van bijvoorbeeld een server of pc (t.net artikel) bevat ik nog niet helemaal...

edit:
Mijn inziens kun je door op de juiste manier het netwerk te designen en op te delen in area's voldoende schalen. Op de area border routers vind er dan namelijk summerization plaats, waardoor niet de volledige link-state database verder geflood word na die router.

[Reactie gewijzigd door Dennizz op 27 juli 2024 02:15]

[Crazz]

Mijn inziens kun je door op de juiste manier het netwerk te designen en op te delen in area's voldoende schalen. Op de area border routers vind er dan namelijk summerization plaats, waardoor niet de volledige link-state database verder geflood word na die router.

Dit snapt natuurlijk niemand, bestaat deze tekst ook in het Nederlands?

[Verwijderd]

Ik snap het anders prima. :-)

In een netwerk is het handig als je routers elkaar vertellen welke netwerken wel en niet bereikbaar zijn. Ten eerste betekent dat dat je niet bij elke wijziging in het netwerk alle routers hoeft te gaan configureren en ten tweede kan het netwerk dan bij uitval zelf zorgen dat een backup-route wordt gekozen.
Een protocol waarmee dit wordt geregeld is een routing protocol, die bestaan in verschillende soorten, link-state is daar een van. OSPF, waarop XL een uitbreiding is,is een voorbeeld van een link-state protocol.

Een OSPF router vertelt aan zijn 'buren' welke netwerken hij kan bereiken, die buren sturen (flooden) die informatie, aangevult met hun eigen informatie door naar hun buren en zo krijgen alle routers een volledige 'kaart' van het netwerk. Op basis daarvan bepalen ze voor elke bestemming in het netwerk de beste (kortste) route.

Dus als er een interface staat te klapperen (up-down-up-down) gaat er steeds een berichtje door het netwerk (link state update) "dit netwerk is niet bereikbaar", "dit netwerk is wel bereikbaar", "wel", "niet" etc. Op basis van die updates bepalen de andere routers een nieuwe route door het netwerk, via een alternatieve route als die beschikbaar is.

Als je netwerk nu erg groot wordt, krijg je veel van dit soort updates en zal het netwerk continue aan het convergeren zijn: er zijn zoveel updates dat het netwerk nooit stabiel wordt omdat steeds als de nieuwe routes berekend zijn er al weer een nieuwe update komt.

Een netwerk dat gebruik maakt van OSPF kan je opdelen in zogenaamde areas. Hierdoor verdeel je je netwerk in kleinere delen. Binnen zo'n area zijn alle details van het netwerk bekend, maar buiten de area worden sommige details weggelaten: er wordt wel doorgestuurd dat een bepaald netwerk bereikbaar is, maar niet precies via welke routes. Er wordt alleen doorgegeven dat een bepaald netwerk bereikbaar is via een "Area Border Router" (ABR). Dat is een router die 2 areas met elkaar verbindt. Binnen de andere area is de route naar die ABR bekend en zo kan dus ahw in 2 stappen bepaald worden hoe er naar het betreffende netwerk gerouteerd kan worden.

Nu kan je nog een stap verder gaan: summarization, oftewel samenvatten van routes. In plaats van alle kleine netwerkjes apart doorgeven, vat je ze samen in 1 route-update. Dus in plaats van door te geven 192.168.1.0/24, 192.168.2.0/24, enz tot 192.168.255.0/24 (waarbij /24 betekent: laatste getal varieert van 0 tot 255), geef je door 192.168.0.0/16 (waarbij /16 betekent: laatste 2 getallen varieren van 0 tot 255). Hiermee vervang je dus 255 route-updates door 1. Natuurlijk zijn hier nog variaties in mogelijk (bijvoorbeeld 4 of 8 routes samengevoegd) en moet je netwerk hier wel op voorbereid zijn: als 192.168.1.0 aan de linkerkant van je netwerk zit en 192.168.2.0 aan de rechterkant, kun je ze niet 'summarizen'.

[Obiter dictum]

Is dat op het moment dat er een laptop, PC, tablet etc bijkomt, er dus een pad naar de desbetreffende hardware (voor het het gemakt) bijkomt. Deze paden zijn in feite voor het netwerk irrelevant, en slechts voor betreffende hardware intressant. De bedoeling van dit protocol is een onderscheid te maken tussen de 'openbare wegen', die voor iedereen intressant zijn, en de 'oprijlanen', die slechts voor de betreffende hardware intressant is.

In feite als een wegenkaart; die kan ook niet worden geupdate elke keer als iemand een oprijlaan wijzigt of bijbouwt.


Edit; Naar aanleiding van jouw edit.
En als dit protocol zélfs de summerization op de area border routers overbodig maakt? Dat is dan nog minder belasting voor het netwerk.

[Reactie gewijzigd door Obiter dictum op 27 juli 2024 02:15]

[matthijsberg]

Ik bemoei me er ook maar even tegenaan als je paden van een PC, server, o.i.d. er bij plaatst dan heeft dit geen invloed op de routeringstabellen.

Als je een router toevoegd aan het netwerk uiteraard wel, maar aan een router sluiten we geen devices aan..

Zoals ik het lees is het de bestaande functionaliteit van dynamische route protocollen maar dan geoptimaliseerd en heeft het niets met client devices te maken. Het protocol wordt gebruikt in grote netwerken met vele verbingingen en vele verschillende paden tussen de routers (als er maar één pad tussen routers is is er niet veel te optimaliseren )

Het gaat over het beperken van de updates naar alleen relevante routers. Ze ontvangen dan de update niet (bandbreedte) en hoeven niet te herberekenen (processor).

[boner]

voor die menschen die denken dat het snellere data-overdracht verzorgt: nee! Het is een optimalisatie voor routeringsprotocollen. Een router vertelt zijn buren welke routes hij kent. Op die manier wordt door de routers een soort wegenkaart aangelegd met de optimale route van A naar B. Bij interne netwerken vaak met OSPF en bij externe netwerken vaak met BGP al zijn voor beiden zeer veel alternatieven. Deze hier besproken manier is een optimalisatie voor die gevallen dat er een link uitvalt, of instabiel is. Dat kost normaliter veel tijd en verkeer om een nieuwe route (wegenkaart) te kunnen tekenen. Nu dus minder.

that's all. geen impact voor stabiele netwerken.

@ TrailBlazer
er zijn wel alternatieven voor BGP al worden die in de praktijk niet of nauwelijks gebruikt.
Exterior routing protocols

Exterior Gateway Protocols (EGPs) route between separate autonomous systems. Examples include:
* EGP (the original Exterior Gateway Protocol used to connect to the former Internet backbone network; now obsolete)
* BGP (Border Gateway Protocol: the current version, BGPv4, dates from around 1995)
* CSPF (Constrained Shortest Path First)

EN dan nog even over OSPF vs (E)IGRP. Het grote voordeel van OSPF is dat het een open standaard is. ALs je alleen maar Cisco routers hebt is (E)IRGP zeker geen slap aftreksel van OSPF. Maar dat is een kwestie van smaak en andere subjectieve overwegingen. Veelal wordt OSPF gebruikt omdat iedereen in routerland er kennis van heeft en het dus goedkoper is om te implementeren. Het grootste netwerk naast internet (dat van General Electric) gebruikt niet voor niets (E)IGRP op veel plekken.

[Reactie gewijzigd door boner op 27 juli 2024 02:15]

[Annihlator]

Het is toch ook zo dat deze langzamere apparaten zegmaar negeert, als ik het artikel goed heb geinterpreteerd, daarmee zorgt de router dus toch voor een nog ietwat betere optimalisatie van zijn routes?
De impact zal denk ik wat dat betreft maar klein zijn, maar ach.

[TrailBlazer]

Er is voor BGP echt geen alternatief hoor. Voor OSPF is maar een alternatief (al denkt Cisco dat EIGRP dat ook is) en dat is IS-IS. Verder valt het wel mee met hoe lang dat duurt. De huidige corerouters hebben zoveel processorkracht dat ze echt binnen seconden een nieuwe route hebben bepaald.

CSPF lijkt gewoon een uitbreiding op een link-state protocol te zijn en is dus geen vervanger voor BGP. EGP is obsolete en niet meer ondersteund kortom geen alternatief wat mij betreft.

Het feit dat een groot netwerk EIGRP gebruikt en de rest van de wereld OSPF/ISI wil toch wel wat zeggen. Grote kans dat dit historisch gegroeid is omdat Cisco de IOS'en met EIGRP goedkoper warem dan de IOS'en met OSPF erin. Je kan een hoop tweaken met EIGRP maar het is het nooit helemaal. Het is niet voor niks dat het zwaartepunt op OSPF/ISIS en BGP ligt in het CCIE R&S en SP examen.

[Reactie gewijzigd door TrailBlazer op 27 juli 2024 02:15]

[Skinkie]

De huidige corerouters hebben zoveel processorkracht dat ze echt binnen seconden een nieuwe route hebben bepaald.

Ja, ja... daarom loopt Quagga ze er bij het inladen allemaal uit... het enige wat interessant is aan core routers is de ASIC, voor meta protocol verwerking moet je juist daar niet zijn.

[berryberry]

Stomme vraag misschien maar kan dit op online gamen een voordeel geven ?

of is dit enkel voor een bedrijfsnetwerk gunstig ?

Dit bedoel ik dus voor de LAG time

[Hyperized]

De lag heeft in de meeste gevallen een geografische oorsprong. De tijd die een pakketje neemt om over het Internet te reizen is (vooral binnen Nederland) al geoptimaliseerd. Als je verbind met een server die zich in Amerika bevind doet het pakketje er standaard gewoon 100ms langer over om z'n bestemming te bereiken omdat het (optische) signaal nou een maal niet sneller gaat. Let wel, er moet voor een server in Amerika een afstand van 8500km afgelegd worden! (in minder dan 100ms heen en terug)

Verder tellen lokale invloeden altijd mee, de belasting van de server, de configuratie van de game en niet te vergeten de staat van je eigen thuis netwerk. Slecht WiFi of slechte kabels blijken maar al te vaak de oorsprong van hoge packetloss te zijn.

Het antwoord is dus: dit bericht is vooral nuttig voor school en bedrijfsnetwerken, en minder interessant voor de gamers onder ons

[Jaco69]

Ook het aantal IP routers nodig is verantwoordelijk voor vertraging. Gelukkig kan je verbazend ver komen door maar een paar keer op IP niveau gerouteerd te worden door ATM en MPLS.

[TrailBlazer]

Alsof een ATM node geen latency heeft. Een MPLS router is 9/10 keer gewoon een router die nog steeds een IGP als OSPF nodig heeft om te bepalen welke tag er gebruikt moet worden om een packet te switchen.

[Blokker_1999]

lag is geen tijd, lag is in niets uit te drukken, het is een fenomeen waarbij synchronisatie in het spel verdwijnt door bijv. een hoge of sterk wisselende latency (ping) of packetloss.

Over het algemeen word de routing op het internet vrij goed opgezet zodat de af te leggen afstand en het aantal tussenpunten zoveel mogelijk beperkt word. Het lijkt mij in dit geval dan ook eerder over een lokaal, steeds veranderend netwerk te gaan waarbij het bepalen van de route geoptimaliseerd word waardoor een pakketje in dat netwerk sneller op zijn bestemming kan komen.

[Verwijderd]

lag = latency

waar jij het over hebt is pingflux of packetloss

[SirNobax]

Helaas, geen sigaar voor jou.

LAG
lag, - lagged, lag·ging
Synonyms . loiter, linger, slowing, slowdown.

Dat 'gamers' die term gebruiken zodra ze een hoge ping hebben (of lage fps) betekend nog niet dat 'lag hetzelfde is als latency'.
Latency word uitgedrukt in tijd, lag kan ook in meters worden uitgedrukt.

Beetje, "de koeien zijn dieren, maar dieren zijn geen koeien"-verhaal.

[Reactie gewijzigd door SirNobax op 27 juli 2024 02:15]

[Greyh0und]

latency != lag...
een lage latency KAN zich uiten in lag, maar packetloss uit zich OOK in lag.
latency is gewoon latency

[Romke]

Dit soort technieken worden over het algemeen vooral eerst ontwikkeld voor de omgevingen waar netwerken in eerste instantie voor bedoeld zijn, namelijk bedrijven, defensie, scholen etc. Serious business om het zo maar even te noemen.

Net als dat op het water de beroepsvaart voorrang heeft op pleziervaart

[dgompie]

Behoorlijk off-topic: Dat is eigenlijk grappig, want op de weg hebben vrachtwagens geen voorrang op personenwagens, waarom op het water wel?

[s463042]

Wel eens met een vrachtschip geprobeerd uit te wijken of te remmen?

[Possstema]

En, wie zegt dat de rit in een personenauto niet beroepsgerelateerd is. Dat is op het water vrij makkelijk te onderscheiden.

[Zyppora]

In sommige delen van het land is er dan ook een speciale vrachtwagenstrook waar je met personenautos niet op mag rijden Daarnaast is het moeilijk vast te stellen of de personenauto in kwestie geen woon-werk-verkeer is.

[Mizitras]

Gezien de menselijke reactiesnelheid, en de tijd waarmee vanaf jou thuis, de verandering ten vroegste visueel waarneembaar is, maken die paar milliseconden niets uit. Tussen 50 en 51 zou je dat ook kunnen zeggen, maar het 'tikt aan', tussen 100 en 200ms zit daardoor wel een merkbaar verschil. Tussen quasi 0 (<1 millisec) en 100, zo goed als niet.

Of zoals jij zelf al zegt: een andere muis kan ook al wonderen verrichten. Maar dat kan een goed uitgeslapen gamer ook misschien

[CAPSLOCK2000]

Veel mensen vergeten dat gamen meer is dan reageren.

Denk even aan een race spel. Je weet al lang van te voren wanneer de bocht komt. Je hoeft niet binnen 200 milliseconden te reageren, want je weet al seconden van te voren wanneer de bocht komt.

De kunst is om het moment dat je drukt goed te timen (waarbij je dus ook rekening moet houden met je eigen traagheid en onnauwkeurigheid).
In dergelijke situaties kunnen mensen op minder dan 50 milliseconde nauwkeurig timen.
Ervaren drummers kunnen binnen 20 milliseconde nauwkeurig bepalen wanneer hun stokje neerkomt.

Als je zuiver op andere mensen moet reageren is een ping onder de 50 ruim voldoende, maar er zijn gevallen te bedenken waarin je onder de 25 wil blijven.


PS. Dit heeft allemaal maar weinig met bovenstaande artikel te maken. Als particulier zal je nooit iets merken van dit betere algoritme.

[Reactie gewijzigd door CAPSLOCK2000 op 27 juli 2024 02:15]

[Verwijderd]

De hele paper is te vinden op http://charlotte.ucsd.edu/users/savage/papers/Sigcomm08.pdf

[Laurens-R]

Vraag me af in hoeverre dit het dichtslippen van het internet uitstelt.

[the_stickie]

Afaik slibt het internet niet dicht. Integendeel: er komt alsmaar meer bandbreedte beschikbaar, en de toepassingen worden alsmaar veelzijdiger.
Wat wél een feit is is dat we bijna zonde ip-adressen ziiten, misschien is het dat waar je op doelt? Dat heeft alleszins niet direct iets te maken met dit verhaal

Overigens is dit het zoveelste routing-protocol dat de hemel belooft imho. Laten we nog even wachte hoe één en ander in de praktijk gezet gaat worden

[Verwijderd]

Het internet slibt wel een beetje dicht hoor, de AMS-IX zit vrij dicht tegen zijn maximum aan en ze wachten met smart op de 40Gbit standaard als ik me niet vergis.

Side-note: AMS-IX = niet het gehele internet maar toch een vrij groot deel vanuit onze positie gezien de verbinding naar de rest van de wereld.

[MSalters]

Nu is AMS-IX bij uitstek een niet-dynamisch deel. Er komen niet dagelijks ISPs bij. Dit is veel belangrijker voor mesh networks. Het OLPC project zal er blijer mee zijn.

[Verwijderd]

Het klopt dat de AMS-IX vrij vol zit daarom zijn ze ook aan het spreiden.
Zo hebben ze de GN-IX (groningen) recentelijk nog uitgebreid.

[Mizitras]

Addendum: Toch wel enkele procentjes van het www-verkeer komt via de AMS-IX lijnen.

[Verwijderd]

Ik vraag me af wat de meerwaarde hiervan gaat zijn. Bestaande protocollen hebben al zat in huis om dit soort zaken af te vangen (route summerisation etc). Ook worden subnetten veelal in grote classes naar een ISP netwerk gerouteerd, om daar pas lokaal opgeknipt te worden in kleinere stukjes, info dus die alleenmaar in het ISP netwerk van belang is, en al zowiezo niet naar buiten gecommuniceerd wordt.

#edit

@ jeroenr

Thanks, dat was precies wat ik bedoelde. Een correct gedesigned en geimplementeerd netwerk heeft al helemaal geen last van dit soort zaken. En al zeker niet met de hoge hardware standaarden in routers vandaag de dag. 'OSPF XL' lijkt in mijn ogen ook gewoon meer op een misschien wat makkelijker te implementeren routing protocol, al is het correct configureren van OSPF etc op zich ook niet zo heel lastig als je een goede network layout hebt gemaakt.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 02:15]

[Hyperized]

De standaard toepassing van deze netwerken gaan uit van een campus situatie, de verwijzingen van het negeren van het toevoegen van kleine nodes suggesteren dit.

Oftewel dit bericht is net zo handig handig voor mensen die grote campus-achtige netwerken ontwerpen, bouwen of beheren als voor de grote ISP's.

In ieder geval vind ik het goed om te zien dat er nog altijd hard gewerkt word aan de optimalisatie van het Internet. Recentelijk hebben er zich heel wat problemen op voorgedaan en het is in ons alle belang dat we een netwerk creeëren dat zo dynamisch mogelijk om foute routes heen werkt. Als hier een nieuwe en snellere methode iets aan kan toevoegen kan ik niet wachten tot deze methode door de markt opgepakt word.

[Verwijderd]

Wat ik uit het verhaal begrijp is het een uitbreiding op OSPF, waarbij er als het ware automatisch bepaald wordt waar area-grenzen liggen en waar gesummarized wordt. Het lijkt mij ook dat als je netwerk goed gedesigned is, dus met area's op de juiste plaatsen en summarization op de juiste plaatsen, waardoor ook 'kleine' updates niet meer door je hele netwerk gepropageerd hoeven te worden dat 'OSPF XL' daar niet veel meer aan kan verbeteren.

[Jaco69]

Ethernet en IP kunnen best wel een verbetering gebruiken. Het is verbazend gemakkelijk om een netwerk met ingebouwde redundantie compleet onderuit te halen door bijvoorbeeld STP, MSTP, OSPF of BGP een beetje in de war te laten raken.

Jammer dat bijvoorbeeld ATM duur is in vergelijking met Ethernet.

[Echron]

Zoals ik het lees is het puur bedoeld om de communicatie tussen bv routers te optimaliseren zodat er meer "plaats" vrij is voor andere communicatie.

Zorgt dit niet voor vertragen wanneer bijvoorbeeld een apparaat wegvalt?

[bigbadbull]

Voor zo ver ik mij dit kan voorstellen is het vooral het aanpakken van broadcast.
bvb pc, maar ook netwerk printers hebben de neiging om op geregelde tijdstippen te zeggen "hallo ik ben hier" Door deze communicatie te negeren, doe je bijna niets af van de echte functionaliteit van het netwerk.
Nu als je 1 netwerk segmentje hebt op 100MB is dit niet zo erg.
Maar bij de grote gecombineerde netwerken kan dit problematisch worden.
Za had een klant van ons een aantal jaren geleden het lumineus idee om maar 1 bedrijfsnetwerk te willen (op zich logisch natuurlijk) echter het is wel een multinational.
Hun service provider heeft dit perfect naar hun wens uitgevoerd waardoor broadcasts van Chinese printer ook in Europa en Amerika toekomen.

Wij hadden ondertussen een RF applicaties lopen over 811.1 (max 11mbps bij optimaal ontvangst)
Met gevolg dat al die "stomme" broadcast het RF verkeer stoorde.

Via een packet filter werd dan dan properder opgelost.

[matthijsberg]

Braodcast kan idd een probleem worden, maar zoals je zelf al aangeeft blijft broadcast verkeer altijd binnen een netwerksegment (broadcast domain)

Aangezien routers tussen netwerksegementen routeren ontvangen ze het wel, maar negeren ze het volledig. Alleen layer twee geeft broadcast door (MPLS bijvoorbeeld).

[Jaco69]

Als je buiten je eigen segment broadcast (naar een ander segment of naar een super segment) dan wordt dat volgens mij ook gerouteerd op IP niveau.

[Verwijderd]

Klopt, maar veel routers blokkeren tegenwoordig 'directed broadcast' oftewel gerouteerd broadcastverkeer omdat daar veel misbruik mee mogelijk is. Een 'geintje' wat vroeger nog wel eens gebruikt werd is een pakketje versturen met een broadcastadres als afzender, naar een ander broadcast adres. Gevolg was dat alle hosts op het tweede netwerk een antwoord gaan sturen naar het eerste netwerk, waar, als je het handig bekeken had, alle hosts op het eerste netwerk weer gaan antwoorden, gevolg: gigantische hoeveelheid verkeer terwijl je zelf maar 1 pakketje verstuurd hebt.

[Verwijderd]

Broadcast verkeer word standaard bij de meeste routingprotocollen(ospf rip eigrp) al genegeerd. Wel word er bij ospf en eigrp een soort van plaatje gemaakt van het netwerk. Maar hier worden dan alleen de routers in opgenomen met de bijbehorende netwerken. Dus niet precies welke host's er in een netwerk zitten. Ook moeten deze routers eerst aan een routingprotocoldomein toegevoegd worden voordat ze werken.

[bigbadbull]

Als je alles in 1 domein en netwerk wilt smijten (zoals ook letterlijk gevraagd was) dan komen de broadcast ook overal door.
Dat nam ik de provider vooral kwalijk dat ze het zo letterlijk uitgevoerd hebben en dan nog alles keihard te ontkennen.

Na wat keiharde bewijzen op tafel te leggen en de verantwoordelijke eindelijk schuld te bekennen, hebben ze het eindelijk toch aangepast.