mac adress - hoe verberg ik deze

[Verwijderd]

Iemand wist via internet mijn com21 kabel modem even te ontregelen, die had dan waarschijnlijk stoute software die eigenlijk alleen @home hoort te hebben..(en andere providers enzo..)
Maar de @home man vertelde mij dat hij dan mijn mac-adress moest weten, en dat dat niet zo 1, 2, 3 gaat.

Blijkbaar wel, maar hoe kan ik zorgen dat ik dat adres beter verberg? Black ice en winroute draai ik tegerlijk, maar helpen blijkbaar niet...

[I.R. Overclocked]

LOL, die kan je niet verbergen, als je dat wel doet kan je niet meer internetten

[Ronald]

Je MAC adres staat in elk willekeurig IP pakketje, je kunt het niet verbergen, en het is zelfs, in tegenstellign tot meneer Kneus bij @home, zeer makkelijk te achterhalen. kostte me 9 seconden om MACje van athena.tweakers.net te achterhalen...
(packet sniffer starten en 1 pingetje doen)

[Verwijderd]

dus kan iedereen, die com21 modem software,
@home modems ontregelen,

klopt dat?

[Verwijderd]

Op dinsdag 13 november 2001 20:33 schreef nitenite het volgende:
Je MAC adres staat in elk willekeurig IP pakketje, je kunt het niet verbergen, en het is zelfs, in tegenstellign tot meneer Kneus bij @home, zeer makkelijk te achterhalen. kostte me 9 seconden om MACje van athena.tweakers.net te achterhalen...
(packet sniffer starten en 1 pingetje doen)

i dare ya. wat is het MAC van mijn Com21?

Op dinsdag 13 november 2001 20:38 schreef illem het volgende:
dus kan iedereen, die com21 modem software,
@home modems ontregelen,

klopt dat?

nee, klopt niet

[maontje]

Denk niet dat ze het kunnen Eppo1313. Ze kennen de werking avn een ip pakketje niet denk ik....|:

[Verwijderd]

als jij 't mac van athena kan sniffen dan zou dat betekenen dat er GEEN router of bridge tussen jou en athena zit. Dat is niet geloofwaardig, dus het mac wat je daar hebt is waarschijnlijk het mac van de eerste router op weg naar athena......

[Helsie]

Op dinsdag 13 november 2001 22:14 schreef TheIceCoMan het volgende:
als jij 't mac van athena kan sniffen dan zou dat betekenen dat er GEEN router of bridge tussen jou en athena zit. Dat is niet geloofwaardig, dus het mac wat je daar hebt is waarschijnlijk het mac van de eerste router op weg naar athena......

Daar zat ik ook al te denken. Van begin tot eind is de communicatie toch gebaseerd op het ip-adres?
De routers vervoeren het dan van router naar router tot het bij de uiteindelijke bestemming is.

[mvdejong]

Juist.
Het MAC-adres werkt alleen voor het lokale net, niet over routers, bridges/switches heen. Dat heeft namelijk helemaal geen zin, omdat er geen garantie is dat alle tussenliggende netwerken een technologie gebruiken waarbij een MAC-adres bestaat. Hoewel Ethernet, TokenRing, FDDI en ATM wel allemaal een vorm van MAC-adres (of hoe het ook bij de verschillende versies heet) hebben, heeft bijvoorbeeld een klassieker als ARCnet alleen een stations-nummer van 0-31 (of later 0-255). Bovendien, om verschillende redenen is het voor TokenRing is het normaal, en voor Ethernet vaak mogelijk, dat niet een hardware-matig, absoluut uniek, MAC-adres wordt gebruikt, maar handmatig ingesteld MAC-adres.

Basis-idee :
- Systeem X wil een IP-pakketje versturen naar systeem Y.
- Als systeem Y op hetzelfde netwerk-segment zit (volgens netmask en routing-tabellen) : stuur een broadcast-ARP-pakketje (Address Resolution Protocol) rond met daarin het hardware-adres van systeem X, en wacht tot systeem Y een aan het hardware-adres van systeem X gericht pakketje terugstuurt met het hardware-adres van systeem Y.
- Verdere conversatie gebeurt nu tussen de beide hardware-adressen.

Als systeem Y op een andere netwerk-segment zit : bepaal de gewenste router (ofwel een specifieke router, ofwel de default-router), en ga dezelfde ARP-discussie aan, maar dan met de router als doel. Zodra de router het pakketje binnenheeft, gaat deze hetzelfde spelletje spelen : lokaal of niet, routertje vinden, doorsturen, enz.

Voor beide situaties geldt ook eigenlijk nog dat voordat een ARP-discussie wordt aangegaan er eerst wordt gekeken of dat hardware-adres al in de lokale ARP-cache zit ten gevolge van eerdere discussie, dat versimpelt de zaak dan aanmerkelijk.

Een complicatie krijg je bijv. bij ATM, dat geen broadcast kent, en dus geen "echte" ARP kan doen. Een ATM-netwerk dat IP moet ondersteunen heeft daartoe een ARP-server (vaak in een switch geintegreerd), waarbij alle stations hun hardware-adres registreren, en waarvan het hardware-adres bij alle stations in de ATM-configuratie moet worden vastgelegd (er is een default-adres hiervoor aangewezen).

[weirdje]

Op dinsdag 13 november 2001 22:14 schreef TheIceCoMan het volgende:
als jij 't mac van athena kan sniffen dan zou dat betekenen dat er GEEN router of bridge tussen jou en athena zit. Dat is niet geloofwaardig, dus het mac wat je daar hebt is waarschijnlijk het mac van de eerste router op weg naar athena......

Een bridge mag nog wel. Die kopieert namelijk hele ethernet frames van poort naar poort (zie switch).
Een router is inderdaad net even een tikkie anders...

[Verwijderd]

Op dinsdag 13 november 2001 22:14 schreef TheIceCoMan het volgende:
als jij 't mac van athena kan sniffen dan zou dat betekenen dat er GEEN router of bridge tussen jou en athena zit. Dat is niet geloofwaardig, dus het mac wat je daar hebt is waarschijnlijk het mac van de eerste router op weg naar athena......

yup probeer maar eens een ander site te sniffen... zal je zien hetzelfde mac adress... als je de mac adressen zou kunnen zien waarom heb je dan nog ip nodig? (andersom natuurlijk ip wordt gebruikt voor routeren mac voor de overdracht tussen 2 pc's/routers op HETZELFDE netwerk)

dus in een pakketje veranderen de mac adressen (elke hop) continue terwijl het begin en eind ipadress onveranderd blijven. echter bij sommige toepassingen/proggies wordt het begin mac-adress ook nog eens in de data verstuurd maar dat is niet zomaar te sniffen... (wel te sniffen maar niet duidelijk wat nu het mac adress is!!! )

[Verwijderd]

Op dinsdag 13 november 2001 23:18 schreef mvdejong het volgende:
Juist.
Het MAC-adres werkt alleen voor het lokale net, niet over routers, bridges/switches heen.

op de goede weg maar niet helemaal. switches en brigdes laten wel broadcasts door (ARP/RARP is een broadcast). laag 2 apparaten weet je wel... de communicatie over een switch gaat dus ook op mac adress; de switch cached de mac adressen die aanwezig zijn op elke poort vandaar dat communicatie tussen 2 pc's alleen over die 2 poorten gaat; broadcasts worden echter wel over alle poorten uitgestuurd.

voor de rest ben ik het met je eens.

[mvdejong]

Het was duidelijk dat ik ten tijde van die post in mijn bed had moeten liggen

Ik weet wel beter. Natuurlijk doen switches/bridges niets met het pakketje zelf (anders zou mijn eigen netwerk thuis het niet echt lekker doen, want daar zit ook Ethernet-FDDI- en Ethernet-TokenRing -bridging in).

nitenite, probeer eens het MAC-adres te achterhalen van de router waarmee je babbelt ...

[TrailBlazer]

Hmm jammer wilde net een verhaal gaan houden over het OSI model maar een paar waren me voor. Je kan aan de hand van een IP adres wat niet op je eigen netwerksegment zit NOOIT het macadres achterhalen. Met IPV6 zal dit anders worden geloof ik omdat dan het MAC onderdeel wordt van je IPV6 adres maar weet ik niet helemaal zeker

[TrailBlazer]

Op dinsdag 13 november 2001 23:18 schreef mvdejong het volgende:
Juist.
Het MAC-adres werkt alleen voor het lokale net, niet over routers, bridges/switches heen. Dat heeft namelijk helemaal geen zin, omdat er geen garantie is dat alle tussenliggende netwerken een technologie gebruiken waarbij een MAC-adres bestaat. Hoewel Ethernet, TokenRing, FDDI en ATM wel allemaal een vorm van MAC-adres (of hoe het ook bij de verschillende versies heet) hebben, heeft bijvoorbeeld een klassieker als ARCnet alleen een stations-nummer van 0-31 (of later 0-255). Bovendien, om verschillende redenen is het voor TokenRing is het normaal, en voor Ethernet vaak mogelijk, dat niet een hardware-matig, absoluut uniek, MAC-adres wordt gebruikt, maar handmatig ingesteld MAC-adres.

Basis-idee :
- Systeem X wil een IP-pakketje versturen naar systeem Y.
- Als systeem Y op hetzelfde netwerk-segment zit (volgens netmask en routing-tabellen) : stuur een broadcast-ARP-pakketje (Address Resolution Protocol) rond met daarin het hardware-adres van systeem X, en wacht tot systeem Y een aan het hardware-adres van systeem X gericht pakketje terugstuurt met het hardware-adres van systeem Y.
- Verdere conversatie gebeurt nu tussen de beide hardware-adressen.

Als systeem Y op een andere netwerk-segment zit : bepaal de gewenste router (ofwel een specifieke router, ofwel de default-router), en ga dezelfde ARP-discussie aan, maar dan met de router als doel. Zodra de router het pakketje binnenheeft, gaat deze hetzelfde spelletje spelen : lokaal of niet, routertje vinden, doorsturen, enz.

Voor beide situaties geldt ook eigenlijk nog dat voordat een ARP-discussie wordt aangegaan er eerst wordt gekeken of dat hardware-adres al in de lokale ARP-cache zit ten gevolge van eerdere discussie, dat versimpelt de zaak dan aanmerkelijk.

Een complicatie krijg je bijv. bij ATM, dat geen broadcast kent, en dus geen "echte" ARP kan doen. Een ATM-netwerk dat IP moet ondersteunen heeft daartoe een ARP-server (vaak in een switch geintegreerd), waarbij alle stations hun hardware-adres registreren, en waarvan het hardware-adres bij alle stations in de ATM-configuratie moet worden vastgelegd (er is een default-adres hiervoor aangewezen).

Hulde voor je verhaal klopt helemaal alleen het laatste over ATM klopt niet volgens mij. Tenminste ik heb nog nooit een netwerk gezien gebaseerd op ATM. Ethernet is het protocol van de MAC adressen. Een router krijgt een pakketje pinnen voor IP a.b.c.d en weet dan anade hand van zijn routeringstabellen welke de next hop is en op welke interface hij deze d'r uit moet gooien. ATM doet helemaal niks met MAC adressen

[weirdje]

Op woensdag 14 november 2001 11:42 schreef TrailBlazer het volgende:
Hmm jammer wilde net een verhaal gaan houden over het OSI model maar een paar waren me voor. Je kan aan de hand van een IP adres wat niet op je eigen netwerksegment zit NOOIT het macadres achterhalen. Met IPV6 zal dit anders worden geloof ik omdat dan het MAC onderdeel wordt van je IPV6 adres maar weet ik niet helemaal zeker

Met EUI-64 kan je MAC adres inderdaad onderdeel van je IPv6 adres worden. Dit *moet* echter niet. Je kunt ook een ander adres kiezen (zonder het MAC adres dus) en je machine daarmee configureren. Als je dan paranoide bent, kun je dus voorkomen dat derden je MAC adres te zien krijgen.

[serkoon]

Op woensdag 14 november 2001 11:47 schreef TrailBlazer het volgende:

[..]

Hulde voor je verhaal klopt helemaal alleen het laatste over ATM klopt niet volgens mij. Tenminste ik heb nog nooit een netwerk gezien gebaseerd op ATM. Ethernet is het protocol van de MAC adressen. Een router krijgt een pakketje pinnen voor IP a.b.c.d en weet dan anade hand van zijn routeringstabellen welke de next hop is en op welke interface hij deze d'r uit moet gooien. ATM doet helemaal niks met MAC adressen

2 r3-atm5-0-0-3.rdc1.ov.home.nl (212.120.67.45) 14.955 ms 17.896 ms 17.297 ms

2e hop vanaf mijn huis.. Zie je die 3 letters 'atm'?
ATM doet niet alleen niks met MAC-adressen, ATM heeft ze niet eens. ATM heeft natuurlijk wel hardware-adressen, maar een MAC-adres is ethernet-specific. Een router opereert bovendien op een ander niveau dan waar je ATM/ethernet moet plaatsen.

[mvdejong]

ATM is uitstekend geschikt als basis voor een IP-netwerk. Overigens gebruik ik de term "hardware-adres", niet MAC-adres, zodra ik me niet tot Ethernet beperk.

ATM wordt gebruikt enkel als backbone, maar ook wel tot aan de eind-stations, speciaal in een omgeving waar veel met audio en video wordt gewerkt, want voor dit soort mixen is ATM ontwikkeld. Het grote voordeel van ATM in dit soort omgevingen is de ruime mogelijkheden om bijv. streaming video voorrang te geven boven "gewoon" data-verkeer. En je kunt desnoods je telefoon-verkeer ook over hetzelfde fysieke netwerk duwen. Ook is de protocol-overhead lager dan bij de meer gebruikelijke netwerken.

Voor ATM naar het eind-station wordt dan vaak wel voor de goedkopere 25 Mbps ATM over UTP gekozen, niet voor de 155 Mbps over glas (of zelfs de brute 622 Mbps). ATM is niet echt medium-gebonden, het gaat tot vele Gigabits, maar ook andere bekabelingen worden ondersteund, bijv. E3 : 36 Mbps of DS1 : 45 Mbps, beide over 2 75 Ohm coax-kabels (36 Mbps heb ik thuis tussen 2 switchjes liggen).

IP over ATM kan zelfs op 2 manieren :
CLIP : Classical IP, waarbij de IP-stack direct op de ATM-controller-driver bouwt.
LANE : LAN Emulation, waarbij de IP-stack op een LAN Emulation-driver bouwt, die bovenop de ATM-controller-driver wordt geladen.
Voor PC-drivers betekent de keuze voor CLIP dat de ATM-controller puur als netwerk-kaart wordt gebruikt, LANE biedt de mogelijkheid om daarnaast nog steeds audio en video direct over ATM te sturen. Voor Sun Solaris-drivers zijn CLIP en LANE wel mogelijk op dezelfde controller.

Elke ATM-kaart heeft een hardware-adres, en een deel daarvan, 6 bytes groot, is niet alleen binnen de ATM-wereld uniek, maar overlapt ook niet met de hardware-adressen van Ethernet, FDDI en TokenRing. Het hardware-adres van ATM is echter veel groter, en een deel daarvan kan ook worden bepaald door de switch waarmee de ATM-controller is verbonden. Het hoeft niet, het adres kan ook handmatig worden geconfigureerd.

Het grote probleem van ATM is dat broadcasts daar niet bestaan, daarom zal ATM een ARP-server moeten gebruiken. I.p.v. dat een ATM-driver een ARP-broadcast pleegt, raadpleegt deze de ARP-server (waar de driver zichzelf ook eerder heeft geregistreerd), en krijgt dan het hardware-adres van de ARP-server aangereikt. 't Is een noodgreep, maar het werkt. De ARP-server draait meestal binnen de ATM-switch, hoewel de ATM-packages voor Sun Solaris ook een ARP-server bevatten. Voor zover mij bekend is dit wel de enige non-switch-based ARP-server.
Het hardware-adres voor de ARP-server moet in de configuratie van de ATM-controller worden vastgelegd (net zoals bij LANE dat van de LANE-server).

Natuurlijk is deze manier van omgang met ATM achterhaald :
- de 155 Mbps is niet veel sneller dan FastEthernet, en wordt overschaduwd door Gigabit Ethernet;
- VOIP (Voice-over-IP) levert ook in de conventionele netwerken de combinatie van telefoon- en data-verkeer (op dezelfde manier dat SCSI-over-IP een geduchte concurrent van FibreChannel aan het is);
- prioriteits-mechanismen zitten in elke geavanceerde switch van tegenwoordig;
- ATM is nog steeds schreeuwend duur, terwijl elke Ethernet-vorm binnen een paar jaar na introductie voor iedereen betaalbaar is.

ATM is nog steeds razend populair bij providers vanwege de uitstekende beheersbaarheid en schaalbaarheid, de voordelen wegen daar ruimschoots tegen de kosten op.

[TrailBlazer]

Op woensdag 14 november 2001 12:51 schreef serkoon het volgende:

[..]

2 r3-atm5-0-0-3.rdc1.ov.home.nl (212.120.67.45) 14.955 ms 17.896 ms 17.297 ms

2e hop vanaf mijn huis.. Zie je die 3 letters 'atm'?
ATM doet niet alleen niks met MAC-adressen, ATM heeft ze niet eens. ATM heeft natuurlijk wel hardware-adressen, maar een MAC-adres is ethernet-specific. Een router opereert bovendien op een ander niveau dan waar je ATM/ethernet moet plaatsen.

Wat bedoel je met dat zie je die drie lettes. JA ik kan ook een ATM interface een IP adres geven, hieroverheen routeren en vervolgens dit IP adres in een DNS server zetten daar is geen kunst aan :|(
Een router opereert op een ander niveau dan waar je ATM/ ethernet moet plaatsen. Ik werk met routers met een ATM interface en een ethernet interface. dus ik begrijp niet wat je met dat niveau bedoelt ALS je OSI bedoelt ATM en Ehernet zijn beide laag 2 protocollen en een router is een laag 3 device dus hebben absoluut wat met elkaar te maken

[TrailBlazer]

Op woensdag 14 november 2001 13:27 schreef mvdejong het volgende:
ATM is uitstekend geschikt als basis voor een IP-netwerk. Overigens gebruik ik de term "hardware-adres", niet MAC-adres, zodra ik me niet tot Ethernet beperk.

ATM wordt gebruikt enkel als backbone, maar ook wel tot aan de eind-stations, speciaal in een omgeving waar veel met audio en video wordt gewerkt, want voor dit soort mixen is ATM ontwikkeld. Het grote voordeel van ATM in dit soort omgevingen is de ruime mogelijkheden om bijv. streaming video voorrang te geven boven "gewoon" data-verkeer. En je kunt desnoods je telefoon-verkeer ook over hetzelfde fysieke netwerk duwen. Ook is de protocol-overhead lager dan bij de meer gebruikelijke netwerken.

IP over ATM kan zelfs op 2 manieren :
CLIP : Classical IP, waarbij de IP-stack direct op de ATM-controller-driver bouwt.
LANE : LAN Emulation, waarbij de IP-stack op een LAN Emulation-driver bouwt, die bovenop de ATM-controller-driver wordt geladen.
Voor PC-drivers betekent de keuze voor CLIP dat de ATM-controller puur als netwerk-kaart wordt gebruikt, LANE biedt de mogelijkheid om daarnaast nog steeds audio en video direct over ATM te sturen. Voor Sun Solaris-drivers zijn CLIP en LANE wel mogelijk op dezelfde controller.

Elke ATM-kaart heeft een hardware-adres, en een deel daarvan, 6 bytes groot, is niet alleen binnen de ATM-wereld uniek, maar overlapt ook niet met de hardware-adressen van Ethernet, FDDI en TokenRing. Het hardware-adres van ATM is echter veel groter, en een deel daarvan kan ook worden bepaald door de switch waarmee de ATM-controller is verbonden. Het hoeft niet, het adres kan ook handmatig worden geconfigureerd.

Het grote probleem van ATM is dat broadcasts daar niet bestaan, daarom zal ATM een ARP-server moeten gebruiken. I.p.v. dat een ATM-driver een ARP-broadcast pleegt, raadpleegt deze de ARP-server (waar de driver zichzelf ook eerder heeft geregistreerd), en krijgt dan het hardware-adres van de ARP-server aangereikt. 't Is een noodgreep, maar het werkt. De ARP-server draait meestal binnen de ATM-switch, hoewel de ATM-packages voor Sun Solaris ook een ARP-server bevatten. Voor zover mij bekend is dit wel de enige non-switch-based ARP-server.
Het hardware-adres voor de ARP-server moet in de configuratie van de ATM-controller worden vastgelegd (net zoals bij LANE dat van de LANE-server).

Natuurlijk is deze manier van omgang met ATM achterhaald :
- de 155 Mbps is niet veel sneller dan FastEthernet, en wordt overschaduwd door Gigabit Ethernet;
- VOIP (Voice-over-IP) levert ook in de conventionele netwerken de combinatie van telefoon- en data-verkeer (op dezelfde manier dat SCSI-over-IP een geduchte concurrent van FibreChannel aan het is);
- prioriteits-mechanismen zitten in elke geavanceerde switch van tegenwoordig;
- ATM is nog steeds schreeuwend duur, terwijl elke Ethernet-vorm binnen een paar jaar na introductie voor iedereen betaalbaar is.

ATM is nog steeds razend populair bij providers vanwege de uitstekende beheersbaarheid en schaalbaarheid, de voordelen wegen daar ruimschoots tegen de kosten op.

Dank vor deze uitleg (ps waar heb je deze kennis opgedaan)

[mvdejong]

Bron van kennis :
1. algemene artikelen op het Internet;
2. manuals van verschillende hardware-producten, ofwel van dingen die ik heb, ofwel downloads van leveranciers;
3. whitepapers die leveranciers over technieken publiceren;
4. zelf die shit op zolder aanleggen (alleen al het plannen daarvan dwingt je om echt goed met 1. en 2. om te gaan).

Als je alleen maar Ethernet kent, en je gaat dan ook maar 1 andere netwerk-technologie ernaast doen, dan gaan je ogen open en zie je wat wel echt nodig is voor een netwerk, en wat ook op andere manieren kan.

Een gedachten-truc is om, als je over meerdere netwerk-segmenten nadenkt, soms daartussen ook een segment inbeeldt bestaande uit een kaboutertje met een lei en een krijtje. Wat je nodig hebt voor routering over dat segment dwingt je om de essentiele van de handige zaken te scheiden.

O ja, nog een manieren om je kennis aan te scherpen :
Probeer op een forum jouw kennis over te dragen aan anderen. Het formuleren dwingt je om je kennis ook voor jezelf te structureren, en als je de mist ingaat (zie een van mijn vorige posts), dan wordt je vanzelf "gecorrigeerd". Voor dat laatste moet je dan wel dankbaar zijn, ook al gebeurt het soms wat minder elegant ("Hoe kom je erbij dat ... Wat een onzin/kolder ... en erger).

[weirdje]

Op woensdag 14 november 2001 12:51 schreef serkoon het volgende:

[..]

ATM doet niet alleen niks met MAC-adressen, ATM heeft ze niet eens. ATM heeft natuurlijk wel hardware-adressen, maar een MAC-adres is ethernet-specific. Een router opereert bovendien op een ander niveau dan waar je ATM/ethernet moet plaatsen.

een MAC adres is niet ethernet specifiek. MAC staat voor Medium Access Control, dus de manier waarop je toegang krijgt tot het medium (de kabel of de ether (ingeval van wireless)).

Om een voorbeeld te noemen, Token Ring heeft ook MAC adressen.

[mvdejong]

Terwijl hardware-adressen natuurlijk voor elke netwerk-technologie onmisbaar zijn, worden deze alleen bij Ethernet daadwerkelijk MAC-adres genoemd.
Bij TokenRing heet het hardware-adres dat in de kaart is geprogrammeerd het UAA (Universally Administrated Address), terwijl het adres dat je handmatig kunt instellen het LAA (Locally Administrated Address) wordt genoemd.

Toevoeging/correctie : bij FDDI/CDDI wordt het ook echt MAC-adres genoemd.

[TrailBlazer]

Ik heb begrepen dat je bij sommige ethernet netwerk kaarten wel het MAC adres kan wijzigen. Sterker nog bij een Hot Standby Routing heb je twee ip adressen in je arp tabel met exact hetzlefde mac adres

code:

Internet  173.129.35.12    185   0000.3099.3143  SNAP   TokenRing0
Internet  173.129.34.13      -   0000.0cf7.81a9  ARPA   Ethernet0
Internet  173.129.34.2       55   0000.0c07.ac01  ARPA   Ethernet0
Internet  173.129.35.3       79   0000.302c.1b99  SNAP   TokenRing0
Internet  173.129.34.3      9   0000.0c37.9c12  ARPA   Ethernet0
Internet  173.129.35.2       97   0000.30ec.3988  SNAP   TokenRing0
Internet  173.129.34.1       91   0000.0c07.ac01  ARPA   Ethernet0
Internet  173.129.34.6      7   0008.c71e.585e  ARPA   Ethernet0

Let op de mac addressen van de .1 en de .2 zijn hetzelfde ze zijn een bepaald HSR mac adress group nummer geloof ik handig als je router besluit te overlijden ofzo