This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[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: </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 ]