slow DHCP-"Forwardings"

[MaEh]

Hello Together,

we are planning to boot our clients with pxe-images in our network environment (OS6900s as cores, mostly OS6860 and some older 6850 as client-switches). In our first tests, we noticed, that DHCP is a litte bit slow in the pxe-process.

So I build a test with one OS6450-P10, on which a Test-DHCP-Server (MS Server 2012 R2) and a test client are directly connected. The test-scenario is less complex so we can exclude problems with ip helper or someting.
On both sides, I installed wireshark (on the server-side directly, on the client side with the help of a port mirror) and synced the clocks for better comparison. The OS6450 is nearly unconfigured (except the port mirror).

As you can see, I made 3 tests and every time, the first DHCP-Discover from the client doesn't reach the Server:

Wireshark-Log (Client-Side)

MS-DHCP_OS6450_ClientMirror.png

Wireshark-Log (Server-Side)

MS-DHCP_OS6450_Server.png

The second test, I made was, to use a cheap unmanaged LevelOne-Switch between the server and the client. Here I made a second mysterious discovery: the times between the Offer and the Request are every time only 4 seconds. With my OS6450, these times are always 8 seconds.

MS-DHCP_CheapSwitch_Server.png

Can anyone explain (or has an idea), why the first discover-packets are dropped every time and why the times between the offer and the request are much better with the cheaper switch?

Thanks and best regards
Markus

[silvio]

try to set forward delay to zero:
ip helper forward-delay 0

regards
Silvio

[devnull]

What i understood is that DHCP Server and Client are in the same VLAN, so ip helper should not be triggered?
Still it might be possible, that the first packet is (wrongly?) trapped to CPU and then disappears?

Do you have a ip helper config (please post your config)

Otherwise open a SR and let us know about results.

[MaEh]

Hi together,

I've tested a few more things today. As expected, setting the ip helper forward-delay to 0 doesn't change anything. I also enabled pxe-support, but this doesn't change anything, too (this is also a ip-helper specific command and normally, the problem shouldn't be affected by ip helper because of the same vlan).
After that, I updatet the OS6450-P10 to the latest Firmware (6.7.2.94.R02), but no changes.

My next try was, to use a unconfigured OS6860E-P48 (8.3.1.130.R02) - in this constellation, the times between DHCP Offer and Request are as bad (8 second) as with the 6450-P10. I don't see the dropped first Discover, but I think this has to do with the mirror port. My feeling was, that the first Discover comes to late.

After that, I plugged a old Network Hub between the PXE-Client and the OS6450-P10 (DHCP-Server <--> OS6450-P10 <--> Network-Hub <--> PXE-Client). In this constellation, all works fine and the times between the DHCP-Packets are as short as with the cheap switch - totally mysterious.

best regards,
Mrkus

[MaEh]

Hi,

together with silvio, we found the solution.

First of all: the longer time between the Offer and the Request with the Alcatel-Switch ist a result of the first dropped discover. The PXE-Client only becomes an answer to his second Discover and so he waits longer for the Request.

So the only Problem was, where the first Discover was gone. We found out, that SpanningTree is the Problem in this case and it should only appear, when the Client starts fresh (as it is normally with pxe). When a cheaper Switch was between the Client and the Alcatel-Switch, the Port was is long enough to be declared as edge-port. In the normal Scenario, the port first is in OperationStatus LIST and in this time, the first Discover was send from the Client but not forwarded by the Alcatel-Switch:

Code: Select all

-> show spantree ports active
Brdge  Port  Oper Status  Path Cost  Role
-----+------+------------+---------+-------
    1  1/1       FORW           4   DESG
    1  1/6       LIST          19   DESG

-> show spantree ports active
Brdge  Port  Oper Status  Path Cost  Role
-----+------+------------+---------+-------
    1  1/1       FORW           4   DESG
    1  1/6       FORW           4   DESG 

Code: Select all

-> show spantree cist ports active
Spanning Tree Port Summary
        Oper  Path   Desig        Prim.   Op  Op  Loop
Port     St   Cost    Cost   Role Port    Cnx Edg Guard  Desig Bridge ID        Note
-------+----+-------+-------+----+-------+---+---+------+----------------------+------
  1/1/1 FORW   20000       0 DESG   1/1/1 PTP EDG  DIS   8000-2c:fa:a2:16:b2:43
 1/1/12 LIST   20000       0 DESG  1/1/12 PTP  NO  DIS   8000-2c:fa:a2:16:b2:43
 
 -> show spantree cist ports active
Spanning Tree Port Summary
        Oper  Path   Desig        Prim.   Op  Op  Loop
Port     St   Cost    Cost   Role Port    Cnx Edg Guard  Desig Bridge ID        Note
-------+----+-------+-------+----+-------+---+---+------+----------------------+------
  1/1/1 FORW   20000       0 DESG   1/1/1 PTP EDG  DIS   8000-2c:fa:a2:16:b2:43
 1/1/12 FORW   20000       0 DESG  1/1/12 PTP EDG  DIS   8000-2c:fa:a2:16:b2:43

Normally, the ports are working with auto-ptp, but in this configuration, the port is "blocking" to long at the boot process. So you have to configure the port as "every-time-ptp":

Configuration Example (Flat-Mode) for AOS6 (in my Example OS6450-P10):

Code: Select all

bridge 1 1/8 connection ptp
bridge cist 1/8 admin-edge enable

Configuration Example (Flat-Mode) for AOS8 (in my Example OS6860E-P48):

Code: Select all

spantree cist port 1/1/8 admin-edge enable
spantree cist port 1/1/8 connection ptp

best regards and thanks for the help
Markus