cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3452
Views
5
Helpful
4
Replies

DHCP relay problems over GRE tunnel

ctainsiel
Level 1
Level 1

Hi guys,

I've got a problem with a Cisco 2821 router [IOS ver. 12.4(24)T4] which doesn't forward dhcp request over a GRE tunnel; both of interfaces (GRE and LAN) belong to the same VRF context. I hereby attach a piece of configuration:

ip vrf guests
rd 10:3
!
interface Loopback0
ip address 172.22.109.1 255.255.255.255
!
interface Tunnel10
ip vrf forwarding guests
ip address 10.200.128.9 255.255.255.252
no ip route-cache cef
no ip route-cache
tunnel source Loopback0
tunnel destination 172.25.121.6
tunnel key 0
tunnel checksum
!
interface GigabitEthernet0/0.474
encapsulation dot1Q 474
ip vrf forwarding guests
ip address 10.200.61.1 255.255.255.0
ip helper-address 172.25.68.26
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 172.22.105.33
ip route vrf guests 0.0.0.0 0.0.0.0 Tunnel10

The tunnel works fine for all except for the DHCP requests. This is the output for "debug ip dhcp server packet", "debug ip dhcp server events" and "debug ip packet 199" where 199 is an ACL for bootpc/bootps packet matching

*Feb 16 10:02:41.684: IP: s=0.0.0.0 (GigabitEthernet0/0.474), d=255.255.255.255, len 604, input feature, MCI Check(64), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

*Feb 16 10:02:41.684: IP: s=0.0.0.0 (GigabitEthernet0/0.474), d=255.255.255.255, len 604, rcvd 2

*Feb 16 10:02:41.684: IP: s=0.0.0.0 (GigabitEthernet0/0.474), d=255.255.255.255, len 604, stop process pak for forus packet

*Feb 16 10:02:41.684: DHCPD: Sending notification of DISCOVER:

*Feb 16 10:02:41.684:   DHCPD: htype 1 chaddr 001a.e290.b3c1

*Feb 16 10:02:41.684:   DHCPD: remote id 020a00000ac83d01000001da

*Feb 16 10:02:41.684:   DHCPD: circuit id 00000000

*Feb 16 10:02:41.684:   DHCPD: table id 1 = vrf guests

*Feb 16 10:02:41.684: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d30.3031.612e.6532.3930.2e62.3363.312d.566c.3437.34 on interface GigabitEthernet0/0.474.

*Feb 16 10:02:41.684: DHCPD: Seeing if there is an internally specified pool class:

*Feb 16 10:02:41.684:   DHCPD: htype 1 chaddr 001a.e290.b3c1

*Feb 16 10:02:41.684:   DHCPD: remote id 020a00000ac83d01000001da

*Feb 16 10:02:41.684:   DHCPD: circuit id 00000000

*Feb 16 10:02:41.684:   DHCPD: table id 1 = vrf guests

*Feb 16 10:02:41.684: DHCPD: there is no address pool for 10.200.61.1.

*Feb 16 10:02:41.688: DHCPD: setting giaddr to 10.200.61.1.

*Feb 16 10:02:41.688: DHCPD: BOOTREQUEST from 0063.6973.636f.2d30.3031.612e.6532.3930.2e62.3363.312d.566c.3437.34 forwarded to 172.25.68.26.

Moreover, I tested an additional ACL for matching bootps/bootpc packets out of the Tunnel 10 interface and it didn't match any packet.

Is there any limitations of the IOS? Or anything else?

Thanks.

Bye

4 Replies 4

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

The debug actually looks good - these lines confirm that:

*Feb 16 10:02:41.688: DHCPD: setting giaddr to 10.200.61.1.

*Feb  16 10:02:41.688: DHCPD: BOOTREQUEST from  0063.6973.636f.2d30.3031.612e.6532.3930.2e62.3363.312d.566c.3437.34  forwarded to 172.25.68.26.

According to them, the DHCP message was correctly forwarded to the DHCP server at 172.25.68.26. Is it possible to check on the DHCP server if this packet actually arrived?

You could theoretically rewrite the helper-address command on the Gi0/0.474 as follows:

ip helper-address vrf guests 172.25.68.26

however, this should not be necessary - but it's nevertheless worth trying.

Best regards,

Peter

ebarticel
Level 4
Level 4

I would like to add a small question if I may...actually 2

Does the DHCP server "knows" where you are? Is DHCP traffic permitted on the other end?

Hope this helps

Eugen

I found it !!! I don't know why but I solved the problem by deleting "no ip route-cache" and "no ip route-cache cef" commands under the tunnel interface (those were default settings).

I wonder why CEF is involved in this.

About Peter's question:

1) No packets came out from the tunnel interface (I used a log ACL) and so the DHCP server had never received them.

About Eugen's question:

1) Router and DHCP server are reachable each other and DHCP scope is configured

2) No ACLs are used

Thanks for your help anyway.

Bye

Hello,

Thank you for letting us know! Hmm, I suppose the CEF had some kind of inconsistency in its contents, causing your packets to be mis-forwarded. I've seen similar problems before. I would also hypothesize that if you restarted your router and put back the commands you've removed, it would still work.

Best regards,

Peter

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: