[ipxe-devel] Adding lldp-agent to ipxe

[Robin Smidsrød]

On 12.09.2013 12:05, Thomas Mieslinger wrote:
> #!ipxe
> cpuid --ext 29 && set arch x86_64 || set arch i386
> :retry_dhcp
> dhcp net0 || goto retry_dhcp
> set filename
> http://\${gateway}/ipxe/assimilation/boot?mac=\${net0/mac}&manufacturer=\${manufacturer:uristring}&product=\${product:uristring}&serial=\${serial:uristring}&arch=\${arch}
> 
> echo mac: \${net0/mac} ip: \${net0/ip}
> echo manufacturer: \${manufacturer} product: \${product} arch: \${arch}
> echo serial: \${serial}
> chain \${filename} ||
> ifstat net0
> echo Booting \${filename} failed, dropping to shell. Type reboot to reboot.
> shell
> 
> The server script returns a default boottarget based on vendor, 64bit
> capability.
> 
> The server script also generates an overview page where one can see
> which computers are under assimilation.
> 
> It would be helpful for that overview page if I could display the
> switchport right away.

I see your use-case. As a workaround, you should be able to poll your
switch for it's arp information to figure out which port it is connected
to. Most managed switches have a way to query it's arp-to-port
association. If you have a bunch of switches then that'd be a bit heavy
and getting LLDP into ipxe is definitely less communication-heavy.

> So for me, I'd just need PortID and PortDescr. But for other uses, I
> guess that ChassisID, SysName and SysDescr could be useful.
> 
> For naming ipxe variables, I'd propose the trick to compose the name of
> a prefix and the original variable name. Example: lldp-PortDescr which
> then would be used as ${net0/lldp-PortID:uristring}.

Generally, variables should be as short as possible, and we only use
lower-case, and usually no form of delimiters. I'd also introduce a
scope called lldp under the network interface. Something like this could
make sense: net0.lldp/lldpport (instead of portid),
net0.lldp/lldpportname (instead of portdescr).

If LLDP is implemented similar to DHCP in its data structure, it would
be advisable to implement the settings scope in a way that you can pull
out arbitrary information using numbered values, much like the pci
settings scope does it.

I'm not exactly sure how quickly the LLDP information is available, and
what kind of communication must be performed before it is available.
Since iPXE is written to communicate completely async, you might need to
also implement a command to query lldp information and wait for it to
either be available or time out. To me it seems quite similar to the way
dhcp command is architected, but I might be wrong. Some of the core devs
might have more insight on this.

> Ok, so the next step would be wait for the approval of the variable
> names and then to propose a patch.

Michael: Anything to add?

-- Robin