PT's telling me my MAC Address is invalid
hiddenknight821
Member Posts: 1,209 ■■■■■■□□□□
in CCNA & CCENT
Packet Tracer rejected my MAC address when I tried to manually configure it on a host.
I was trying to understand how IPv6 Stateless Auto-configuration works. Don't laugh, but I first tried this address, DEAD.B00B.FACE. It works (please note that's not an 'O' but a zero). However, I am now getting myself confuse with the EUI-64 rule since I thought I would get FE80:: DCAD:B0FF:FE0B:FACE as my link-local address, but I get this instead (FE80:: DEAD:B0FF:FE0B:FACE). I thought the first 7th binary bit in the first byte (2nd hex digit) would be inverted, but it seems to me I am only suppose to make sure that 7th bit is always a binary one instead of zero when doing the EUI-64 calculation. Please help me out clear up this confusion too.
Now, back to my original point. So, I decided to change the first byte (first two hex) to 02AD.B00B.FACE to try to understand what rule the EUI-64 is using. It works, but the following don't work and are rejected:
01AD.B00B.FACE
03AD.B00B.FACE
05AD.B00B.FACE
07AD.B00B.FACE
09AD.B00B.FACE
I dunno what's up here, but seems like there are rules on creating MAC addresses that I am not aware of. I would like you guys to take a crack at this mystery to see if you get the same result. I'm currently using the latest version of PT (5.3.008 ).
I was trying to understand how IPv6 Stateless Auto-configuration works. Don't laugh, but I first tried this address, DEAD.B00B.FACE. It works (please note that's not an 'O' but a zero). However, I am now getting myself confuse with the EUI-64 rule since I thought I would get FE80:: DCAD:B0FF:FE0B:FACE as my link-local address, but I get this instead (FE80:: DEAD:B0FF:FE0B:FACE). I thought the first 7th binary bit in the first byte (2nd hex digit) would be inverted, but it seems to me I am only suppose to make sure that 7th bit is always a binary one instead of zero when doing the EUI-64 calculation. Please help me out clear up this confusion too.
Now, back to my original point. So, I decided to change the first byte (first two hex) to 02AD.B00B.FACE to try to understand what rule the EUI-64 is using. It works, but the following don't work and are rejected:
01AD.B00B.FACE
03AD.B00B.FACE
05AD.B00B.FACE
07AD.B00B.FACE
09AD.B00B.FACE
I dunno what's up here, but seems like there are rules on creating MAC addresses that I am not aware of. I would like you guys to take a crack at this mystery to see if you get the same result. I'm currently using the latest version of PT (5.3.008 ).
Comments
-
Todd Burrell Member Posts: 280I would suspect that the other MAC addresses are showing up as duplicates? I don't know all the gory details, but I seem to remember that the EUI-64 format takes the MAC address and then flips some bits in the first part of the MAC address. Look at this link:
EUI-64 in IPv6 - Packet Life -
hiddenknight821 Member Posts: 1,209 ■■■■■■□□□□Crap. I hate the stupid smiley when I put the ':' and 'D' or ':' and ')' next to each other. I hope you guys can figure out what I was trying to type, and I can assure you I made no mistake from my observation in PT. The only thing in the topology is the PC host itself, so there clearly was no MAC address conflict.
Todd, I already explained that I had a misconception about the EUI rule, and I need someone to tell me if my first or second thought was right. I am aware about changing the bit, but PacketLife is contradicting with my observation from Packet Tracer. So could someone with high self-confidence please test this or refute any of the misleading information here? Thanks. -
hiddenknight821 Member Posts: 1,209 ■■■■■■□□□□I am still not 100% sure why I'm seeing what I was seeing, but I am almost positive that the the programmers of PT were extremely lazy and didn't understand how the Universal/Local (U/L) bit works. The link Todd previously posted made much more sense to me as I had already believed that's how EUI-64 bit. I mean... You should be able to tell whether the MAC address is universally administered or locally administered from reading the IPv6 address with the EUI-64 and determine the original MAC address. The PT didn't invert the second least-significant bit in the first most-significant byte for all addresses. I noticed it was programmed to prevent people from plugging in the odd hex numbers (from 0 to F) in the second digit, but only accept even hex numbers.
Screw PT programmers. That was one of the most simplest thing out of many other features they programmed. I would hate to point out that Odom poorly explained how EUI-64 bit works as I was given the impression that he would explain everything concisely in great details. You can find it on pg. 595 in the ICND2 book. PacketTracer and Wiki did much better job explaining it.