cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1211
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?