encapsulation failed

[chuck007]

I have a 2600 router on a stick setup with ip helper turned on for DHCP relays. But it's not working. I got encapsulation failed on the debug logs. However I can ping back and forth just fine. Here are the logs:

Dec 26 18:18:38.081 PST: IP: s=0.0.0.0 (FastEthernet0/0), d=255.255.255.255, len 328, rcvd 2

Dec 26 18:18:38.081 PST: UDP src=68, dst=67

Dec 26 18:18:38.085 PST: IP: s=10.209.2.254 (local), d=10.69.96.30 (FastEthernet0/0), len 328, sending

Dec 26 18:18:38.085 PST: UDP src=67, dst=67

Dec 26 18:18:38.085 PST: IP: s=10.209.2.254 (local), d=10.69.96.30 (FastEthernet0/0), len 328, encapsulation failed

Dec 26 18:18:38.085 PST: UDP src=67, dst=67

Dec 26 18:18:38.089 PST: IP: s=10.209.2.254 (local), d=10.69.96.40 (FastEthernet0/0), len 328, sending

Dec 26 18:18:38.089 PST: UDP src=67, dst=67

Dec 26 18:18:38.089 PST: IP: s=10.209.2.254 (local), d=10.69.96.40 (FastEthernet0/0), len 328, encapsulation failed

Dec 26 18:18:38.089 PST: UDP src=67, dst=67

I have a very basic setup:

ip subnet-zero

!

interface FastEthernet0/0

ip address 10.209.2.254 255.255.255.0

ip helper-address 10.69.96.30

ip helper-address 10.69.96.40

no ip redirects

no ip directed-broadcast

duplex auto

speed auto

!

interface Serial0/0

no ip address

no ip directed-broadcast

no ip mroute-cache

shutdown

!

ip classless

ip route 0.0.0.0 0.0.0.0 10.209.2.22

no ip http server

The WAN router is at 10.209.2.22 which is managed by our ISP. From my 2600 router, I can ping the WAN router and my DHCP servers. And my servers can ping the router also. It seems like my router is confused because the ARP debugs showed the following:

Dec 26 18:21:27.933 PST: IP ARP: creating incomplete entry for IP address: 10.209.2.22 interface FastEthernet0/0

Dec 26 18:21:27.933 PST: IP ARP: sent req src 10.209.2.254 0007.eb37.f5c0,

dst 10.209.2.22 0000.0000.0000 FastEthernet0/0

Dec 26 18:21:27.933 PST: IP ARP: rcvd rep src 10.209.2.22 0019.556a.8660, dst 10.209.2.254 FastEthernet0/0

Dec 26 18:22:26.313 PST: IP ARP: creating incomplete entry for IP address: 10.69.96.30 interface FastEthernet0/0

Dec 26 18:22:26.317 PST: IP ARP: sent req src 10.209.2.254 0007.eb37.f5c0,

dst 10.69.96.30 0000.0000.0000 FastEthernet0/0

Dec 26 18:22:26.317 PST: IP ARP: creating incomplete entry for IP address: 10.69.96.40 interface FastEthernet0/0

Dec 26 18:22:26.317 PST: IP ARP: sent req src 10.209.2.254 0007.eb37.f5c0,

dst 10.69.96.40 0000.0000.0000 FastEthernet0/0

Dec 26 18:22:30.313 PST: IP ARP: sent req src 10.209.2.254 0007.eb37.f5c0,

dst 10.69.96.30 0000.0000.0000 FastEthernet0/0

Dec 26 18:22:30.317 PST: IP ARP: sent req src 10.209.2.254 0007.eb37.f5c0,

dst 10.69.96.40 0000.0000.0000 FastEthernet0/0

What is going on? Does "ip helper-address" not support router on a stick setup? Thanks.

[Richard Burts]

Chuck

What you have posted surprises me a little and certainly seems to demonstrate that your version of IOS does not support ip helper-address in your version of router on a stick. The more usual implementation of router on a stick has multiple VLANs on the interface and traffic arriving on one subinterface is forwarded out another subinterface. It is not clear why you have implemented in this way and it is not clear whether this implementation affects what the IOS should support.

Your implementation is a bit unusual in that it seems to assume that user PCs will be connected to the Ethernet segment and will define this router address 10.209.2.254 as their default gateway. But this router does nothing but forward to another router connected in the same subnet since it has no routes other than the connected subnet and its default route (which is to an address in the connected subnet). And when responses come back to the WAN router it will not forward to this router but will forward to the PCs since the destination will be in a locally connected subnet on the WAN router.

It is not clear whether the debug ARP output is related to a single transaction or whether two IP packets. The time stamps of the debug IP packet output and of the debug arp output suggest that they were done at different times and so they do not really clarify each other. And the time difference of almost a minute in the debug arp output (18:21:27 and 18:22:26) suggest that 2 different IP packets were involved.

What seems to be happening is that the router receives the DHCP request, and since it will be sending the ip helper packet out the same interface on which it was received it ARPs for the helper destination rather than sending to the default route as you might expect. This behavior suggests that ip helper-address is not supported in your particular implememtation. Having said that the question becomes SHOULD it be supported. And very few of us are able to answer the question of what the IOS should do. Perhaps one of the Cisco engineers who participate in the forum can answer. Or if you have a support contract, then I would suggest that you open a case with TAC and ask if it should be supported in your environment.

HTH

Rick

[chuck007]

Thanks for the insight. The unusal setup is because we have a WAN router and another internet gateway soon to be implemented. However, these are operated by our ISP and we can't make changes easily. Anyway, I was hoping the router on a stick would do the simple routing between the WAN and internet traffic. I must admit, it is unusal and wasn't clear if the Cisco IOS version (if any) would support this setup. However, thinking outside the box, most servers (Microsoft and Linux) support DHCP relay with one NIC card. I crossed my fingers and gave it a try. The alternative would be to turn on DHCP relay on a local server box.

Anyway, hopefully someone may have more info if Cisco supports such a setup for ip helpers.

Thanks.

[Richard Burts]

Chuck

I understand most of what you are saying. But I am still puzzled at the logic of having your user PCs connected on the same Ethernet segment (and in the same subnet) as the router run by the ISP. And having the DHCP server be remote on the other side of the ISP router seems also pretty strange.

I have seen lots of situations where a customer router connects to the ISP router via Ethernet, but have not seen situations where that same subnet was used to connect user stations.

HTH

Rick

[Harold Ritter]

This should definitely work. What version of IOS are you running on this router? Is CEF enabled on Fa0/0?

Thanks,

[chuck007]

I'm running 12.0(7)T with the following image:

flash:c2600-i-mz.120-7.T

Hardware is:

cisco 2621 (MPC860) processor (revision 0x600) with 26624K/6144K bytes of memory

show ip cef:

%CEF not running

Prefix Next Hop Interface

I think it should work too. But don't know why. Thanks.

--chuck

[Harold Ritter]

I would definitely work with CEF enabled and maybe more recent software.

Hope this helps,

[Harold Ritter]

I meant, I would definitely try with CEF enabled.

[jackyoung]

Hi Harold, can you explain why the CEF will make it work in this case ?

IMO, it is technically work but it is not an usual design.

Hi Chuck, is it possible to ask the ISP to enable the DHCP relay then you get the address via the ISP router ?

Hope this helps.

[Harold Ritter]

Hi Jack,

I simply suspect this might be a bug with the non-cef path. 12.0(7)T is kind of outdated as well.

Hope this helps,

[jackyoung]

Hi Harold, thanks a lot for your reply.

[Richard Burts]

Jack

I am trying to understand the logic of your suggestion. The debug ARP in the early posting clearly show that the router is sending ARP requests for the helper address destinations (which are remote addresses and the router should not ARP but should forward to its default route). The failure to get an ARP response is the reason for the encapsulation failed error. How will having the provider enable DHCP relay alter this problem. Perhaps if the provider enabled proxy arp it would be a more effective solution.

HTH

Rick

[jackyoung]

Hi Rick, sorry for the late reply due to unstable Internet access from my location. It is only a simple and quick suggestion to ensure the required command is enabled, I assume the DHCP server is located at somewhere that the routers will require to forward the DHCP traffic.

I agreed your point. Thanks a lot for your comment & happy new year.

[chuck007]

Yes, I can also have the ISP turn on DHCP relay too as we have done with another site. This will be my alternative if I can't get it to work on the 2600. Thanks.

[chuck007]

Good suggestion. I'll give it a try and re-test. Perhaps the CEF implementation may bypass the issue I'm seeing. I'll post the results shortly. Thanks.

--chuck