DHCP 30s delay

djay_cdxi · ‎07-15-2019

Our server team advise us to check the L2 switch on the issue that the DHCP server running in windows has a 30s delay when leasing an IP address to a workstation. Connection is only through local area network. The DHCP server and the workstation are connected to an L2 switch. All in the same VLAN which is the default.

Average branch has 10 devices/workstation and there are branches that only 2 or 3 workstation that encounter the delay. There are also branches that all workstation encounter the delay and there are branches that do not experience any delay on their workstation. We have around 100+ branches and so far there are 26 confirmed branches that experience this problem. Switch configuration is the same for all switches. I was advise to implement portfast on all access port since we have a pvst spanning tree configured on the switch.

Question: If we implement portfast, why does other workstation/branches doesn't experience the same problem given that all switches has no portfast configured on all ports? How do we resolve this?

lpassmore · ‎07-15-2019

Please do a double check that the 'other workstation/branches' don't have portfast default on as a global command or if they are maybe running Rapid PVST+

djay_cdxi · ‎07-15-2019

This is a sample branch switch that 3 of their workstation encounter the problem.

Switch#sh spanning-tree summary
Switch is in pvst mode
Root bridge for: none
EtherChannel misconfig guard is enabled
Extended system ID           is enabled
Portfast Default             is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default            is disabled
UplinkFast                   is disabled
BackboneFast                 is disabled
Pathcost method used         is short

Name                   Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001                     0         0        0         15         15
---------------------- -------- --------- -------- ---------- ----------
1 vlan                       0         0        0         15         15

Jaderson Pessoa · ‎07-15-2019

Hello,
Please share the result of the commands below;
show spanning-tree summary
show running-config

Jaderson Pessoa
*** Rate All Helpful Responses ***

djay_cdxi · ‎07-15-2019

This is a sample branch where only 3 workstation encounter the delay.

Switch#sh spanning-tree summary
Switch is in pvst mode
Root bridge for: none
EtherChannel misconfig guard is enabled
Extended system ID           is enabled
Portfast Default             is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default            is disabled
UplinkFast                   is disabled
BackboneFast                 is disabled
Pathcost method used         is short

Name                   Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001                     0         0        0         15         15
---------------------- -------- --------- -------- ---------- ----------
1 vlan                       0         0        0         15         15

Jaderson Pessoa · ‎07-16-2019

great, just apply commands below and test again;

