cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1054
Views
5
Helpful
1
Replies

[ASR901] DHCP snooping: output port is same as input port

krvi
Level 1
Level 1

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.

1 Reply 1

krvi
Level 1
Level 1

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?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: