Network Collisions???

vrijdag 15 maart 2002 15:36

Ja, ik ben pluizig en blauw!

Op vrijdag 15 maart 2002 13:04 schreef Kabouterplop01 het volgende:
Hey guys,
Dont worry, Je moet maar eens de defenitie bekijken van wat Ethernet betekent; CSMACD (carrier sense multiple acces with COLLIsion detection) het hele principe van ethernet is hierop gebaseerd! Ik weet niet of je je servertje uitzet (Ik niet i.i.g.) maar je servertje browst door het netwerk om te kijken waar jouw netwerkomgeving uit bestaat... (Multicast!) Als jouw server dan geen pc tegenkomt die antwoord, waar moeten die pakketjes dan heen...(naar de collision led.)

Wuh? Omdat er geen PC antwoord gaat het collision-LEDje aan op die switch? Ik zou inderdaad de WERKING van CSMA/CD eens ff doornemen, want wat je nu verkondigt is verre van waar.

... en oranje! :P

Acties:

Verwijderd

begin dan eens met het omdraaien van twee kabels op de switch, dan weet je gouw genoeg of het iets met de switch temaken heeft of niet.

vrijdag 15 maart 2002 18:01

Acties:

Verwijderd

Topicstarter

ik heb het gisteren nog is ff getest, en hier zijn mijn conclusies...

Als ik alle pc's opstart, geen collisions.
Als ik van pc A naar pc B een file doorstuur, geef pc A collisions aan, (A = 10mbit, B = 100mbit).
Als ik alle pc's afzet, geeft pc B collisions aan.
Ook heb ik de kabel van pc B al is verstoken, en het collisins ledje, verplaatst zich mee naar waar ik de kabel verplaatst heb.

vrijdag 15 maart 2002 18:07

Acties:

kwtemp874

bij mij weten heb je op 2 pc's met een crosslink nog collisions.

Zou me er maar niet al te druk om maken.

Toevallig netbeui ook geinstalleerd?

dinsdag 19 maart 2002 09:45

Acties:

Verwijderd

Topicstarter

nope no Netbeui...

dinsdag 19 maart 2002 10:40

Acties:

dinsdag 19 maart 2002 10:55

Op vrijdag 15 maart 2002 18:07 schreef kwtemp het volgende:
bij mij weten heb je op 2 pc's met een crosslink nog collisions.

Dan is er toch echt iets mis. Met een crosslink kun je full duplex werken en met full duplex heb je nooit collisions, omdat het een point to point verbinding is met gescheiden receive en transmit kanalen.

Acties:

dinsdag 19 maart 2002 12:28

Op vrijdag 15 maart 2002 18:01 schreef BigKahuna het volgende:
ik heb het gisteren nog is ff getest, en hier zijn mijn conclusies...

Als ik alle pc's opstart, geen collisions.
Als ik van pc A naar pc B een file doorstuur, geef pc A collisions aan, (A = 10mbit, B = 100mbit).
Als ik alle pc's afzet, geeft pc B collisions aan.
Ook heb ik de kabel van pc B al is verstoken, en het collisins ledje, verplaatst zich mee naar waar ik de kabel verplaatst heb.

Ik heb 1 collision ledje en 8 partition ledjes. Heb jij per poort een collision ledje?
Ik denk dat of de kabel of de netwerkkaart kapot is.

Acties:

Verwijderd

Op dinsdag 19 maart 2002 10:40 schreef OlafvdSpek het volgende:

[..]

Dan is er toch echt iets mis. Met een crosslink kun je full duplex werken en met full duplex heb je nooit collisions, omdat het een point to point verbinding is met gescheiden receive en transmit kanalen.

dus?
zoals je zelf al zegt KAN je met full duplex werken!!!

dinsdag 19 maart 2002 12:32

Acties:

dinsdag 19 maart 2002 21:10

Zoals jij het zei leek het alsof je altijd collisions zou kunnen hebben, dus altijd half duplex zou gebruiken.

Maar waarom zou je half duplex gebruiken? Volgens mij heb je trouwens zelfs bij half duplex geen collisions, omdat je nog steeds met gescheiden kanalen werkt. Of wordt bij half-duplex maar een kanaal gebruikt?

Acties:

Jaap-Jan

Als er een network collision- lampje zit op een switch, ben je dan niet ge****? Immers, alleen een HUB kan een collision geven, een switch nooit.

Quote uit de netwerk FAQ:
Aangezien al deze zaken er voor zorgden dat grote netwerken meer bezig waren met Collisions te genereren dan daadwerkelijk data te versturen, ( ) heeft men de Switch ontwikkeld.
De Switch is meer dan een dom apparaat die de data gewoon naar alle poorten kopieert, een Switch gaat namelijk als eerste als hij aangezet wordt, adressen leren. Hij kijkt naar het MAC-adres van het aangesloten apparaat op een bepaalde poort, en slaat dit op in een intern geheugen. (Dat verdwijnt als de Switch uit gaat.)

| Last.fm | "Mr Bent liked counting. You could trust numbers, except perhaps for pi, but he was working on that in his spare time and it was bound to give in sooner or later." -Terry Pratchett

dinsdag 19 maart 2002 21:12

Acties:

dinsdag 19 maart 2002 23:11

Suffers from split brain

Op dinsdag 19 maart 2002 21:10 schreef Japie_17 het volgende:
Als er een network collision- lampje zit op een switch, ben je dan niet ge****? Immers, alleen een HUB kan een collision geven, een switch nooit.
[..]

Een switch op half duplex kan wel collisions geven hoor.
Als je data langs 2 poorten naar elkaar stuurt.
Maar normaal gebruik je die op full en heb je indd geen collisions.

Everybody lies | BFD rocks ! | PC-specs

Acties:

woensdag 20 maart 2002 10:29

Ja, ik ben pluizig en blauw!

Op dinsdag 19 maart 2002 21:12 schreef Predator het volgende:

[..]

Een switch op half duplex kan wel collisions geven hoor.
Als je data langs 2 poorten naar elkaar stuurt.
Maar normaal gebruik je die op full en heb je indd geen collisions.

Je snapt zijn quote niet.

Als er een _NETWORK_ collision-LEDje op je switch zit (dus niet per poort, maar gewoon een indicatie dat er ergens op de switch een NETWORK-collision voordoet), dan ben je genaaid.

... en oranje! :P

Acties:

Verwijderd

Topicstarter

ik heb per verbinding een collision ledje...

woensdag 20 maart 2002 10:37

Acties:

Dark

who tweaked the light?

Ik heb hier een edimax switch voor m'n neus staan, daar betekent het collision(1 per verb.) ledje tevens full-duplex. Het brandt dus altijd als het plugje er goed inzit. Ook als de pc's uit staan blijft het col/fdx ledje branden op de aangesloten poorten...

woensdag 20 maart 2002 11:04

Acties:

woensdag 20 maart 2002 11:38

Op dinsdag 19 maart 2002 21:12 schreef Predator het volgende:

[..]

Een switch op half duplex kan wel collisions geven hoor.
Als je data langs 2 poorten naar elkaar stuurt.
Maar normaal gebruik je die op full en heb je indd geen collisions.

Waarom kan een switch in half-duplex mode werken?
En ik snap nog steeds niet waar in half-duplex die collision dan vandaan komt. Als je data naar elkaar stuurt dropt de switch de helft van de packets volgens mij gewoon, aangenomen dat beide dezelfde max bandbreedte hebben en die ook proberen te gebruiken.

Acties:

woensdag 20 maart 2002 14:58

Suffers from split brain

Op woensdag 20 maart 2002 11:04 schreef OlafvdSpek het volgende:

[..]

Waarom kan een switch in half-duplex mode werken?
En ik snap nog steeds niet waar in half-duplex die collision dan vandaan komt. Als je data naar elkaar stuurt dropt de switch de helft van de packets volgens mij gewoon, aangenomen dat beide dezelfde max bandbreedte hebben en die ook proberen te gebruiken.

Hier komt het vandaan:
vb poort 1 pc1 en poort 2 pc2
PC1 stuurt een ethernet frame naar PC2 en PC2 stuurt tegelijk een frame naar PC1.
Bij full duplex geen probleem bij half wel.
Dan heb je een collision net zoals je de 2 pc's met een cross cable op half duplex zou verbinden.

Collisions zijn eigen aan de logische bus topology van ethernet en omdat ethernet collision detection gebruikt en niet collision avoidance.

Als de switch het packet zou droppen weet de nic zelf niet dat er collision gebeurt is en dat zijn frame de mist ingegaan is.

Everybody lies | BFD rocks ! | PC-specs

Acties:

woensdag 20 maart 2002 15:28

Ja, ik ben pluizig en blauw!

Op woensdag 20 maart 2002 11:38 schreef Predator het volgende:

[..]

Hier komt het vandaan:
vb poort 1 pc1 en poort 2 pc2
PC1 stuurt een ethernet frame naar PC2 en PC2 stuurt tegelijk een frame naar PC1.
Bij full duplex geen probleem bij half wel.
Dan heb je een collision net zoals je de 2 pc's met een cross cable op half duplex zou verbinden.

Predator, jammer!

Ik heb een tijd met ontzag diverse van je postings gelezen, in de veronderstelling dat je aardig wat netwerkkennis hebt. Helaas houdt dat nu op, gezien het feit wat je nu beweert.

Switches zijn collision-domain scheiders. Indien 2 poorten in een VLAN op éénzelfde switch beide op half-duplex staan, zitten ze toch beiden in een eigen collision-domain. Wat jij dus beweert over een collision op een switch, klopt niet. Deze elementaire kennis wordt je aangesmeerd tijdens een Cisco ICND cursus.

Overigens is dit geen personal flame, meer een verbaasde reactie dat dit uit jouw knoppenbord moet komen! (Eigenlijk dus indirect een compliment naar je, maar niet over deze posting)

... en oranje! :P

Acties:

woensdag 20 maart 2002 15:35

Suffers from split brain

Op woensdag 20 maart 2002 14:58 schreef iNSaNe-oNe het volgende:

[..]

Predator, jammer!
Ik heb een tijd met ontzag diverse van je postings gelezen, in de veronderstelling dat je aardig wat netwerkkennis hebt. Helaas houdt dat nu op, gezien het feit wat je nu beweert.

