cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1705
Views
0
Helpful
17
Replies

DHCP on 3750

iptrix
Level 1
Level 1

No idea if this is the place to ask, but I cannot figure this out. Got 3 3750's, and a bunch of ME3400 switches. One of the 3750 runs a dhcp server, but the problem is, I keep seeing that it's very, very hard for clients to actually get an IP. Sometimes they do, and then it's from the right dhcp scope, so everything appears correct .. only it can take like 10 tries to *get* the dhcpoffer message back to the client.

So I played with the debug function, and saw something interesting ..

Feb 16 21:47:51: DHCPD: DHCPDISCOVER received from client 01e0.91f5.ccc3.7e on interface Vlan00.

Feb 16 21:47:51: DHCPD: Sending DHCPOFFER to client 01e0.91f5.ccc3.7e (95.000.000.000).

Feb 16 21:47:51: DHCPD: Check for IPe on Vlan00 Feb 16 21:47:51: DHCPD: creating ARP entry (95.000.000.000, e091.f5cc.c37e).

Feb 16 21:47:51: DHCPD: unicasting BOOTREPLY to client e091.f5cc.c37e (95.000.000.000).

First 2 mentions of the mac address looks .. weird. Second 2 rows shows it differently. Is THIS why the dhcp server has such a hard time reaching back to the clients? I see from the debug log that it gets more or less all the requests. However using packet sniffers, I can see that the replies very seldom gets to the clients.

So what's going on? And why does the mac address look as above? I believe I'm running advancedipservices 12.2(44) on the 3750 that's the dhcp server atm, but I have no idea if this IS the problem :/ Been trying almost everything.

/Micke, Sweden.

17 Replies 17

Reza Sharifi
Hall of Fame
Hall of Fame

Can you post the config for the 3750?  Also, can you provide a diagram on how all devices connect together?

Actually, for all practical purposes, they are in a straight line.

3750(T24) <-> 3750(F12) <-> 3750(F12) <-> 3400#1 .... 3400#18

Yes, it really is 18 of the switches on a single string. I didn't make it .. I just said "sure, I can help" at a bad moment to a friend ;.)

As for the config, well .. of which? Idea is to have vlan 10 as administrative, with 10.10.x.y IP's, and the vlan in question here is 14, the customer one. I have actually removed a lot of protection in the last version; to eliminated what I thought might muddy the waters - but no luck. Here are some highlights:

3750(T24, dhcp/core router)

ip subnet-zero

ip routing

ip domain-name br.se

ip dhcp database flash:/dhcp.db

ip dhcp relay information trust-all

ip dhcp excluded-address 10.10.0.1 10.10.0.9

!

ip dhcp pool Noncustomer

   network 10.1.0.0 255.255.0.0

   dns-server 10.1.0.2

   domain-name br.se

!

ip dhcp pool Brf1

   network 95.1.1.0 255.255.255.128

   default-router 95.1.1.1

   dns-server 79.1.2.3 79.1.2.4

   domain-name br.se

!

ip dhcp pool Brf2

   network 95.1.1.128 255.255.255.128

   default-router 95.1.1.129

   dns-server 79.1.2.3 79.1.2.4

   domain-name br.se

!

ip dhcp pool Brf3

   network 95.1.2.0 255.255.255.0

   default-router 95.1.2.1

   dns-server 79.1.2.3 79.1.2.4

   domain-name br.se

!

ip dhcp pool Brf4

   network 95.1.3.0 255.255.255.0

   dns-server 79.1.2.3 79.1.2.4

   domain-name br.se

   default-router 95.1.3.1

!

interface range GigabitEthernet1/0/1 - 2

description Trunk to Switch

switchport trunk encapsulation dot1q

switchport mode trunk

ip arp inspection trust

ip dhcp snooping trust

exit

!

interface Vlan10

description Admin

ip address 10.10.0.1 255.255.0.0

ip broadcast-address 10.10.255.255

!

interface Vlan14

description Brf4

ip address 95.1.3.1 255.255.255.0

!

-------------------

The other 3750's are just switches .. all trunk lines, all trunk lines have all vlans too atm.

The ME3400 that are the customer switches are like:

ip subnet-zero

no ip domain-lookup

!

ip dhcp snooping vlan 14

ip dhcp snooping database flash:snooping.db

ip dhcp snooping

!

no file verify auto

!

spanning-tree mode rapid-pvst

spanning-tree portfast default

no spanning-tree optimize bpdu transmission

spanning-tree extend system-id

!

interface range FastEthernet0/1 - 24

description Customer port

switchport access vlan 14

switchport block multicast

switchport port-security maximum 5

switchport port-security

switchport port-security aging time 30

switchport port-security violation restrict

switchport port-security aging type inactivity

ip arp inspection limit rate 100

ip dhcp snooping limit rate 100

!

interface GigabitEthernet0/1

description Uplink

port-type nni

switchport mode trunk

ip dhcp snooping trust

!

interface GigabitEthernet0/2

description Downlink

port-type nni

switchport mode trunk

ip dhcp snooping trust

!

interface Vlan10

ip address 10.10.0.40 255.255.0.0

no ip route-cache

no ip mroute-cache

!

interface Vlan14

no ip address

!

Jeff Van Houten
Level 5
Level 5

18 in a straight line with no cross connects? It's a little long in the tooth but someone needs to google the 5-4-3 rule.

Sent from Cisco Technical Support iPad App

So in your opinion, this is a valid reason for 9 of 10 dhcp attempts not reaching the client from the server? Mind you all make it *to* the server, far as I can tell.

/Micke

I would bet it's a timing issue. While you don't have the collision domain problem the 5-4-3 rule was created to address, you still have a BROADCAST domain issue. broadcasts have to be propagated across all those uplinks between switches and Across every port in the subnet. I think I would try to flatten the network with a few core switches and connect the others to the cores. I would bet you problem goes away.

Thanks,

Jeff Van Houten

Vice President &

Chief Technology Officer

First Bank and Trust

909 Poydras St.

Suite 3300

New Orleans, LA 70112

www.fbtonline.com<>

"Your Goals Come First"

Well I can't do much about the topology of that place, it's a linear collection of houses .. would require extensive digging to shift into more of a star pattern than the current linear layout. I don't mind the odd missed packet, but this is ONLY for dhcp, and it's like 9 out of 10 .. or worse. The mere fact that there's 18 switches - most of them with 0-2 connected ports - cannot explain this, it feels to me. However, I'm not a network hardware designer.

Once people manage to get their IP, it's working as nicely as you can desire. I just have to solve it, maybe I ought to turn to crystals, magnets, and people chanting "ommm" next ./

Btw .. noone had any comment on the weird mac format, the "01" being prepended?

/Micke

Houses connected together? Are these all on the same subnet?

Sent from Cisco Technical Support iPad App

All 18 switches are really only using the administrative vlan (for me to reach the switches), and one Client vlan. The client vlan is a dhcp /24 network, really the most simple configuration you could imagine.

I understand that there's a slight problem with broadcasts with 18 linear switches in the same vlan, but the broadcast itself appears to work! It's the unicast back to the client that seems to disappear. So I'm none too eager to put this down as a broadcast issue for that reason.

/Micke

Hi,

is the client receiving these unicasts? can you sniff the NIC of the client and post the capture file.

Regards.

Alain

Don't forget to rate helpful posts.

Hi,

noone had any comment on the weird mac format, the "01" being prepended?

this is not a MAC address but a client identifier constructed by prepending a media type( here 01 for ethernet or 802.11) to the MAC address.

Regards.

Alain

Don't forget to rate helpful posts.

Well, it's confusing me. If I look at the dhcp bindings on the router, these appear with different formats. I don't understand why this is happening:

95.1.3.2     c0c1.c0af.6d0f          Feb 17 2012 04:09 PM    Automatic

95.1.3.151   015c.d998.bfbe.cb       Feb 18 2012 10:13 AM    Automatic

95.1.3.157   0100.2436.9d29.ac       Feb 18 2012 07:21 AM    Automatic

95.1.3.159   0021.9401.a7c3          Feb 18 2012 06:26 AM    Automatic

95.1.3.188   01a0.21b7.bad7.ff       Feb 18 2012 09:29 AM    Automatic

95.1.3.190   0021.9401.8023          Feb 18 2012 12:48 AM    Automatic

Some of the hardware addresses are 01-prepended, and others are not? Believe me, they are ALL on ethernet.

/Micke

Hi,

It depends of host implementations.

Regards.

Alain

Don't forget to rate helpful posts.

Ok, what? Which hosts are we talking about, my 18 ME3400 switches, or my 3 3750 switches, one of which acts as the router and dhcp server? That answer you wrote seems to imply that I've done something, but I am not aware of that. I thought I had the entire chain under my control, but you say "it depends on host implementations"?

What does that mean? Can the computer at a certain customer in, say, house #7 here, influence that the "01" is prepended in the router arp table? And if so why isn't that done for the lady living next door to the first customer?

I really need help and I know I shouldn't try to understand *everything* but some answers really aren't. And it still has nothing to do with my original problem: why is like 9 out of 10 replies from the DHCP server back to the client *eaten* on the way? Or rather - why is the 1 out of 10 making it?

Hi,

I'm just answering your questions about the different hardware addresses referenced in the dhcp binding database,

I know it has nothing to do with your dhcp offers not being followed by dhcp requests but you were also asking about these hardware addresses.Now  let us just focus about the dhcp packets not being replied.

As I said before are these dhcp offers making it to the clients( if you look at the OUIs from the MAC , you'll see in their database that you have Apple, Dlink,Netgear NIC cards trying to get an IP address via DHCP)  ? sniff to see if they are received and also if not then do a SPAN session on each switch to see where the problem is residing.

So all these clients they have their IP leased by the server and if you look at the original debug of dhcp server packets

you have a Netgear NIC requesting an address and if you look at this:

Feb 16 21:47:51: DHCPD: DHCPDISCOVER received from client 01e0.91f5.ccc3.7e on interface Vlan00.

Feb 16 21:47:51: DHCPD: Sending DHCPOFFER to client 01e0.91f5.ccc3.7e (95.000.000.000).

2 things are puzzling me: first the broadcast frame is received on VLAN0 and the address leased is not a valid one( it is a subnet address not a host address.

Can you do a debug ip dhcp server events and a debug ip dhcp server packet and also post sh  ip dhcp snooping database and sh ip arp inspection

Can you also tell us if it is a problem tied to a specific client.

Regards.

Alain


Don't forget to rate helpful posts.
Review Cisco Networking products for a $25 gift card