[Lxc-users] mac addresses
Michael H. Warfield
mhw at WittsEnd.com
Fri Feb 12 17:02:23 UTC 2010
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 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20100212/b9294586/attachment.pgp>
More information about the lxc-users
mailing list