While trying to setup the DHCP for giving IP addresses to ATCA devices in a crate I came across something which I am wondering about.
For the shelf managers the IAID (Lan Channel ID) is set to 0h.
For the CERN IPMC I was expecting the same and instead got 4h.
I was wondering if you could give me an explanation about why it is 4h.
Also can we assume that any IPMC which is compliant to the standard would use the same Lan Channel ID ?
For a board controller for example (a zynq), should the same be used ? I guess this depends a bit on the explanation for 4h.
We will need to consistently be able to respond to any boards/IPMCs that are in an ATCA crate so the answer to these questions are very important for the infrastructure.
When you arrive at n = 5, it tells you that this is a LAN channel. But as Stefan said for the CERN-IPMC the LAN channel number is always 5. I was just wondering what you are trying to achieve …
You can subsequently also use the following to see the LAN parameters, e.g. IP address and which source was used to obtain the IP address:
When you arrive at n = 5, it tells you that this is a LAN channel. But as Stefan said for the CERN-IPMC the LAN channel number is always 5. I was just wondering what you are trying to achieve …
You can subsequently also use the following to see the LAN parameters, e.g. IP address and which source was used to obtain the IP address:
OK so I was maybe not very specific in my initial post. Let me clarify.
In CMS the plan is to use ClientID to be able to get IP addresses from devices in the ATCA chassis and follow the HPM.3 spec. for this.
The format for the ClientID string according to the HPM.3 standard is (as seen in the DHCP request once header and data length are removed): ff: # Type 00:00:00:04: # IAID; "IPMI Lan Channel Index" XX:(x39) # DUID: DHCP Unique Identifier
The field which is causing us issues is the IAID one.
When the shelf manager is set to do DHCP with ClientID that field is 0h (all zeros).
I naturally assumed that the IPMC would therefore also use 0h.
As I wrote before the value is 4h for the CERN IPMC. Why is it not 0 ?
I do not have access to other IPMCs so I can say what those are using.
As we need to be able to provide the DHCP configuration for all possible crates/boards in the CMS network, we need to know that this will be the same for all IPMC manufacturers. Is that the case ?
The same goes for all boards and their Zynq controllers. Should they use 0h or the same as the IPMC ?
You understand that if the value can be “anything” it will be chaos if not impossible to have a DHCP config which works for all boards in P5.
the behavior of the CERN IPMC is consistent, since the value of 4 in the LAN channel index in the client ID corresponds to the IPMI channel number of 5. Though the numbering is implementation specific, but there are some recommendations in the HPM.3 standard, see section 2.6.1 and tables 2.9 and 2.10.
Also note the following quote from the HPM.3 specification:
In order to find out what our current situation in the ATLAS L1CT concerning DHCP Client ID is, I have been sniffing the DHCP requests from our modules (LTIs, IPMCs, and SHMM) in one shelf.
Here are the results for the Client IDs used for DHCP:
SHMM and IPMC use a Client ID conformat with HPM.3. The SOMs do not (yet?)
The SHMM Lan Channel index is “0”, the IPMC one “4” as discussed earlier.
The Shelf address is shown as “shmm-lti-10” which is what had been programmed into our SHMM.
The Slot locations correspond to primary site type “Dedicated ShMC” for the SHMM and “Front Board” for the IPMCs - as expected.
The Primary site number is 0 for the SHMM and 7, 11, and 4 for the IPMCs, which coincides with their slot numbers in the shelf.
The SoM shows the shelf address correctly, the site type as 0 (=Front Board) and the site number as 11 (corresponding to its slot number), which is correct. In our case, the DHCP protocol is only used once during boot from U-Boot, and never from Linux while running. This may have to be addressed.
Please let me know if you have any comments.
I suggest to have a meeting, maybe in a week or two?, to discuss any open issues on DHCP Client ID and HPM.3 …
Thank you for your feedback.
Your findings for the Shelf manager and IPMC in the different slots is exactly what we see also. So that is good news.
For the SOM, as Per indicated in a separate thread with you, we have a version which is HPM.3 compatible and it basically looks like the IPMC except that the secondary site and number are different (we have chosen for CMS, oem numbers for those and specified this as our baseline).
Yes having a discussion in 1-2 weeks would be great.
Many thanks for checking these settings on your side.
Just one more thing before we will have our meeting next week. In a discussion with Stefan, we realized that the HPM.3 client ID is based on the location of the module - which is the exactly big advantage of using Client ID.
But it is actually ONLY based on location! There is no more blade-specific information in it. So, whatever blade you push into the shelf, it will get a ClientID defined by the Shelf address and the slot location. Is this what we want? Do we not want to check if the blade type is compatible with the shelf (and the slot) it is being pushed into?
Is that what you intend to use the secondary Site Type and Site Location for?
I am just wondering if we are not missing something fundamental. In the end, we may need location and board information combined in order to provide correct functioning.