11-08-2021 03:47 AM - edited 11-29-2021 01:54 AM
Around 6 months ago I successfully set up an ASR901 for DHCP snooping, with option 82 insertion and relay (ip helper). I am certain that it worked because I used it for a couple of hours, with a 5 minute lease time, investigated the option 82 format on the DHCP server side and saved the ASR901 config. At that time the ASR901 was running asr901-universalk9-mz.155-2.S2.bin
Here is the relevant part of the config; a base what I have been working from.
ip dhcp snooping bridge-domain 20 ip dhcp snooping bridge-domain 20 interface GigabitEthernet0/5 description Downlink DHCP port no ip address media-type auto-select negotiation auto ip dhcp snooping bridge-domain 20 information option format-type circuit-id string REDACTEDDD service instance 20 ethernet encapsulation untagged bridge-domain 20
interface TenGigabitEthernet0/0
description Uplink port
no ip address
negotiation auto
ip dhcp snooping trust
service instance 1001 ethernet
encapsulation untagged
bridge-domain 1001
interface Vlan20 description Downling DHCP subnet ip address 10.10.11.241 255.255.255.240 ip helper-address 10.10.10.61 ip helper-address 10.10.10.62 interface Vlan1001 description Uplink vlan towards DHCP server ip address 10.20.20.132 255.255.255.240
Now I need to do this setup again, but now the ASR901 is running asr901-universalk9-mz.156-2.SP9.bin. Now the issue , according to the debug output, appears to be that the ASR is dropping the DHCPOFFER being returned by the DHCP server.
Nov 6 02:49:31.701: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Gi0/5, MAC da: ffff.ffff.ffff, MAC sa: dead.be53.3b46, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: dead.be53.3b46, efp_id: 20, vlan_id: 20 Nov 6 02:49:31.701: DHCP_SNOOPING: add relay information option. Nov 6 02:49:31.701: PURA_DHCP_SNOOPING: Encoding opt82 CID in string format Nov 6 02:49:31.701: PURA_DHCP_SNOOPING: Encoding opt82 RID in string format Nov 6 02:49:31.701: DHCP_SNOOPING: binary dump of relay info option, length: 35 data: ##REDACTED Nov 6 02:49:31.701: _dhcp_snooping_insert_client_mac: interface Gi0/5 sda mac dead.be53.3b46 vlan 20 _dhcp_snooping_insert_client_mac: src 0x11705BB0 efp extra_info_type 1 efp_id 20 phyidb 0xE836A28-GigabitEthernet0/5 efp_type 1 Nov 6 02:49:31.701: PURA_DHCP_SNOOPING: insert host tracking mac dead.be53.3b46 vlan 20 Nov 6 02:49:31.701: PURA_DHCP_SNOOPING: found existing mac dead.be53.3b46 vlan 20 Nov 6 02:49:31.701: PURA_DHCP_SNOOPING: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (20) Nov 6 02:49:31.701: PURA_DHCP_SNOOPING: exclude source cpu port GigabitEthernet0/5 from output portset. Nov 6 02:49:31.701: PURA_DHCP_SNOOPING: bridge packet send packet to cpu port: Vlan20. Nov 6 02:49:31.701: PURA_DHCP_SNOOPING: Split horizon port list : none Nov 6 02:49:31.701: PURA_DHCP_SNOOPING: Updated final port list : none Nov 6 02:49:31.705: DHCP_SNOOPING: process new DHCP packet, message type: DHCPOFFER, input interface: Gi0/5, MAC da: dead.be53.3b46, MAC sa: dead.baba.2370, IP da: 10.10.11.250, IP sa: 10.10.11.241, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 10.10.11.250, DHCP siaddr: 0.0.0.0, DHCP giaddr: 10.10.11.241, DHCP chaddr: dead.be53.3b46, efp_id: 20, vlan_id: 20 Nov 6 02:49:31.705: DHCP_SNOOPING: binary dump of option 82, length: 35 data: ##REDACTED Nov 6 02:49:31.705: DHCP_SNOOPING: binary dump of extracted circuit id, length: 14 data: ##REDACTED Nov 6 02:49:31.705: DHCP_SNOOPING: binary dump of extracted remote id, length: 19 data: ##REDACTED Nov 6 02:49:31.705: actual_fmt_cid 4, length 12 type 4 len 10 Nov 6 02:49:31.705: PURA_DHCP_SNOOPING located host tracking mac dead.be53.3b46 Gi0/5 vlan 20 Nov 6 02:49:31.705: PURA_DHCP_SNOOPING: opt82 data indicates local packet Nov 6 02:49:31.705: DHCP_SNOOPING: remove relay information option. Nov 6 02:49:31.705: PURA_DHCP_SNOOPING located host tracking mac dead.be53.3b46 Gi0/5 vlan 20 Nov 6 02:49:31.705: DHCP_SNOOPING: output port is same as input port (GigabitEthernet0/5), dropping packet
MAC addresses have been altered and some identifying information redacted.
I don't know how to interpret "output port is same as input port" because it does not make sense to me. If I turn of dhcp snooping, the dhcp process works as expected, but I need option 82 inserted.
I have tried "no ip dhcp snooping information option" and I don't remember the result being any different.
I have also tried with only a single ip helper-address but the result was the same.
I have only tried with a single client; a laptop with wireshark and it receives no DHCPOFFER.
Now, I am certain that this did work 6 months ago, with asr901-universalk9-mz.155-2.S2.bin, and the only other thing that has changed since then is an upgrade of the DHCP server.
Some day this week I will be able to test with asr901-universalk9-mz.155-2.S2.bin, again.
Bottom questions:
What is the cause for "DHCP_SNOOPING: output port is same as input port"?
Is this intended/expected behavior?
If not, are you able to tell me where I went wrong?
Thank you.
11-09-2021 10:27 AM - edited 11-09-2021 10:32 AM
After more testing last night I concluded that this issue/behavior is not present in firmwares such as asr901-universalk9-mz.156-2.SP2.bin and older. My base configuration sample, as seen in my previous post, works as expected with the following debug output:
Nov 8 20:36:25.153: DHCP_SNOOPING: process new DHCP packet, message type: DHCPOFFER, input interface: Gi0/5, MAC da: dead.be53.3b46, MAC sa: dead.beba.2370, IP da: 10.10.11.250, IP sa: 10.10.11.241, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 10.10.11.250, DHCP siaddr: 0.0.0.0, DHCP giaddr: 10.10.11.241, DHCP chaddr: dead.be53.3b46, efp_id: 20, vlan_id: 20
Nov 8 20:36:25.153: DHCP_SNOOPING: binary dump of option 82, length: 35 data:
##REDACTED
Nov 8 20:36:25.153: DHCP_SNOOPING: binary dump of extracted circuit id, length: 14 data:
##REDACTED
Nov 8 20:36:25.153: DHCP_SNOOPING: binary dump of extracted remote id, length: 19 data:
##REDACTED
Nov 8 20:36:25.153: actual_fmt_cid 4, length 12 type 4 len 10
Nov 8 20:36:25.153: PURA_DHCP_SNOOPING located host tracking mac dead.be53.3b46 Gi0/5 vlan 20
Nov 8 20:36:25.153: PURA_DHCP_SNOOPING: opt82 data indicates local packet
Nov 8 20:36:25.153: DHCP_SNOOPING: remove relay information option.
Nov 8 20:36:25.153: PURA_DHCP_SNOOPING located host tracking mac dead.be53.3b46 Gi0/5 vlan 20
Nov 8 20:36:25.153: DHCP_SNOOPING: platform performs specific bridging of dhcp reply to output port: GigabitEthernet0/5.
Nov 8 20:36:25.157: DHCP_SNOOPING: process new DHCP packet, message type: DHCPREQUEST, input interface: Gi0/5 #... continues succesfully
Firmwares tested and working successfully:
asr901-universalk9-mz.155-2.S2.bin
asr901-universalk9-mz.155-2.S4.bin
asr901-universalk9-mz.156-2.SP.bin
asr901-universalk9-mz.156-2.SP1.bin
asr901-universalk9-mz.156-2.SP2.bin
Firmwares tested and not working as expected:
asr901-universalk9-mz.156-2.S3.bin
asr901-universalk9-mz.156-2.SP3.bin
asr901-universalk9-mz.156-2.SP9.bin
asr901-universalk9-mz.155-3.S10.bin
Maybe except for CSCvd35000, I did not notice anything in the relevant release notes regarding DHCP snooping, but I have observed that behavior regarding DHCP snooping is different. Why is this?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide