DHCP Relay Bug?

[Jason Scott]

Are there any known issues with DHCP Relay? We're currently migrating to 8200s in our core and have started to experience some very strange issues with some vlans and clients unable to obtain DHCP addresses. Yet other vlans that use the same physical paths are working fine.

If I issue 'show dhcp-relay' no stats are showing for client requests and server responses. All in all, very strange.

[cenk sasmaztin]

hi Jason
please send me sh tech command

cenk

[Jason Scott]

Thanks, did you want show tech or show conf? The tech file is pretty big :)

I've tried adding the dhcp relay option 82 append command and we are now seeing statistics under 'show dhcp relay'. I'm going to test client dhcp in the next hour.

[Jason Scott]

Here is show tech.

[Pieter 't Hart]

hi Jason,
several interfaces have ip-addresses, but there is none in the same subnet (10.177.20.0) as the ip-helper (10.177.20.19)!
so the dhcp-server has no return path!

ip address 10.177.25.254 255.255.255.0
ip address 10.177.12.254 255.255.255.0
ip address 10.177.10.254 255.255.255.0
ip address 10.177.11.254 255.255.255.0
ip address 10.177.17.253 255.255.255.0
ip address 10.177.13.254 255.255.255.0
ip address 10.177.14.254 255.255.255.0
ip address 10.177.19.254 255.255.255.0
ip address 10.177.15.254 255.255.255.0
ip address 10.177.16.126 255.255.255.128
ip address 10.177.18.254 255.255.255.0
ip address 10.177.7.62 255.255.255.192
ip address 10.177.27.254 255.255.255.0

regards , Pieter

[Jason Scott]

Hi, its misleading as you're only seeing the configuration from one of our 3 core routers. The layer 3 interface for the DHCP server vlan (20) resides on another router, with vlan 20 spanned at layer 2 across the uplinks.

If I take a client that is having dhcp issues and give it a static ip address I have full ip connectivity to the dhcp server and other subnets. This indicates routing is ok.

[Pieter 't Hart]

try setting speed and duplex of the switchport as fixed.
it may be the port still negotiates this while pxe allready sent its dhcp request wich times out.

[cenk sasmaztin]

hi Jason
please test for me

one pc connect on vlan 1 (port A1)and assign ip address on pc

ip address 10.5.1.22
default gateway 255.255.255.0
subnet mask 10.5.1.2

after you make ping to 10.177.20.19 on pc

if unsuccessfull pinging you can run on pc traceroute command to 10.177.20.19

and please say me result

cenk

[Jason Scott]

Unfortunately this is a production network so some testing is difficult in hours. Vlan 10.5.1.x is our management vlan for switch ip addresses.

We've been speaking with our support at HP on this as well and they believe a bug in firmware 13.09 may be the cause and have advised us to revert back to v12.xx.

[cenk sasmaztin]

hi jason
as for me your problem cause routing

you can return k12xx software
if continue issue plese talk to me



not:
vlan 1 not managemet vlan on your switch
only name managemet vlan

managemet vlan for security manage
managemet vlan declare on switch with
<(config)#managemet-vlan 1 >command and unable routing managemet vlan

I pass over in sh tech management-vlan 1 command

[Jason Scott]

Thanks Cenk. I realised this recently but I'm not unsure of the impact were we to enable the management-vlan command. OSPF utilises addresses in vlan 1 for routing.

[cenk sasmaztin]

hi Jason
so please erase management-vlan 1 command on switch

and please make my ping and tracert test

cenk

[Jason Scott]

Hiya,

I can do this on any of our edge switches as they all have 10.5.1.x addresses. They can ping 10.177.20.19 fine. Traceroute output is:

L5NR_2626PWR.1# trace 10.177.20.19
traceroute to 10.177.20.19 ,
1 hop min, 30 hops max, 5 sec. timeout, 3 probes
1 10.5.1.1 0 ms 0 ms 0 ms
2 10.177.20.19 0 ms 0 ms 0 ms

[cenk sasmaztin]

are continue same issue..

[Evert Goor]

Just before i go further can you tell me what vlans are bugging ?

[Jason Scott]

Well that's the strange thing about this problem. Its random and sometimes clients are ok and sometimes not. Currently we've got issues with vlan 67 and 31.

Another development has been that some clients are having difficulty properly resolving DNS names, but testing on other clients in the same subnet works! Our of desperation I enabled ip directed broadcasts and those clients with problems immediately resolved the names. Based on what I know of this command however I'm not sure why it would fix it.

I don't think our issues our resolved with that one change. There's something else going on that we can't track down.