I was actually playing with DHCP relay and what I did find out is kind of interesting. For what is DHCP relay look for rfc3046 .
In short it is when the client sends a DHCP a broadcast message (discover) some device – usually the switch that is the client directly connected to – intercepts the packet and sends a unicast discover instead of it to remote server over L3. The advantage is that the amount of boadcasts in the networks drops and secondly the DHCP server can be in different subnet. This is great because you can now use centralised dhcp server for all networks.
But this advantage of using the single DHCP brings one big problem – user identification. The unicast relay will use the appropriate IP (usually a gw or the subnet) but if you need more more information about the supplicant that is where option 82 of DHCP comes to play.
In short the DHCP option 82 is here to convey some additional and more detailed user-related information to the DHCP server. The definition by ietf is very vague and the content of the fields is vendor-specific. What must be said is that option 82 has two most widely used sub-options: “agent circuit id” sub-option and “agent remote ID”
The basic structure of option 82 by ietf looks like this:
agent circuit id SubOpt|Len|Circuit ID +——+——+——+——+——+——+——+——+– | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | … +——+——+——+——+——+——+——+——+–
and for the other sub-option it is defined this way
agent remote id SubOpt Len Agent Remote ID +——+——+——+——+——+——+——+——+– | 2 | r | r1 | r2 | r3 | r4 | r5 | r6 | … +——+——+——+——+——+——+——+——+–
This seems like a pure theory with no real information inside so lets have a look at some real stuff.
Option: (t=82,l=18) Agent Information Option Option: (82) Agent Information Option Length: 18 Value: 01060004000A00000208000600E0FC490D22 Agent Circuit ID: 0004000A0000 Agent Remote ID: 000600E0FC490D22
This is a real capture from WireShark for Huawei switch S3900 with option 82 enabled. In this case while using standard, pre-defined values for the sub-options, sub-option 1 receives L2 port No. of the packet and vlan No.; whereas sub-option 2 receives MAC address of the packet device.
In our case it is the received string deciphered like this:
01 06 00 04 000A 0000 02 08 00 06 00E0FC490D22 01–CIRCUIT_ID 06–length ( “00 04 0005 0080″ length) 00–CIRCUIT_ID type 04–length ( “0005 0080″ length) 000A–vlan No. (10 in dec.) 0000–global port No. 02–REMOTE_ID 08–length (”00 06 00E0FC6AE332″ length) 00–REMOTE_ID type 06–length 00E0FC490D22–system bridge MAC
In this case everything is seems to be quite clear. But there is a catch – the global port number. It’s value is counted by this formula:
52*slotnumber (0) + present port index (0) = 0
Note that in huawei’s case:
- the port index starts from 0
- the constant is different for various devices and is probably connected to maximum numbers of ports in one slot or card (I was unable to verify why the number is different
So this means that global port 0000 is actually port 1/0/1 in VRP command line.
Ok that was the light stuff but what if the S3900s are in stack? How the global port number will be influenced?
For S3900 it is like this:
01 06 00 04 000a 016d = 365 (in dec) 02 08 00 06 00e0fc490d22 52*slot number (7) + present port index (1) = 365
The slot number is actually the number of the device in the stack starting from 0 as the port.
So this is complete explanation of S3900’s with basic configuration of option 82. It is necessary to say that if you have some special wishes for data transmitted in the string you can configure some (e.g. sysname instead of mac address, etc.). This option is possible only in newer VRP versions. When it is configured this information will be transmitted instead the MAC address value.
There is one more interesting thing – the gigabit ports are not distinguished in the formula for the port index number so even thou you have interface GigabitEthernet 1/1/1 the port index is using follow up numbering eth 1/0/48 (last FE interface) equals port index 47 and gig 1/1/1
There is one exception – S6503
This switch is kind of old and the software is working differently. Especially it is not possible to change any content of the last fields – so only MAC address can be transmitted as an identifier. The other thing to know is that the constant in the formula is not 52 but 48 so the global port number is counted like this:
48*slot number + present port index = global port number
In this case
- the slot numbering starts from 1
- the port index starts from 0
The default behavior of option 82 is different across devices and vendors. In order to decode/use it properly on the dhcp server you need to obtain the right documentation or play guessing game with WireShark but hopefully the example above could be of some use in what direction should you take if you decide to do the investigation yourselves or if there is no documentation available.