Switches zijn collision-domain scheiders. Indien 2 poorten in een VLAN op éénzelfde switch beide op half-duplex staan, zitten ze toch beiden in een eigen collision-domain. Wat jij dus beweert over een collision op een switch, klopt niet. Deze elementaire kennis wordt je aangesmeerd tijdens een Cisco ICND cursus.

Overigens is dit geen personal flame, meer een verbaasde reactie dat dit uit jouw knoppenbord moet komen! (Eigenlijk dus indirect een compliment naar je, maar niet over deze posting)

Kijk, we zullen er over discussieren:
Switch zijn indd collision domein scheiders en dit altijd.
Ofwel:
Collisions in een domein dat verbonden is op een poort doen zich niet voor op andere domeinen en verstoren hier het netwerk verkeer niet.

Collision Domain (LAN Segment)
A part of a LAN where data transmitted on it is broadcast to all of the devices on that segment but not to devices on another segment. Each segment may contain a single server or workstation, or multiple workstations that are connected to a hub. In the latter case two or more workstations can broadcast messages simultaneously, hence, the messages collide. That segment is a 'collision domain.' (The Ethernet protocol sorts this problem out with random timing rules for each workstation to re-broadcast its message.)

Maar het gaat hier ook niet over collisions in netwerken aan de switch maar over een collision op de bridge verbinding ertussen.

Kijk (half duplex):
poort 1 stuurt naar poort 2 en tegelijk ook omgekeerd.
Wat gaat je switch doen:
Er zijn volgens mij maar 2 mogelijkheden:
A) 1 van de 2 droppen

1 in wacht buffer plaatsen en dan doorsturen

Bij A weet de andere kant niet dat zijn frame verdwenen is.
Met een collision weet ie wel dat zijn packet om zeep is kan ie het opnieuw sturen.
Bij B: niet alle switchen steken het gehele packen in een buffer

Bv Cut-through switches

Cut-through switches read the MAC address as soon as a packet is detected by the switch. After storing the six bytes that make up the address information, they immediately begin sending the packet to the destination node, even as the rest of the packet is coming into the switch.

Dus kan ie het niet in wacht zetten.

Everybody lies | BFD rocks ! | PC-specs

Acties:

BitProcessor

Op woensdag 20 maart 2002 14:58 schreef iNSaNe-oNe het volgende:

[..]

Predator, jammer!
Ik heb een tijd met ontzag diverse van je postings gelezen, in de veronderstelling dat je aardig wat netwerkkennis hebt. Helaas houdt dat nu op, gezien het feit wat je nu beweert.

Nope, toch niet !
Predator GOOOO !
Hij heeft wel degelijk gelijk. Wat jij hierboven zegt van die VLAN's doet totaal niet terzake.
Je hebt gelijk dat switches geen collisions doorgeven op alle poorten (wat een hub wel doet).

Maar als twee nic's op half duplex via eenzelfde switch verbonden zijn, kunnen er wel degelijk collisions optreden. Waarom, gewoon omdat halfduplex gebruikt maakt van CSMA/CD en er daarbij collissions kunnen optreden, die MOETEN kunnen opgemerkt worden door de twee communicerende nics.

Bijkomend voorbeeldje :

code:

1 2	HUB1 ---- SWITCH ---- HUB2 HUB3 -------\|

Stel dat een nic die op hub1 zit aan het communiceren is met een nic op hub2 en er treedt ergens een collision op, dan zal die switch dat op de poort van hub1 en 2 doorgeven, wat hij natuurlijk niet doet is het ook doorgeven op de poort waar hub3 op zit. Op die manier krijg je inderdaad verschillende collisiondomeinen.

Switches die vlan-tagging aankunnen zijn nog iets anders. Met VLANning kan je bijvoorbeeld aangeven dat bepaalde poorten op die switch meer bandbreedte moeten krijgen oid...

"I think there is a world market for maybe five computers" - Thomas Watson, chairman of IBM, 1943

woensdag 20 maart 2002 16:15

Acties:

woensdag 20 maart 2002 16:20

Op woensdag 20 maart 2002 14:58 schreef iNSaNe-oNe het volgende:

[..]

Predator, jammer!
Ik heb een tijd met ontzag diverse van je postings gelezen, in de veronderstelling dat je aardig wat netwerkkennis hebt. Helaas houdt dat nu op, gezien het feit wat je nu beweert.

Switches zijn collision-domain scheiders. Indien 2 poorten in een VLAN op éénzelfde switch beide op half-duplex staan, zitten ze toch beiden in een eigen collision-domain. Wat jij dus beweert over een collision op een switch, klopt niet. Deze elementaire kennis wordt je aangesmeerd tijdens een Cisco ICND cursus.

Overigens is dit geen personal flame, meer een verbaasde reactie dat dit uit jouw knoppenbord moet komen! (Eigenlijk dus indirect een compliment naar je, maar niet over deze posting)

Maar wat is het verschil tussen half- en full-duplex dan?
Bij half-duplex voert een node CS uit, maar met een dedicated link (cross-cable of switch), detecteert die nooit een actieve andere node en kan dus altijd gelijk zenden.

Acties:

woensdag 20 maart 2002 16:22

Op woensdag 20 maart 2002 15:35 schreef G8KeePeR het volgende:
Je hebt gelijk dat switches geen collisions doorgeven op alle poorten (wat een hub wel doet).

