On Fri, 2010-02-12 at 11:37 -0500, Brian K. White wrote:
The reason I'm trying to use the new mac numbering scheme in case it's
not apparent is, an OUI consumes 3 of the available 6 bytes in a mac,
leaving only 3 to make a unique number out of. Yet IP addresses have 4
bytes and I want a _simple_ rule or bit of script that will always
result in a safely unique, statically assigned mac, without having to
maintain a db of them. Something I could put into documentation and it
would always work, not just usually work in the simple cases.
So I figured, 02:00 for the first two bytes, and directly convert the IP
into the remaining 4 bytes. Every admin already has to make his IP's
unique at least within the same network, so those macs should always
work. My initial rule of using the OUI that Novell uses for Xen guests
(I'm using openSUSE) and then convering just the last byte of the IP
into the last byte of the mac, and using the second-to-last byte of the
mac to seperate different networks if a host or container has multiple
nics on multiple networks, that rule falls down in all but the simplest
cases.
OUI's consume 3 byte (minus 2 bits) but that really only applies if
the locally administered bit is not set. You're setting it so you can
do what ever you like with the remaining (which you obviously recognize
by using the 4 bytes). Just want to clarify that.
So my question is, is 02:x:x:x:x:x in some way non-routable just
because it sets the locally-administered bit?
I use that all the time without any problems. It may be something in
the way their switch is set up that limits the number of mac addresses
on that port. I have seen that (we've got it at work administered by
our IT department where we have a Cisco switching fabric that manages 3
buildings with 3 network ports to each station) where one network is
limited by default to 5 mac addresses per port and another, more
restrictive, network is limited to just one. If it's something like a
Cisco switching fabric, it's pretty straight forward to set up limits
like that. I think ours are all within a 24 hour period and resets
after that to allow you to change machines, do maintenance, and other
such.
Is there some sort of packet I can send that will trigger Verizons
switches routers to update to the new mac for more than 5 seconds?
That's a question for Verizon.
If I traceroute from a remote box in to one of these containers, it just
gets to a particular Verizon router that I have no control over and goes
no further.
pa2:~ # traceroute nj12
traceroute to nj12 (71.187.206.76), 30 hops max, 40 byte packets
1 gw-238-225.quonix.net (208.72.238.225) 0.349 ms 0.224 ms 0.198 ms
2 ge-11-1-2.mpr3.phl2.us.above.net (209.249.122.165) 0.280 ms 0.300 ms
0.199 ms
3 xe-4-0-0.mpr1.lga5.us.above.net (64.125.31.34) 2.533 ms 2.437 ms
2.431 ms
4 xe-0-1-0.er1.lga5.us.above.net (64.125.27.61) 2.264 ms 2.312 ms
2.325 ms
5 0.ge-3-2-0.BR3.NYC4.ALTER.NET (204.255.168.25) 2.291 ms 2.294 ms
2.321 ms
6 0.ge-4-2-0.NY5030-BB-RTR2.verizon-gni.net (152.63.10.54) 2.652 ms
2.683 ms 6.821 ms
7 so-6-3-0-0.NWRK-BB-RTR2.verizon-gni.net (130.81.19.97) 4.155 ms
4.303 ms 3.696 ms
8 P15-0-0.NWRKNJ-LCR-04.verizon-gni.net (130.81.29.195) 4.904 ms 4.806
ms 4.697 ms
9 P12-0-0.NWRKNJ-LCR-06.verizon-gni.net (130.81.27.7) 5.657 ms 5.434
ms 5.447 ms
10 P14-0.NWRKNJ-LCR-08.verizon-gni.net (130.81.30.95) 5.658 ms 5.551 ms
5.573 ms
If I traceroute from the same remote box to the host that the containers
is on, it take a very different-looking path and reaches the host.
Though possibly the differences are just load-balancing hardware?
pa2:~ # traceroute nj10
traceroute to nj10 (71.187.206.74), 30 hops max, 40 byte packets
1 gw-238-225.quonix.net (208.72.238.225) 0.325 ms 0.187 ms 0.196 ms
2 ge-11-1-2.mpr3.phl2.us.above.net (209.249.122.165) 0.282 ms 0.179 ms
0.201 ms
3 xe-4-0-0.mpr1.lga5.us.above.net (64.125.31.34) 2.535 ms 2.439 ms
2.430 ms
4 xe-0-1-0.er1.lga5.us.above.net (64.125.27.61) 2.259 ms 2.288 ms
2.317 ms
5 0.ge-3-2-0.BR3.NYC4.ALTER.NET (204.255.168.25) 2.327 ms 2.314 ms
2.307 ms
6 0.ge-8-1-0.NY325-BB-RTR1.verizon-gni.net (152.63.18.38) 2.690 ms
2.756 ms 2.646 ms
7 so-4-0-0-0.NWRK-BB-RTR1.verizon-gni.net (130.81.17.7) 7.708 ms
20.080 ms 7.678 ms
8 P15-0-0.NWRKNJ-LCR-03.verizon-gni.net (130.81.29.193) 8.419 ms 8.098
ms 8.031 ms
9 P12-0-0.NWRKNJ-LCR-05.verizon-gni.net (130.81.27.2) 9.065 ms 9.111
ms 9.059 ms
10 P14-0.NWRKNJ-LCR-07.verizon-gni.net (130.81.30.9) 7.729 ms 7.671 ms
7.595 ms
11 * * *
12 static-71-187-206-74.nwrknj.fios.verizon.net (71.187.206.74) 17.883 ms
12.380 ms 14.285 ms
pa2:~ #
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com