[atlas] Request for RIPE Atlas probe DHCP change.
- Previous message (by thread): [atlas] Request for RIPE Atlas probe DHCP change.
- Next message (by thread): [atlas] ATLAS as mechanism for route policy discovery
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Leo Bicknell
bicknell at ufp.org
Mon Apr 23 15:59:15 CEST 2012
In a message written on Mon, Apr 23, 2012 at 03:31:48PM +0200, Philip Homburg wrote: > Looking into it. Client ID or Vendor Class? You are not supposed to set > Client ID to something generic because it has to unique identify the > device. Vendor Class is safe. Client ID is what most of the home gateways present. I can think of three ways it could be done: 1) Just use "ripeatlas" or a similar fixed string, and yes, there will be "collisions". Plenty of other devices use this method and they seem to work, although it's not the most RFC-complaint way to do things. 2) Use a fixed string and part of the MAC. I've seen a number of embedded devices use this method. "atlas-12:AB:56" or similar. 3) Actually set it based on the probe ID. I think this would be the coolest option. "atlas-1234" or similar. I would think this could be super-useful for folks setting up and testing more than one probe, since all of the UI references them by probe ID. I've never seen a home gateway display vendor class, but setting it properly would also be a nice thing to do. :) -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20120423/53996b9f/attachment.sig>
- Previous message (by thread): [atlas] Request for RIPE Atlas probe DHCP change.
- Next message (by thread): [atlas] ATLAS as mechanism for route policy discovery
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]