Maar als twee nic's op half duplex via eenzelfde switch verbonden zijn, kunnen er wel degelijk collisions optreden.

Ah, daar wordt half-duplex dus gebruikt.

Stel dat een nic die op hub1 zit aan het communiceren is met een nic op hub2 en er treedt ergens een collision op, dan zal die switch dat op de poort van hub1 en 2 doorgeven, wat hij natuurlijk niet doet is het ook doorgeven op de poort waar hub3 op zit. Op die manier krijg je inderdaad verschillende collisiondomeinen.

Volgens mij geeft die dat alleen door bij een cut-through transactie. Als het een store/forward transactie is hoeft de collision naar hub 2 niet te worden doorgegeven.

Acties:

woensdag 20 maart 2002 16:30

Op woensdag 20 maart 2002 15:28 schreef Predator het volgende:
Dus kan ie het niet in wacht zetten.

Kan wel, bijvoorbeeld als de out-link in gebruik is.

Acties:

woensdag 20 maart 2002 16:36

Ja, ik ben pluizig en blauw!

Op woensdag 20 maart 2002 15:28 schreef Predator het volgende:

[...]
Maar het gaat hier ook niet over collisions in netwerken aan de switch maar over een collision op de bridge verbinding ertussen.

Kijk (half duplex):
poort 1 stuurt naar poort 2 en tegelijk ook omgekeerd.
Wat gaat je switch doen:
Er zijn volgens mij maar 2 mogelijkheden:
A) 1 van de 2 droppen
1 in wacht buffer plaatsen en dan doorsturen

Bij A weet de andere kant niet dat zijn frame verdwenen is.
Met een collision weet ie wel dat zijn packet om zeep is kan ie het opnieuw sturen.
Bij B: niet alle switchen steken het gehele packen in een buffer

Bv Cut-through switches
[..]

Dus kan ie het niet in wacht zetten.

Hij zal inderdaad niet het pakket storen in zijn buffer bij Cut-through switching, maar zoals je zelf schrijft: als hij inderdaad de eerste 6 bytes ontvangen heeft zal hij meteen beginnen met forwarden naar de destination port, terwijl hij inderdaad nog bezig is met het ontvangen van de rest van het frame. Indien op de destination port al een carrier aanwezig is (lijn bezet, dus zenden niet mogelijk zonder een collision te genereren), dan genereert de switch op de SOURCE-port (waarop het frame dus binnenkomt) alsnog een error (collision). Dat forceert de zendende partij om alsnog een poging te wagen.

Je hebt dus gelijk, voor het geval dat cut-through switching aan staat op switches, in plaats van store-and-forward of fragment-free.

Zo genoeg gebitw*pt. Zijn we het nu met elkaar eens?

... en oranje! :P

Acties:

woensdag 20 maart 2002 16:42

Ja, ik ben pluizig en blauw!

Op woensdag 20 maart 2002 15:35 schreef G8KeePeR het volgende:

[...]

Maar als twee nic's op half duplex via eenzelfde switch verbonden zijn, kunnen er wel degelijk collisions optreden. Waarom, gewoon omdat halfduplex gebruikt maakt van CSMA/CD en er daarbij collissions kunnen optreden, die MOETEN kunnen opgemerkt worden door de twee communicerende nics.

Nee, tussen de NIC's op de end-hosts en de switch die ertussen zit.

Switches die vlan-tagging aankunnen zijn nog iets anders. Met VLANning kan je bijvoorbeeld aangeven dat bepaalde poorten op die switch meer bandbreedte moeten krijgen oid...

Ik had het over end-hosts verbonden aan un-tagged ports op een switch in het zelfde VLAN op die switch. Jij bedoelt trunks of tagged ports tussen switches onderling. Da's weer wat anders.

... en oranje! :P

Acties:

woensdag 20 maart 2002 16:57

Ja, ik ben pluizig en blauw!

Op woensdag 20 maart 2002 16:15 schreef OlafvdSpek het volgende:

[..]

Maar wat is het verschil tussen half- en full-duplex dan?
Bij half-duplex voert een node CS uit, maar met een dedicated link (cross-cable of switch), detecteert die nooit een actieve andere node en kan dus altijd gelijk zenden.

Half-duplex wordt gebruikt op een shared medium, of point-to-point verbindingen. Hierbij kunnen dus meerdere hosts op een fysieke bus zitten, maar ook tussen end-hosts en switches. Dit kan in principe altijd gebruikt worden (mits alle aangesloten apparatuur dezelfde setting gebruikt, anders duplex-mismatches met ellende van dien).

Full-duplex kan alléén gebruikt worden op point-to-point verbindingen, maar niet op shared mediums (voorbeeld: inderdaad via gewone kabel tussen end-host en switch, cross-cable tussen end-host en end-host, maar niet een kabel tussen end-host en HUB omdat een HUB per definitie half-duplex praat).

Is het duidelijker zo?

... en oranje! :P

Acties:

woensdag 20 maart 2002 17:03

Nee. Ik snap nog steeds het verschil tussen half- en full-duplex op een dedicated link niet.

Acties:

woensdag 20 maart 2002 17:10

Ja, ik ben pluizig en blauw!