sw(config):# spanning-tree portfast default
sw(confiug:# spanning-tre bpdu guard

Jaderson Pessoa
*** Rate All Helpful Responses ***

djay_cdxi · ‎07-16-2019

Thanks but would you know why spanning-tree would is not running on certain ports?

Jaderson Pessoa · ‎07-18-2019

maybe spanning-tre has portfast enable under some interface.

Jaderson Pessoa
*** Rate All Helpful Responses ***

Philip D'Ath · ‎07-15-2019

I would make all ports facing towards clients access ports with port fast enabled.

djay_cdxi · ‎07-15-2019

Thank you for your reply. Can you explain why other workstation/branches doesn't experience delay given that their access ports don't have a "portfast" configuration? I might be asked by our team lead prior to reconfiguration.

lpassmore · ‎07-15-2019

@djay_cdxi wrote:
Thank you for your reply. Can you explain why other workstation/branches doesn't experience delay given that their access ports don't have a "portfast" configuration? I might be asked by our team lead prior to reconfiguration.

Hi djay

Without configs and more info I don't think anybody can. At a bare minimum we need to see the running configs of your switch that has the problem and the other switch on which several ports do not exhibit the same behavior. Along with this please share which ports on this switch have the issue and which don't.

Then do show interface on one of each.

show spanning-tree interface for one of each

And we might even need some debug information yet.

As a general guide, however, unless you have non-Cisco switches in your environment I think you will find that the best practice recommendation would be to implement RSTP+ or MST on all switches rather than relying upon the old STP protocol. And enable port-fast (edge) on all interfaces except your network (inter-switch) interfaces.

djay_cdxi · ‎07-16-2019

I understand. Sample interface config that has problem.

Switch_A#sh interfaces fa0/18
FastEthernet0/18 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 000d.bc2a.ae92 (bia 000d.bc2a.ae92)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 100BaseTX
input flow-control is unsupported output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 08:15:52, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 9000 bits/sec, 5 packets/sec
5 minute output rate 87000 bits/sec, 5 packets/sec
     331231 packets input, 129836196 bytes, 0 no buffer
     Received 1571 broadcasts (0 multicast)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 331 multicast, 0 pause input
     0 input packets with dribble condition detected
     449429 packets output, 268831404 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out

Switch#sh spanning-tree int fa0/18

Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg FWD 19 128.18 P2p

Switch#sh run int fa0/18
Building configuration...

Current configuration : 34 bytes
!
interface FastEthernet0/18
end

Sample Interface that DO NOT encounter the delay.

Switch_A#sh int fa0/2
FastEthernet0/2 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 000d.bc2a.ae82 (bia 000d.bc2a.ae82)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 7/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 100BaseTX
input flow-control is unsupported output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 2873000 bits/sec, 237 packets/sec
5 minute output rate 126000 bits/sec, 144 packets/sec
     22643032 packets input, 939935799 bytes, 0 no buffer
     Received 4487 broadcasts (0 multicast)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 1170 multicast, 0 pause input
     0 input packets with dribble condition detected
     14459792 packets output, 2495007600 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out

Switch_A#sh run int fa0/2
Building configuration...

Current configuration : 33 bytes
!
interface FastEthernet0/2
end

Switch_A#sh spanning-tree int fa0/2

Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg FWD 19 128.2 P2p

We have the same config on all ports. I have no sample config for cisco switch that do not have this behavior. What I have is an HP Switch.

I can configure the portfast on all access ports given that this is the best practice but the scenario we have is that other ports/switch that does not have portfast configured don't encounter the same problem. All our switches is just L2 device.

As for the identified 4 switches (HP) that has no problem, 2 of which has STP enable and the other 2 has STP disable. I don't see a pattern on the config, common is that no portfast configured on access port.

Appreciate your response given the limited info/config given.

johnlloyd_13 · ‎07-15-2019

hi,

server team most of the time blame it's the network. you'll need to do some basic troubleshooting first.

just to get a background, some questions for you:

is the DHCP server locally installed in the branch? or PC get their IP from the HQ DHCP server?

what switch platform do you use for the branch site? are they all the same or mixed?

can you update the workstation LAN driver or change patch cable?

can you also isolate by configuring a temporary DHCP server on the local switch or router and see if it's still 'slow' in getting an IP?

djay_cdxi · ‎07-16-2019

The 30s delay was seen on the logs by the server team and advise to check on the middle device which is the switch.

DHCP server is locally installed in the branch. Switch is running on a 10/100mbps bandwidth. We are using Cisco, HP access switches. I think we can recommend to update the network driver of the workstation. This will be our next step once I prove that there is no problem/adjustment needed on the network side.

I just find it strange given that we have a standard baseline configuration on the switch, other workstation/branches don't experience the same.

Thank you for your inputs.

lpassmore · ‎07-16-2019

OK, so if I read you correctly, all ports on the Cisco exhibit the 30 seconds delay but only some ports on the HP switches do this. I can't really comment on the HP switches but can say that if spanning-tree is not configured then you will definitely not see the issue and if spanning-tree is configured without some form of port-fast then you will very likely see this issue.

On the Cisco switches you will have to enable portfast to solve this, change timers (bad idea) or turn off spanning-tree (even worse idea); that is just the way they work. By design a port that is participating in spanning-tree will not forward traffic until it has passed through the blocking, listening and learning stages. This, as you have found, takes about 30 seconds or so by default. To test this turn on spanning-tree event debugging while you connect a PC and watch what happens.

The HP switches should work the same way but we would have to get into models, versions and configuration of those if you want to work out why some of those ports don't exhibit the same issue. If I was to hazard a guess it would be that spanning-tree is not running on the ports that are responding quickly.