cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
332
Views
0
Helpful
13
Replies
claurie
Beginner

Configure DHCP on ASR Router for QinQ Subinterfaces

Hi All,

 

Currently trying to test DHCP on QinQ Sub-Interfaces on an ASR 1001-X. Static Addressing works without a hitch, but when setting the sub-interface with the DHCP Pool Default-Router address to enable a remote router to obtain an IP Address via DHCP, the 'dhcp server' receives the DHCPDISCOVER message but nothing appear to be sent to the remote router. I have included DHCP Pool, sub-interface configurations below along with 'sh ip dhcp server statistics' output and 

 . I would appreciate any and all advice on what I am missing!

 

no ip domain lookup
ip dhcp excluded-address 103.xxx.xxx.233
!
ip dhcp pool RC_Trial
network 103.xxx.xxx.232 255.255.255.248

dns-server 8.8.8.8 8.8.4.4
default-router 103.xxx.xxx.233
domain-name xxxxx.com.au
lease 8

INTERFACE

interface GigabitEthernet0/0/3.30x
description xxxxxxx
encapsulation dot1Q 30xx second-dot1q 35xx
ip address 103.xxx.xxx.233 255.255.255.252
ip access-group ACL-DHCP-Allow out

 

ip access-list extended ACL-DHCP-Allow
permit udp any host 255.255.255.255 eq bootps bootpc
permit ip any any

 

'SH IP DHCP SERVER STATISTICS' Output

Memory usage 20550
Address pools 2
Database agents 0
Automatic bindings 0
Manual bindings 0
Expired bindings 0
Malformed messages 2533
Secure arp entries 0
Renew messages 0
Workspace timeouts 0
Static routes 0
Relay bindings 0
Relay bindings active 0
Relay bindings terminated 0
Relay bindings selecting 0

Message Received
BOOTREQUEST 0
DHCPDISCOVER 2512
DHCPREQUEST 20
DHCPDECLINE 0
DHCPRELEASE 0
DHCPINFORM 0
DHCPVENDOR 0
BOOTREPLY 0
DHCPOFFER 0
DHCPACK 0
DHCPNAK 0

Message Sent
BOOTREPLY 0
DHCPOFFER 0
DHCPACK 0
DHCPNAK 0

Message Forwarded
BOOTREQUEST 0
DHCPDISCOVER 0
DHCPREQUEST 0
DHCPDECLINE 0
DHCPRELEASE 0
DHCPINFORM 0
DHCPVENDOR 0
BOOTREPLY 0
DHCPOFFER 0
DHCPACK 0
DHCPNAK 0

DHCP-DPM Statistics
Offer notifications sent 0
Offer callbacks received 0
Classname requests sent 0
Classname callbacks received 0

 

Edge.TR.M1#sh ip sockets
Proto Remote Port Local Port In Out Stat TTY Output IF
17 103.xxx.xxx.134 50149 103.xxx.xxx.130 161 0 0 2001001 0
17 --listen-- 110.xxx.xxx.50 162 0 0 2001011 0
17 --listen-- 110.xxx.xxx.50 53998 0 0 2001011 0
17(v6) --listen-- --any-- 161 0 0 2020001 0
17(v6) --listen-- --any-- 162 0 0 2020011 0
17(v6) --listen-- --any-- 49477 0 0 2020001 0
17 103.xxx.xxx.134 514 103.xxx.xxx.65 51381 0 0 400210 0
17 0.0.0.0 0 --any-- 67 0 0 2002211 0

1 ACCEPTED SOLUTION

Accepted Solutions

Craig

 

Thanks for the update. Glad to know that it is now working for you. My guess is that specifying the option 82 information was more significant but it is certainly possible that Paul's suggestion for trust all was also helpful. The important thing is that now it is working for you.

HTH

Rick

View solution in original post

13 REPLIES 13
paul driver
VIP Mentor

Hello

With the encapsulation on the subinterface it is now being tagged -

so if the device that connects to the physical interface of your rtr is a switch then that port needs to be a trunk and be able to accept vlan 30 or if it’s a rtr it needs to be in the same sub interface



kind regards
Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future

Hi Paul,
Thanks for the reply. The remote end is a router. Connection between the two routers is a Layer 2 ethernet network that implements the Qin Q tagging that is handed of the ASR. There is no possibility of the remote router being a member of any VLAN.
Cheers
Craig

Craig

 

I do not understand your statement "There is no possibility of the remote router being a member of any VLAN." Paul makes a good point that your subinterface will be sending Ethernet frames tagged with vlan ID. So the remote router needs to process tagged Ethernet frames. If the router is not a member of any vlan will it process tagged frames?

 

Perhaps you can give us some information about the remote router and how it is configured?

HTH

Rick

Hi Richard,

Thanks for the reply. I can see the confusion. The Ethernet Broadband network connecting the two routers removes the tags 'at the edge' before delivery to the remote router. The remote router is using IPoE on its WAN Port if that makes any clearer.

Thanks

Craig

 

Thanks for the clarification. My experience with QinQ has not been that tags were removed before delivery to the remote router. But if that is happening in your network then we need to look for some other issues. 

 

To make sure that I am understanding correctly - if you keep the sub interface QinQ configuration and manually configure IP addresses on both sides then there is successful communication? That would certainly indicate that the issue is about DHCP. Perhaps debug for DHCP might shed some light on the issue.

HTH

Rick

Hi Richard,
Static IP assignment using same subnet works without issue. I will debug dhcp server asap.

Thanks
Craig

Hi Richard,
Debug ip dhcp server packet output:
*Apr 20 00:13:27.865: DHCPD: Reload workspace interface GigabitEthernet0/0/3.31101 tableid 0.
*Apr 20 00:13:27.866: DHCPD: tableid for 103.102.223.237 on GigabitEthernet0/0/3.31101 is 0
*Apr 20 00:13:27.866: DHCPD: client's VPN is .
*Apr 20 00:13:27.866: DHCPD: No option 125
*Apr 20 00:13:27.866: DHCPD: inconsistent relay information.
*Apr 20 00:13:27.866: DHCPD: relay information option exists, but giaddr is zero.
Does this give you any direction to look?
Thanks

Craig

 

Thanks for the debug output. There are messages that I am not clear about but that certainly do show that there is some problem with the configuration. One of those messages is

Apr 20 00:13:27.866: DHCPD: inconsistent relay information.

I am not sure about it but I wonder if it relates to the fact that your DHCP pool describes a network with mask 255.255.255.248 but the mask of the interface is different

ip address 103.xxx.xxx.233 255.255.255.252

 

I am also not clear about this message

Apr 20 00:13:27.866: DHCPD: relay information option exists, but giaddr is zero

giaddr is the gateway address in the DHCP request and is typically used when the DHCP request is being sent to a server whose IP address is in a subnet different from the subnet where the client is. If the remote router and your router are in the same subnet then I am not sure why the relay information option is used but the DHCP request has giaddr as zero. That would seem to reflect some issue on the remote router request.

 

I suggest changing the interface mask in the configuration to be consistent with the mask in the DHCP pool. If that does not resolve the issue then I believe that we need to find some information about the configuration of the remote router.

HTH

Rick

Hello


@claurie wrote:
Hi Richard,
*Apr 20 00:13:27.866: DHCPD: inconsistent relay information.
*Apr 20 00:13:27.866: DHCPD: relay information option exists, but giaddr is zero.


Try enabling dhcp to trust packets with a zero gateway-address
ip dhcp relay information trust-all



kind regards
Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future

Hi Paul and Richard,
Thanks for pointing me in the right direction. Implemented Paul's ip dhcp relay information trust-all
Also, I found out that Option 82 was employed for the DHCP packets we were receiving.
Implemented the following without specifying relay agent information in the ip DHCP class to allow use of any Option 82 information (not sure at present which of these two actions, or both, worked - but work it did:
ip dhcp pool Test
network 103.xxx.xxx.236 255.255.255.252
default-router 103.xxx.xxx.237
dns-server 8.8.8.8 8.8.4.4
domain-name xxxxxxx.com.au
lease 8
class Option82
!
!
ip dhcp class Option82
!
!

Craig

 

Thanks for the update. Glad to know that it is now working for you. My guess is that specifying the option 82 information was more significant but it is certainly possible that Paul's suggestion for trust all was also helpful. The important thing is that now it is working for you.

HTH

Rick

View solution in original post

claurie
Beginner

Thank You Both

Craig

 

You are welcome. It has been an interesting discussion about a very obscure point. I am glad that our suggestions have been helpful. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

HTH

Rick