arp cache bij unicast

[Verwijderd]

Hallo,

Laatst in de les cisco (ccna) was er enige onenigheid over het updaten van de arp cache bij een unicast via broadcast principe (hub).
Om het duidelijker te maken:

Opstelling: 5 hosts aan een hub

Situatie: Er word gepinged van pc1 naar pc5

1.Een ARP broadcast word uitgezonden door pc1 .
2.Dus iedereen "ziet" dit aangezien een hub uitzend op alle poorten behalve de inkomende.
3.De 4 andere pc's controleren het destinatie mac in de frame header en zien dat het voor hen bedoeld is aangezien dMAC FFFF FFFF FFFF is. Ze zullen de-encapsuleren tot op laag 3 en hier is enkel pc 5 destinatie (aangezien het zijn ip is)
4.Ondertussen hebben pc 2, 3, 4, en 5 hun arp cache ge-update op basis van het source mac (hier pc 1)
5. Pc 5 zal nu unicast naar pc 1 terrugzenden aangezien hij het mac adres nu al in zijn arp cache heeft.
6.Ook nu zullen pc 1, 2, 3, 4 deze unicast zien (omdat het een hub is pc 1, 2, 3 en 4 zullen in de frame header. Maar aangezien het nu een unicast is het dMac niet meer FFFF FFFF FFFF maar het mac adres van pc1 dus pc 2, 3, 4 zullen niet verder de-encapsuleren.

De vraag is nu: Hoe komt het dat als je de arp cache bekijkt van pc 2,3 en 4 ze ook het mac adres van pc5 in hun arp cache hebben, aangezien ze zijn arp request in unicast nooit de-encapsuleerd hebben?

Ik weet dat het nogal moeilijk uitgelegd is maar ik zag geen andere manier om het te omschrijven.
Het kan zijn dat ik iets over het hoofd zie maar dan hoor ik dat wel

[Verwijderd]

Dat komt doordat het antwoord op de arp ook op alle pc's gehoord wordt. Deze pc's vinden dit schijnbaar handige informatie.

Op een switch gebeurd dit niet daar het antwoord terug een unicast is wordt deze alleen naar de te ontvangen pc geswitched, deze is inmiddels bekend doordat het source adres van zijn broadcast geleerd is.

[Soultaker]

@MASH_MAN: je mist het punt; omdat de ARP reply van node 5 aan node 1 gericht is, zouden de andere nodes 'm niet eens moeten ontvangen. Voor zover ik weet werkt een netwerkkaart normaal (als z'n host niet als bridge ofzo fungeert) in non-promiscuous mode, wat betekent dat de netwerkkaart alle packets met een verkeerd MAC-adres weggooit en de kernel de ARP reply dus nooit te zien krijgt.

Met andere woorden: ik weet het ook niet. Hoe heb je dit getest?

[Verwijderd]

Soultaker schreef op zondag 26 november 2006 @ 16:33:
@MASH_MAN: je mist het punt; omdat de ARP reply van node 5 aan node 1 gericht is, zouden de andere nodes 'm niet eens moeten ontvangen. Voor zover ik weet werkt een netwerkkaart normaal (als z'n host niet als bridge ofzo fungeert) in non-promiscuous mode, wat betekent dat de netwerkkaart alle packets met een verkeerd MAC-adres weggooit en de kernel de ARP reply dus nooit te zien krijgt.

Met andere woorden: ik weet het ook niet. Hoe heb je dit getest?

Dit was een opstelling die we gemaakt hadden in het cisco lokaal. Ik heb net dezelfde opstelling gemaakt in packettracer en daar is de arp cache van de niet bestemde hosts zelfs leeg. Dus in hoeverre dit als controle beschouwd kan worden durf ik niet zeggen.

verder @ soultaker: je zegt dat ze de arp reply niet zouden moeten ontvangen is volgens mij dat ze de reply juist wel ontvangen maar er niks mee doen aangezien het op layer 2 niet aan hen gericht is.

@ MASH MAN: Ik denk wel dat je gelijk hebt dat ze zien dat het arp is en daarom de informatie eruit halen, ook als het niet voor hun bestemd is. Dit was dan ook wat ik ervan dacht

[ Voor 8% gewijzigd door Verwijderd op 26-11-2006 17:06 ]

[Verwijderd]

Verwijderd schreef op zondag 26 november 2006 @ 17:04:
verder @ soultaker: je zegt dat ze de arp reply niet zouden moeten ontvangen is volgens mij dat ze de reply juist wel ontvangen maar er niks mee doen aangezien het op layer 2 niet aan hen gericht is.

Als jij in een trein/bus zit, en er zitten 2 andere mensen te praten, dan hoor je dit toch ook? Ook al is het niet voor jou bedoeld.

Maar goed, aan de ene kant is dit wel handig (network sniffing, etc), aan de andere kant ook weer niet. Ik heb er geen problemen mee dat dit gebeurt, omdat je alleen met switches moet werken (hubs zijn oud en traag).

Ik gebruik zelf een simpel en oude hub (4 poorts) in mijn forensic-kit. Om zo met mijn laptop te kunnen luisteren naar wat een PC doet op het netwerk (diagnose tijdens herstart, kijken of spyware/backdoors een "call to home" doet).

[Soultaker]

Verwijderd schreef op zondag 26 november 2006 @ 17:14:
Als jij in een trein/bus zit, en er zitten 2 andere mensen te praten, dan hoor je dit toch ook? Ook al is het niet voor jou bedoeld.

Dat is geen goede analogie. Een netwerkkaart geeft een packet alleen door aan de kernel in een van deze gevallen:
• het bestemmingsadres is het adres van de netwerkkaart;
• het bestemmingsadres is een broadcastadres;
• de netwerkkaart werkt in promiscuous mode.
Als dit niet voor de ARP reply geldt, dan krijgt de kernel het packet niet te zien, en kan de ARP cache in de kernel niet geüpdatet worden.

Als dat wel gebeurt, is er dus iets speciaals. Misschien dat sommige netwerkkaarten ook op basis van 't frame type besluit om een packet door te geven?

Verwijderd schreef op zondag 26 november 2006 @ 17:04:
verder @ soultaker: je zegt dat ze de arp reply niet zouden moeten ontvangen is volgens mij dat ze de reply juist wel ontvangen maar er niks mee doen aangezien het op layer 2 niet aan hen gericht is.

De netwerkkaart kan 'm wel ontvangen, maar de kernel als het goed is niet (tenzij de netwerkkaart in promiscuous mode werkt).

[ Voor 21% gewijzigd door Soultaker op 26-11-2006 17:35 ]

[Verwijderd]

Soultaker schreef op zondag 26 november 2006 @ 17:21:
[...]


Als dat wel gebeurt, is er dus iets speciaals. Misschien dat sommige netwerkkaarten ook op basis van 't frame type besluit om een packet door te geven?

Dat denk ik ook maar ik wou het hier dus even vragen zodat dit bevestigd kon worden.

[serkoon]

Dit zou alleen mogen gebeuren wanneer de NICs in promisc. mode staan. Dat is zelfs de basis van het detecteren van sniffers op een netwerk: doordat een sniffend systeem arp replies ziet en arp caches update, kun je achterhalen dat NICs in promisc. mode staan omdat die systemen arp cache entries hebben die er niet zouden moeten zijn.