Op woensdag 20 maart 2002 16:57 schreef OlafvdSpek het volgende:
Nee. Ik snap nog steeds het verschil tussen half- en full-duplex op een dedicated link niet.

Ik begrijp dat je met 'dedicated link' een point-to-point verbinding bedoelt? Ff duidelijk hebben

half-duplex: end-host <--> end-host of switch/hub zouden tegelijkertijd kunnen praten. Collisions zijn dus mogelijk. Er moet dus wel degelijk geluisterd worden of de lijn vrij is.

full-duplex: end-host <--> end-host of switch hebben beiden gescheiden send/receive kanalen, die altijd vrij zijn. Er hoeft dus niet aan CS gedaan te worden, collisions niet mogelijk.

NU duidelijk?

... en oranje! :P

Acties:

woensdag 20 maart 2002 17:16

Suffers from split brain

Op woensdag 20 maart 2002 16:30 schreef iNSaNe-oNe het volgende:

[..]

Hij zal inderdaad niet het pakket storen in zijn buffer bij Cut-through switching, maar zoals je zelf schrijft: als hij inderdaad de eerste 6 bytes ontvangen heeft zal hij meteen beginnen met forwarden naar de destination port, terwijl hij inderdaad nog bezig is met het ontvangen van de rest van het frame. Indien op de destination port al een carrier aanwezig is (lijn bezet, dus zenden niet mogelijk zonder een collision te genereren), dan genereert de switch op de SOURCE-port (waarop het frame dus binnenkomt) alsnog een error (collision). Dat forceert de zendende partij om alsnog een poging te wagen.

Je hebt dus gelijk, voor het geval dat cut-through switching aan staat op switches, in plaats van store-and-forward of fragment-free.

Zo genoeg gebitw*pt. Zijn we het nu met elkaar eens?

nog ff

Bij fragment free slaat ie enkel de eerste 64bytes op waar het dus weer op hetzelfde als cut-through neerkomt.

Neem dan nu even store en forward aan.
Switch wacht tot lijn vrij is en zend dan het frame naar de andere kant. Echter de andere kant wil nu ook tegelijk zenden.
Ze voeren beide CS uit en lijn is vrij.
Dan sturen ze beide op de lijn.
Lijkt mij toch ook collision te geven dan.
De switch kan het dan later nog ff proberen.
Maar volgens mij heb dan nog steeds een collision gehad.

Everybody lies | BFD rocks ! | PC-specs

Acties:

woensdag 20 maart 2002 17:28

Op woensdag 20 maart 2002 17:03 schreef iNSaNe-oNe het volgende:

[..]

Ik begrijp dat je met 'dedicated link' een point-to-point verbinding bedoelt? Ff duidelijk hebben

half-duplex: end-host <--> end-host of switch/hub zouden tegelijkertijd kunnen praten. Collisions zijn dus mogelijk. Er moet dus wel degelijk geluisterd worden of de lijn vrij is.

Hoe zit dat dan in een UTP kabel? Ik dacht dat je daar een ader voor transmit, een voor receive, twee voor aarde en vier ongebruikt had? Hoe wordt dat met half-duplex dan gebruikt?

Acties:

woensdag 20 maart 2002 17:35

Ja, ik ben pluizig en blauw!

Op woensdag 20 maart 2002 17:10 schreef Predator het volgende:

[..]

nog ff
Bij fragment free slaat ie enkel de eerste 64bytes op waar het dus weer op hetzelfde als cut-through neerkomt.

Hmm, bijna. Fragment-free staat ook bekend als 'modified cut-through'. Collisions treden voor 99% op in de eerste 64 bytes. Als die eerste 64 bytes goed zijn binnen gekomen kan men er vanuit gaan dat de rest ook goed zal gaan.

Neem dan nu even store en forward aan.
Switch wacht tot lijn vrij is en zend dan het frame naar de andere kant. Echter de andere kant wil nu ook tegelijk zenden.
Ze voeren beide CS uit en lijn is vrij.
Dan sturen ze beide op de lijn.
Lijkt mij toch ook collision te geven dan.
De switch kan het dan later nog ff proberen.
Maar volgens mij heb dan nog steeds een collision gehad.

Klopt, alleen niet op beide collision-domains, maar slechts op ééntje. De originele zender waarvan het frame dus ontvangen en opgeslagen is op de switch hoeft het niet nogmaals te zenden, dat doet de switch wel voor hem.

... en oranje! :P

Acties:

woensdag 20 maart 2002 17:39

Ja, ik ben pluizig en blauw!

Op woensdag 20 maart 2002 17:16 schreef OlafvdSpek het volgende:
[..]

Hoe zit dat dan in een UTP kabel? Ik dacht dat je daar een ader voor transmit, een voor receive, twee voor aarde en vier ongebruikt had? Hoe wordt dat met half-duplex dan gebruikt?

Bij half-duplex kan de NIC slechts één ding tegelijk. OF luisteren (als in: luisteren of de lijn vrij is of frames receiven op de Rx+ en Rx- aders), OF transmitten (als in: op de Tx+ en Tx- aders frames senden), maar niet tegelijk (half <> heel, één van de twee).

Bij full-duplex kan de NIC beide zaken tegelijk. Dit kan dus alléén als er tussen twee componenten gebabbeld word (point-to-point). Gescheiden send- en receivekanalen dus.

Een derde netwerkcomponent op dezelfde lijn zou deze logica verstoren. Daarom kan full-duplex alleen op point-to-point verbindingen gebruikt worden, op een non-shared medium.

Zo. Wat een verhaal.

... en oranje! :P

Acties:

woensdag 20 maart 2002 17:54

Suffers from split brain

Op woensdag 20 maart 2002 17:28 schreef iNSaNe-oNe het volgende:

[..]

Hmm, bijna. Fragment-free staat ook bekend als 'modified cut-through'. Collisions treden voor 99% op in de eerste 64 bytes. Als die eerste 64 bytes goed zijn binnen gekomen kan men er vanuit gaan dat de rest ook goed zal gaan.
[..]

Niets bijna.

Hij checkt die 64 bytes op fouten bv door een collision.
Maar die collision is reeds gebeurt in het collision domein aan die kant.
Dat is dan een verneukt frame dat hij binnenkrijgt.
Dat is een collions veroorzaakt door een 3de partij.
De verstuurder heeft dit ook gemerkt een stuurt het dan opnieuw.
Daar gaat het hier niet over.

Klopt, alleen niet op beide collision-domains, maar slechts op ééntje. De originele zender waarvan het frame dus ontvangen en opgeslagen is op de switch hoeft het niet nogmaals te zenden,
dat doet de switch wel voor hem.

Dat heb ik toch ook nooit beweert

Maar nu je er toch over begint:

Nog even terug naar Cut through dan.
Voeg verhaal van store en forward en cut through samen (of fragment-free).
As in:
Collision bij zenden van switch naar andere nic.
Op zelfde manier als ik bij store en forward zei.
Dan heb je daar collision maar de switch heeft het niet in een buffer zitten en dan moet ie aan de andere kant ook collision geven anders is het frame verneukt en heeft de zender het niet opgemerkt.
In principe hoeft ie het niet te doen maar het is beter dat ie het wel doet.

Everybody lies | BFD rocks ! | PC-specs

Acties:

woensdag 20 maart 2002 17:57

Op woensdag 20 maart 2002 17:35 schreef iNSaNe-oNe het volgende:

[..]

Bij half-duplex kan de NIC slechts één ding tegelijk. OF luisteren (als in: luisteren of de lijn vrij is of frames receiven op de Rx+ en Rx- aders), OF transmitten (als in: op de Tx+ en Tx- aders frames senden), maar niet tegelijk (half <> heel, één van de twee).

Bij full-duplex kan de NIC beide zaken tegelijk. Dit kan dus alléén als er tussen twee componenten gebabbeld word (point-to-point). Gescheiden send- en receivekanalen dus. Een derde netwerkcomponent op dezelfde lijn zou deze logica verstoren. Daarom kan full-duplex alleen op point-to-point verbindingen gebruikt worden, op een non-shared medium.

Zo. Wat een verhaal.

In half-duplex moet de NIC tijdens verzenden ook luisteren om collisions op te merken.

Acties:

woensdag 20 maart 2002 18:08

Op woensdag 20 maart 2002 17:39 schreef Predator het volgende:
Nog even terug naar Cut through dan.
Voeg verhaal van store en forward en cut through samen (of fragment-free).
As in:
Collision bij zenden van switch naar andere nic.
Op zelfde manier als ik bij store en forward zei.
Dan heb je daar collision maar de switch heeft het niet in een buffer zitten en dan moet ie aan de andere kant ook collision geven anders is het frame verneukt en heeft de zender het niet opgemerkt.
In principe hoeft ie het niet te doen maar het is beter dat ie het wel doet.

Switches die cut-through ondersteunen ondersteunen store/forward toch ook (voor het geval de out-link bezig is)?

Acties:

woensdag 20 maart 2002 18:45

Suffers from split brain

Op woensdag 20 maart 2002 17:57 schreef OlafvdSpek het volgende:

[..]

Switches die cut-through ondersteunen ondersteunen store/forward toch ook (voor het geval de out-link bezig is)?

In principe niet.
Vaak kunnen ze beide.
Het is niet nodig want het is peer-2-peer.
Als de ene kant bezig is, dan is ie aan het zenden.
Dan is de andere kant aan het ontvangen.
Die gaat dan ook niet beginnen met zenden.

Everybody lies | BFD rocks ! | PC-specs

Acties:

woensdag 20 maart 2002 19:03

Ja, ik ben pluizig en blauw!

Op woensdag 20 maart 2002 schreven

- Predator,
- iNSaNe-oNe
en
- OlafvdSpek

een heel verhaal.

[..]

Heren, we snappen het allemaal wel, alleen praten we soms langs elkaar heen heb ik alweer gemerkt (zeker ook door mijn eigen schuld). Interessant is het zeker wel.

Alleen, voor de topicstarter levert dit verhaal over forwarding-methodes niet bijzonder veel op.

Vreemd blijft het zeker, BigKahuna. Heb je inmiddels zelf al een verklaring gevonden voor je rare probleem, of leer je ermee leven? Of heb je liever dat we doorbomen over techniekjes?

... en oranje! :P

Acties:

donderdag 21 maart 2002 12:22

Suffers from split brain

Op woensdag 20 maart 2002 18:45 schreef iNSaNe-oNe het volgende:

[..]

Heren, we snappen het allemaal wel, alleen praten we soms langs elkaar heen heb ik alweer gemerkt (zeker ook door mijn eigen schuld). Interessant is het zeker wel.

Alleen, voor de topicstarter levert dit verhaal over forwarding-methodes niet bijzonder veel op.

Nu geef je wel volledig gelijk

Eens discussiëren vind ik erg leuk maar we moeten indd ooit es gaan stoppen anders zijn we volgende week nog bezig.

Vreemd blijft het zeker, BigKahuna. Heb je inmiddels zelf al een verklaring gevonden voor je rare probleem, of leer je ermee leven? Of heb je liever dat we doorbomen over techniekjes?

Volgens mij is the BigKahuna al terug naar Hawai om met halfnaakte meisjes met strooien rokjes te spelen

Everybody lies | BFD rocks ! | PC-specs

Acties:

donderdag 21 maart 2002 12:29

Op woensdag 20 maart 2002 18:08 schreef Predator het volgende:

[..]

In principe niet.
Vaak kunnen ze beide.
Het is niet nodig want het is peer-2-peer.
Als de ene kant bezig is, dan is ie aan het zenden.
Dan is de andere kant aan het ontvangen.
Die gaat dan ook niet beginnen met zenden.

Daar snap ik niks van. Het kan toch heel goed zijn dat twee clients naar een server iets sturen op hetzelfde moment?
En cut-through is toch alleen handig op links met kleine load? Het lijkt me dat store/forward altijd ondersteund wordt, anders krijg je wel erg veel drops/collisions in een druk netwerk.

Je hebt store/forward ook nodig als de port speeds niet hetzelfde zijn.

Acties:

Verwijderd

Topicstarter

idd, en ik ben juist terug, argh that was nice

...
Nee ff serieus nu, k ben nogal een vrij druk bezet iemand...
k ga al die zaken ne keer uitproberen, vanavond als'k tijd heb, maar anders van't weekend... i'll keep you guys posted... dus eerst volgende antwoord van mij zal pas van't weekend zijn peins ik, mor ik hem echt genen tijd om het vroeger na te kijken...

BTW i like the discussions, daar steekt nog iets van op,...

donderdag 21 maart 2002 19:48

Acties:

vrijdag 22 maart 2002 10:19

Suffers from split brain

Op donderdag 21 maart 2002 12:22 schreef OlafvdSpek het volgende:

[..]

Daar snap ik niks van. Het kan toch heel goed zijn dat twee clients naar een server iets sturen op hetzelfde moment?
En cut-through is toch alleen handig op links met kleine load? Het lijkt me dat store/forward altijd ondersteund wordt, anders krijg je wel erg veel drops/collisions in een druk netwerk.

Je hebt store/forward ook nodig als de port speeds niet hetzelfde zijn.

Je hebt ook nog flow control.

Ik ben het even aan het opzoeken:

If a faulty piece of equipment creates a lot of error frames on a network segment, store-and-forward mode is probably the best choice, because buffering the whole frame prior to transmission allows the frame check sequence to be verified, meaning that only good frames will be forwarded. If only a small number of error frames are seen, cut-through forwarding is preferable because of the very low latency. And if many collisions occur on a segment, fragment-free may be the forwarding mode of choice because it will prevent collision fragments from consuming network bandwidth on other segments.

Op veel switches kan je de forward mode instellen.
Manueel. Sommige dus het ook automatisch naar gelang wat het beste op dat moment is.
Ik heb na lang zoeken toch een switch gevonden die geen helemaal ook geen store and forward doet. Maar aangezien je op veel andere het zelf kan instellen is het dus ook geen vereiste.

Maar ik begin nu zelf te twijfelen ook

Aangezien ik gelezen heb dat je met cut through geen gemengde snelheden kunt hebben en terwijl die switch in mijn link toch echt wel duidelijk zegt dat ie enkel fragment free toepast en toch kan 10/100 mengen

Fragment free is in principe ook cut through.
Dus dat is tegenstrijdig.

Er is dus errug weining te vinden over de exacte interne werking van een switch online

Everybody lies | BFD rocks ! | PC-specs

Acties:

Weppel

Jullie 3 zijn sapdrinkenderwijs goed bezig!

vrijdag 22 maart 2002 16:17

Acties:

vrijdag 22 maart 2002 16:40

Op donderdag 21 maart 2002 19:48 schreef Predator het volgende:
Je hebt ook nog flow control.

Oh ja? Bedoel je TCP flow control of iets anders?

Op veel switches kan je de forward mode instellen.
Manueel. Sommige dus het ook automatisch naar gelang wat het beste op dat moment is.
Ik heb na lang zoeken toch een switch gevonden die geen helemaal ook geen store and forward doet. Maar aangezien je op veel andere het zelf kan instellen is het dus ook geen vereiste.

Zijn ze dat niet gewoon vergeten er bij te zetten?

Maar ik begin nu zelf te twijfelen ook
Aangezien ik gelezen heb dat je met cut through geen gemengde snelheden kunt hebben en terwijl die switch in mijn link toch echt wel duidelijk zegt dat ie enkel fragment free toepast en toch kan 10/100 mengen
Fragment free is in principe ook cut through.
Dus dat is tegenstrijdig.

Er is dus errug weining te vinden over de exacte interne werking van een switch online

Jammer genoeg wel, daarom zijn we nog steeds aan het discussieren ;->

Wat denk jij dan dat een cut-through switch doet als er twee packets binnenkomen voor dezelfde out-link? Een packet droppen?

Acties:

vrijdag 22 maart 2002 17:05

Suffers from split brain

Op vrijdag 22 maart 2002 16:17 schreef OlafvdSpek het volgende:

[..]

Oh ja? Bedoel je TCP flow control of iets anders?
[..]

Nee flow control voor ethernet.
Er bestaat zoals als back pressure wat een fake collision maakt om het netwerk te laten wachten
Maar ook iets al een wait packet oid (ethernet 80xxx dinges)

Zijn ze dat niet gewoon vergeten er bij te zetten?
[..]

Misschien wel maar bij de paar andere switchen die ze hebben staat het wel vermeld.

Jammer genoeg wel, daarom zijn we nog steeds aan het discussieren ;->

indd

Standaard uitleg over switches geen probleem maar als je nu echt even de interne werking in detail wilt opzoeken -> noppes

Wat denk jij dan dat een cut-through switch doet als er twee packets binnenkomen voor dezelfde out-link? Een packet droppen?

Volgens mij gaat die switch sequentieel gaan bekijken.
De macs opslaan, eerste opzoeken en link leggen, 2de opzoeken, in gebruik, en dan collision maken op die 2de.

Maar ik ben er hoegenaamd niet zeker van.

Ethernet is niet verplicht foutloos te zijn en mag packets kwijtspelen maar dan komt pas later (bv TCP) aan het licht dat er wat verkeerd is.
Vermits TCP met een window werkt moet je dan een hele hoop packets weer vragen.
Het lijkt mij daarom beter om collision te maken ipv te droppen.
Dan stuurt ie het tenminste opnieuw.
Dan zit je wel met een wachttijd maar dan koelt het ook even af.

Het lijkt mij de beste oplossing maar of het ook zo gedaan wordt

Everybody lies | BFD rocks ! | PC-specs

Acties:

vrijdag 22 maart 2002 17:13

Op vrijdag 22 maart 2002 16:40 schreef Predator het volgende:
Nee flow control voor ethernet.
Er bestaat zoals als back pressure wat een fake collision maakt om het netwerk te laten wachten
Maar ook iets al een wait packet oid (ethernet 80xxx dinges)

Nooit van gehoord. Maar bufferen zou efficienter zijn.

Misschien wel maar bij de paar andere switchen die ze hebben staat het wel vermeld.

Volgens mij gaat die switch sequentieel gaan bekijken.
De macs opslaan, eerste opzoeken en link leggen, 2de opzoeken, in gebruik, en dan collision maken op die 2de.

Dat gebeurd juist parallel en ergens ziet die dat de out-link bezet is. Als het serieel zou gebeuren lijkt het meer op een hub.

Acties:

vrijdag 22 maart 2002 17:53

Suffers from split brain

Op vrijdag 22 maart 2002 17:05 schreef OlafvdSpek het volgende:

[..]

Nooit van gehoord. Maar bufferen zou efficienter zijn.
[..]

Dat gebeurd juist parallel en ergens ziet die dat de out-link bezet is. Als het serieel zou gebeuren lijkt het meer op een hub.

Ik zei sequentieel != serieel

Hij kan er meerdere tegelijk doorsturen en zo maar ik denk ie er maar 1 mac tegelijk kan opzoeken (gaat volgens mij wel enorm snel, veel sneller dan de switch de data doorkrijgt).
Dat lijkt mij een andere grote orde in snelheid.

Maar ik zou er mijn kop niet over verwedden.

Everybody lies | BFD rocks ! | PC-specs

Acties:

vrijdag 22 maart 2002 18:01

Sequentieel is volgens mij wel serieel hoor. Alleen had jij het over de vergelijking serieel en ik over het hele packet serieel.

Omdat het opzoeken een adres in een routing table best lang kan duren (vooral in routers) kan elke poort dit zelf doen in sommige switches/routers.

Acties:

dinsdag 2 april 2002 16:23

Suffers from split brain

Op vrijdag 22 maart 2002 17:53 schreef OlafvdSpek het volgende:
Sequentieel is volgens mij wel serieel hoor. Alleen had jij het over de vergelijking serieel en ik over het hele packet serieel.

Omdat het opzoeken een adres in een routing table best lang kan duren (vooral in routers) kan elke poort dit zelf doen in sommige switches/routers.

Sequentieel is eigenlijk ook serieel yah

Heb je wel gelijk in.

Routers moeten ook meer vergelijken dan alleen gewoon een 6byte waarde.
Ze moeten nog eens al die netmasks bitewise AND'n en ie moet ze ook allemaal aflopen omdat ie de meest specifieke gevonden heeft.
Een switch moet gewoon een waarde opzoeken als ie em vind mag ie stoppen. Maar het kunnen er indd wel errug veel zijn.

Everybody lies | BFD rocks ! | PC-specs

Acties:

Verwijderd

Topicstarter

Het probleem is opgelost, juist voor de big LAN party at my place...

Tnx for your support, all

dinsdag 2 april 2002 19:02

Acties: