DHCP Snooping eats messages to a switch later in the chain ..

[iptrix]

I have a problem at a place where 5 ME3400 switches are connected in a straight line. I can't do much about the topology of that place, but the problem is they are all DHCP Snooping, but unicast replies from the dhcp server further up the hierarchy gets eaten by the first switch! I can't really see why it not only inspects in and whines about it not being for itself - it then drops the message.

What have we done wrong (apart from the actual layout of that place, which I can't really change)?

Sep 28 13:49:29: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/1)

Sep 28 13:49:29: DHCP_SNOOPING: process new DHCP packet, message type: DHCPOFFER, input interface: Gi0/1, MAC da: 7444.012d.debd, MAC sa: 0013.1a4a.65c7, IP da: XX.YY.186.7, IP sa: XX.YY.186.1, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: XX.YY.186.7, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 7444.012d.debd

Sep 28 13:49:29: DHCP_SNOOPING: binary dump of option 82, length: 20 data:

0x52 0x12 0x1 0x6 0x0 0x4 0x0 0xE 0x1 0x9 0x2 0x8 0x0 0x6 0xB4 0x14 0x89 0xA0 0xB9 0x0

Sep 28 13:49:29: DHCP_SNOOPING: binary dump of extracted circuit id, length: 8 data:

0x1 0x6 0x0 0x4 0x0 0xE 0x1 0x9

Sep 28 13:49:29: DHCP_SNOOPING: binary dump of extracted remote id, length: 10 data:

0x2 0x8 0x0 0x6 0xB4 0x14 0x89 0xA0 0xB9 0x0

Sep 28 13:49:29: DHCP_SNOOPING_SW: opt82 data indicates not a local packet

Sep 28 13:49:29: DHCP_SNOOPING: can't parse option 82 data of the message,it is either in wrong format or not inserted by local switch

Sep 28 13:49:29: DHCP_SNOOPING_SW: lookup packet destination port failed to get mat entry for mac: 7444.012d.debd

Sep 28 13:49:29: DHCP_SNOOPING: can't find output interface for dhcp reply. the message is dropped.

It really should just send it on, as with any unicast not on the switch itself - it should go out Gi0/2 really. Why isn't it?

[core] -- [sw1] -- [sw2] -- [sw3] -- [sw4] -- [sw5]

All the trunks are trusted, DAI is on (I've tried shutting it off, as well), port-security is used but it's actually not dying on the switch having the client computer, but the first one in the chain with dhcp snooping.

/Micke

[dominic.caron]

Look's like you have an option 82 problem. Try this on your switchs.

ip dhcp snooping information option allow-untrusted

[iptrix]

Unfortunately, that isn't an option since the switches are *user* switches, in a chain. I cannot use that option since it would allow option 82 from user ports. It's a global setting, not a per-port one.

/Micke

[dominic.caron]

is the port between you switch in a dhcp trusted state?

[iptrix]

Yes, which I did write ;-p Up- and downlinks both are trusted (all trunks, in fact). No split paths, it's all one big chain.

/Micke

[iptrix]

Come on :/ Someone must have seen it .. it's the unicast replies that don't make it back to the client switch, because of the "the message is dropped." - it's not being forwarded as a layer 2 message should.

Probably because the switches between the dhcp server and the dhcp clients switch do not add the dhcp client to the mac address table from the dhcpdiscover broadcast :/

[iptrix]

I feel I have to bump this -- I keep seeing this issue, and I don't know how to fix it

If I have 2 "customer" switches, each with dhcp snooping active, chained, dhcp messages that are unicasted are intercepted by the first switch, and when it determines it's not for this switch, it tries to resend it, but since it doesn't know the address (the mac address in the unicast address), the message dies.

If the dhcp message, however, is multicast it works. But problem is a lot of end-user home routers specifically ask for unicast replies, and the dhcp server adheres to that, meaning that computers can get dhcp on the second switch easily, but routers just fail.

How do I fix this? I still want dhcp snooping but I have to have these switches "in line" at this place :/

/Micke