Forum » Omrežja in internet » ista ip/mac v LANu
ista ip/mac v LANu
slovencl ::
Kaj se zgodi, ča dam računalniku, ki ga priključim v mrežo isti ip ali isti mac (ali oboje) kot ga ima že nek drug računalnik v mreži. A to pomeni da ne bo dosegljiv noben od teh dveh računalnikov, ali da sploh noben v mreži ne bo dosegljiv, ker se bo switchu sfuzlalo?
fiction ::
Switchu se ne bo "sfuzlalo". Oz. ponavadi zacne samo delovati kot hub in posilja podatke na vse porte v takem primeru.
Ce imata 2 mrezni kartici isti MAC naslov potem bosta pac obe "pobrali" podatke z zice (razen seveda ce switch ze
ve da je dolocen MAC naslov samo na dolocenem "prikljucku" in zato sploh ne bo poslal okvira na vse izhode oz. ga sploh ne bo sprejel
s tistega napacnega porta - kar pa mislim da switchi ne delajo, naceloma namrec lahko ti kabel premaknes iz enega porta v drugega).
Te "pobrane podatke" pa bo najbrz potem jedro zavrglo - ker bo pac IP stack videl da destination IP ni pravilen.
V primeru da imas v mrezi dva enaka IP naslova je pa drugace. Odvisno je od tega kaksen IP -> MAC mapping imas v ARP cachu
na racunalniku oz. ce tega se ni od katere mrezne naprave je dobil tvoj PC prej ARP odgovor. Naceloma bo lahko isti IP za dolocene
racunalnike ena naprava, za druge pa druga in komunikacija bi morala cisto normalno delovati.
Ce imata 2 mrezni kartici isti MAC naslov potem bosta pac obe "pobrali" podatke z zice (razen seveda ce switch ze
ve da je dolocen MAC naslov samo na dolocenem "prikljucku" in zato sploh ne bo poslal okvira na vse izhode oz. ga sploh ne bo sprejel
s tistega napacnega porta - kar pa mislim da switchi ne delajo, naceloma namrec lahko ti kabel premaknes iz enega porta v drugega).
Te "pobrane podatke" pa bo najbrz potem jedro zavrglo - ker bo pac IP stack videl da destination IP ni pravilen.
V primeru da imas v mrezi dva enaka IP naslova je pa drugace. Odvisno je od tega kaksen IP -> MAC mapping imas v ARP cachu
na racunalniku oz. ce tega se ni od katere mrezne naprave je dobil tvoj PC prej ARP odgovor. Naceloma bo lahko isti IP za dolocene
racunalnike ena naprava, za druge pa druga in komunikacija bi morala cisto normalno delovati.
iNN ::
Mislim da ob prvi komunikaciji z določeno postajo switch poslje MAC naslovljene postaje na vse porte, potem pa v tabelo zapiše MAC naslov postaje ki se je oglasila. Sedaj, ce imas dve postaji z istimi MACi, potem se bo verjetno res dogajalo to kot je napisal fiction. Z to razliko, da bo verjetno potem posiljal pakete na dva porta in ne se na vse ostale.
Kar se tice istih IPjev, se mi zdi tezko verjetno da bi delovala komunikacija normalno. IP --> MAC mapping se ustvari na podlagi ARP who-has paketov. In ce na switch prikljucimo postajo z dolocenim IPjem, potem ostale naredijo mapping na ta IP. Ko prikljucimo se drugo z istim IPjem, je maping za njen IP ze narejen vendar ne na njen MAC.
Zanima me pa, kaj bi se zgodilo ce priklucimo postaji z istim IPjem "istocasno"?
Kar se tice istih IPjev, se mi zdi tezko verjetno da bi delovala komunikacija normalno. IP --> MAC mapping se ustvari na podlagi ARP who-has paketov. In ce na switch prikljucimo postajo z dolocenim IPjem, potem ostale naredijo mapping na ta IP. Ko prikljucimo se drugo z istim IPjem, je maping za njen IP ze narejen vendar ne na njen MAC.
Zanima me pa, kaj bi se zgodilo ce priklucimo postaji z istim IPjem "istocasno"?
==
fiction ::
Aja pri tem sem pozabil omeniti, da ARP je samo pri IPv4. IPv6 ima link-local IP naslove, ki dejansko ze vsebujejo MAC naslov in zato
ni treba uporabljati address resolution protocola (ce na mrezi uporabljas take IP-je za komunikacijo).
Drugace imas na voljo NDP (neighbour discovery protocol) - tako da lahko govoris z nekim sosednjim vozliscem preko "globalnega"
IPv6 naslova.
Hm naprava najbrz cacha samo tisti who-has reply, ki ga je sama zahtevala in ne kar enega.
Torej si to glede vecih naprav z istim IP-jem si predstavljam takole:
najprej ima samo X IP 192.168.0.1. Ce recimo A in X ze komunicirata si bo A pac shranil
MAC naslov od X. B je naprava, ki je na mrezi istocasno vendar pa v njen ARP cache ne doda nicesar.
Potem pride Y, ki ima tudi IP 192.168.0.1. Ce hoce A se kaj od 192.168.0.1 bo pac uporabil MAC od X (ki
ga ima shranjenega) in vse bo kul.
Ce bo pa B ali pa C, ki se je na novo prikljucil, hotel govoriti z 192.168.0.1, bo poslal ARP who-has.
X in Y ga bosta sprejela in nanj odgovorila - sedaj je samo vazno od vrstnega reda sprejetja odgovorov na B-ju oz. C-ju
(in moznost da sta oba istocasno odpade). Pomoje bo B uposteval prvi odgovor - pri drugem pa bo rekel
saj imam ze v cachu (stvar me sploh ne briga) - isto kot ce bi mu nekdo hotel podatkniti "spoofan" ARP odgovor.
Ce bi X in Y priklopil istocasno potem bi pa takoj nekdo hotel komunicirati z 192.168.0.1 bi se pac dogajalo isto.
Na ethernetu ne more biti kolizij in nek frame je sigurno oddan malo prej kot drug in zato ga tudi
naprava "ki poslusa" na kablu prej sprejme. B in C si potem shranita vnose v ARP cache in cisto mozno je, da sta ta vnosa
razlicna.
Lahko pa naredis tudi staticne ARP vnose na racunalniku, da preprecis ta nedeterminizem.
ni treba uporabljati address resolution protocola (ce na mrezi uporabljas take IP-je za komunikacijo).
Drugace imas na voljo NDP (neighbour discovery protocol) - tako da lahko govoris z nekim sosednjim vozliscem preko "globalnega"
IPv6 naslova.
Hm naprava najbrz cacha samo tisti who-has reply, ki ga je sama zahtevala in ne kar enega.
Torej si to glede vecih naprav z istim IP-jem si predstavljam takole:
najprej ima samo X IP 192.168.0.1. Ce recimo A in X ze komunicirata si bo A pac shranil
MAC naslov od X. B je naprava, ki je na mrezi istocasno vendar pa v njen ARP cache ne doda nicesar.
Potem pride Y, ki ima tudi IP 192.168.0.1. Ce hoce A se kaj od 192.168.0.1 bo pac uporabil MAC od X (ki
ga ima shranjenega) in vse bo kul.
Ce bo pa B ali pa C, ki se je na novo prikljucil, hotel govoriti z 192.168.0.1, bo poslal ARP who-has.
X in Y ga bosta sprejela in nanj odgovorila - sedaj je samo vazno od vrstnega reda sprejetja odgovorov na B-ju oz. C-ju
(in moznost da sta oba istocasno odpade). Pomoje bo B uposteval prvi odgovor - pri drugem pa bo rekel
saj imam ze v cachu (stvar me sploh ne briga) - isto kot ce bi mu nekdo hotel podatkniti "spoofan" ARP odgovor.
Ce bi X in Y priklopil istocasno potem bi pa takoj nekdo hotel komunicirati z 192.168.0.1 bi se pac dogajalo isto.
Na ethernetu ne more biti kolizij in nek frame je sigurno oddan malo prej kot drug in zato ga tudi
naprava "ki poslusa" na kablu prej sprejme. B in C si potem shranita vnose v ARP cache in cisto mozno je, da sta ta vnosa
razlicna.
Lahko pa naredis tudi staticne ARP vnose na racunalniku, da preprecis ta nedeterminizem.
Zgodovina sprememb…
- spremenil: fiction ()
iNN ::
Ja se popolnoma strinjam z tem kar si napisal, verjetno bi bila potem problem edino komunikacija med napravama z istim IPjem.
Aja, razen tole, ethernet (CSMA/CD (carrier sense multiple access/collision detection)) je koliziski protokol. Postaja, ki zeli oddajati, si mora izboriti dostop do medija. Torej najprej postaja "ugotavlja" ce je signal na vodilu ze prisoten, ce je ne zacne oddajati. Ko je vodilo prosto odda paket, vendar po oddaji se vedno spremlja signal na vodilu (od tod CD-collision detection). Ce sprejet ni enak oddanemu, je prislo do kolizije. Takrat preneha z oddajo, in pocaka nakljucno dolg cas, nato postopek ponovi.
Protokol je zato primeren predvsem za omrezja z "manj" prometa, ker pri vecjem prometu potem prihaja do vec kolizij, in se zato, posledicno, ucinkovitost omrezja zmansuje.
Nasploh pa do kolizij prihaja zaradi zakasnitev v omrezju, ki izvirajo vecinoma iz fizicnih lastnosti medija, naprav ...
Aja, razen tole, ethernet (CSMA/CD (carrier sense multiple access/collision detection)) je koliziski protokol. Postaja, ki zeli oddajati, si mora izboriti dostop do medija. Torej najprej postaja "ugotavlja" ce je signal na vodilu ze prisoten, ce je ne zacne oddajati. Ko je vodilo prosto odda paket, vendar po oddaji se vedno spremlja signal na vodilu (od tod CD-collision detection). Ce sprejet ni enak oddanemu, je prislo do kolizije. Takrat preneha z oddajo, in pocaka nakljucno dolg cas, nato postopek ponovi.
Protokol je zato primeren predvsem za omrezja z "manj" prometa, ker pri vecjem prometu potem prihaja do vec kolizij, in se zato, posledicno, ucinkovitost omrezja zmansuje.
Nasploh pa do kolizij prihaja zaradi zakasnitev v omrezju, ki izvirajo vecinoma iz fizicnih lastnosti medija, naprav ...
==
Zgodovina sprememb…
- spremenilo: iNN ()
fiction ::
Ja, ALOHA in CSMA sta kolizijska protokola - sem ravno naredil RKO tako da to se znam ;)
Potem imas se razne rezervacijske protokole (token ring, token bus) pri katerih imas neko
minimalno propustnost.To mi je jasno.
Sem se malo nerodno izrazil. Tisto glede kolizij je bilo misljeno, da ne more priti
do dveh istocasnih oddajanj - ker drugace pride do kolizije
(ni tako da bi bilo mozno oba "podatka" poslati istocasno
po eni zici) in zato pac vedno nekdo prej odda okvir kot drug
(se pravi tudi ce bosta napravi nekaj istocasno poslali bo se vedno nekdo moral cakati).
Pri protokolih z zetonom je pa itak tocno definirano kdo lahko kdaj oddaja.
Potem imas se razne rezervacijske protokole (token ring, token bus) pri katerih imas neko
minimalno propustnost.To mi je jasno.
Sem se malo nerodno izrazil. Tisto glede kolizij je bilo misljeno, da ne more priti
do dveh istocasnih oddajanj - ker drugace pride do kolizije
(ni tako da bi bilo mozno oba "podatka" poslati istocasno
po eni zici) in zato pac vedno nekdo prej odda okvir kot drug
(se pravi tudi ce bosta napravi nekaj istocasno poslali bo se vedno nekdo moral cakati).
Pri protokolih z zetonom je pa itak tocno definirano kdo lahko kdaj oddaja.
iNN ::
Ce te prav razumem, hoces povedati, da v ethernetu ne prihaja do kolizij?
Kot sem napisal ze zgoraj prihaja v ethernetu do kolizij zaradi zakasnitev, ki so posledica fizicnih lastnosti naprav, medija, ipd., to pomeni da dve postaji istocasno ugotovita da je kanal prost, in DEJANSKO zacneta oddajati istocasno, to povzroci trk. Drugace pa trk ni noben nenavaden pojav, saj ga naprava zazna, prekine oddajanje, pocaka nakljucno dolg cas in postopek ponovi.
Kot sem napisal ze zgoraj prihaja v ethernetu do kolizij zaradi zakasnitev, ki so posledica fizicnih lastnosti naprav, medija, ipd., to pomeni da dve postaji istocasno ugotovita da je kanal prost, in DEJANSKO zacneta oddajati istocasno, to povzroci trk. Drugace pa trk ni noben nenavaden pojav, saj ga naprava zazna, prekine oddajanje, pocaka nakljucno dolg cas in postopek ponovi.
==
fiction ::
iNN: Se strinjam - pri ethernetu (komercialno ime za CSMA/CD) valda prihaja do kolizij in to je tudi nekaj
povsem normalnega. Nikoli nisem (hotel) trditi kaj drugega. "Na ethernetu ne more priti do kolizij" je bil tist stavek,
ki je povzrocil zmedo in tocno zato sem tudi postal tisti popravek.
Misljeno je bilo v stilu, da ce pride do kolizije potem je itak isto kot ce nobeden ne bi nicesar oddal.
Vse kar sem hotel reci je le da 2 napravi ne morata istocasno posiljati podatkov.
Ali prepreci to carrier sense.. ki odkrije da ni prosta linija - ce pa zaradi zaksnitev
se vedno obe napravi oddajata pa to s "collision detection" obe odkrijeta in takoj nehata.
s/"Na ethernetu ne more priti do kolizij"/"Na ethernetu lahko oddaja samo ena naprava za drugo in zato
tudi ne more neka naprava dobiti dveh ARP who-has odgovorov 'na enkrat'/
Poanta je bila samo v tem, da nima veze ce napravi z istim IP-jem prikljucis "istocasno".
povsem normalnega. Nikoli nisem (hotel) trditi kaj drugega. "Na ethernetu ne more priti do kolizij" je bil tist stavek,
ki je povzrocil zmedo in tocno zato sem tudi postal tisti popravek.
Misljeno je bilo v stilu, da ce pride do kolizije potem je itak isto kot ce nobeden ne bi nicesar oddal.
Vse kar sem hotel reci je le da 2 napravi ne morata istocasno posiljati podatkov.
Ali prepreci to carrier sense.. ki odkrije da ni prosta linija - ce pa zaradi zaksnitev
se vedno obe napravi oddajata pa to s "collision detection" obe odkrijeta in takoj nehata.
s/"Na ethernetu ne more priti do kolizij"/"Na ethernetu lahko oddaja samo ena naprava za drugo in zato
tudi ne more neka naprava dobiti dveh ARP who-has odgovorov 'na enkrat'/
Poanta je bila samo v tem, da nima veze ce napravi z istim IP-jem prikljucis "istocasno".
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Po menjavi mrežne RDP ne dela.Oddelek: Operacijski sistemi | 2030 (1045) | WhiteAngel |
| » | SWITCHOddelek: Pomoč in nasveti | 1337 (1258) | prrazlag |
| » | SwitchOddelek: Omrežja in internet | 1567 (1346) | bajker |
| » | ebtables+linux+brctl+siol-tvOddelek: Omrežja in internet | 2360 (2212) | korenje_ver2 |
| » | mac spoofingOddelek: Pomoč in nasveti | 1646 (1382) | Suhy |