Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

encapsulation failed

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.

1 ACCEPTED SOLUTION

Accepted Solutions
New Member

Re: encapsulation failed

I made some more researches... you're hitting this BUG : CSCdp36754

----QUOTE----

CSCdp36754

Forwarding of bootp/dhcp address request UDP packets fail because of encapsulation failure.

Workaround:

1) Use Cisco IOS Release 12.0(5)T

2) For DDR, define IP DHCP server on the local router.

UniverCD document "Configuring DHCP" at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt1/1cddhcp.htm#35657

3) Configure a static arp entry for the "next hop" adresse's

mac-address.

Here is an example workaround with DHCP server on the other

side of a FDDI ring:

interface ethernet 0

ip helper-address 192.82.247.98

arp 192.82.247.98 4000.7507.0301 SNAP

----UNQUOTE----

So I think you may try the suggestion I made in the previous post.. or consider an IOS upgrade to 12.1T or 12.2.

or even downgrade to 12.0(5)T as it doesn't hit this bug

I hope it works by the next year ;)

Happy new year to all

George

22 REPLIES
Hall of Fame Super Gold

Re: encapsulation failed

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

New Member

Re: encapsulation failed

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.

Hall of Fame Super Gold

Re: encapsulation failed

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

Cisco Employee

Re: encapsulation failed

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

Thanks,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
New Member

Re: encapsulation failed

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

Cisco Employee

Re: encapsulation failed

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

Hope this helps,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Cisco Employee

Re: encapsulation failed

I meant, I would definitely try with CEF enabled.

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Silver

Re: encapsulation failed

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.

Cisco Employee

Re: encapsulation failed

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,

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Silver

Re: encapsulation failed

Hi Harold, thanks a lot for your reply.

Hall of Fame Super Gold

Re: encapsulation failed

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

Silver

Re: encapsulation failed

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.

New Member

Re: encapsulation failed

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.

New Member

Re: encapsulation failed

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

New Member

Re: encapsulation failed

I have turned on IP CEF but didn't work. I wonder if my IOS version is messing up. But in theory, it should work. Any advise would help. Thanks.

Here is the show ip cef:

Prefix Next Hop Interface

0.0.0.0/0 10.209.2.22 FastEthernet0/0

0.0.0.0/32 receive

10.69.96.0/19 10.209.2.22 FastEthernet0/0

10.209.2.0/24 attached FastEthernet0/0

10.209.2.0/32 receive

10.209.2.1/32 10.209.2.1 FastEthernet0/0

10.209.2.13/32 10.209.2.13 FastEthernet0/0

I have turned on debug for ARP and looking for DHCP packets:

ARP:

ARP packet debugging is on

Generic IP:

IP packet debugging is on (detailed) for access list 102

access-list 102 permit udp any any eq bootps

access-list 102 permit udp any eq bootpc any

Here is my debug logs:

.Dec 29 09:30:23.656 PST: IP: s=0.0.0.0 (FastEthernet0/0), d=255.255.255.255, len 328, rcvd 2

.Dec 29 09:30:23.656 PST: UDP src=68, dst=67

.Dec 29 09:30:23.656 PST: IP: s=10.209.2.254 (local), d=10.69.96.30 (FastEthernet0/0), len 328, sending

.Dec 29 09:30:23.656 PST: UDP src=67, dst=67

.Dec 29 09:30:23.660 PST: IP ARP: creating incomplete entry for IP address: 10.69.96.30 interface FastEthernet0/0

.Dec 29 09:30:23.660 PST: IP ARP: sent req src 10.209.2.254 0007.eb37.f5c0,

dst 10.69.96.30 0000.0000.0000 FastEthernet0/0

.Dec 29 09:30:23.660 PST: IP: s=10.209.2.254 (local), d=10.69.96.30 (FastEthernet0/0), len 328, encapsulation failed

.Dec 29 09:30:23.660 PST: UDP src=67, dst=67

.Dec 29 09:30:23.660 PST: IP: s=10.209.2.254 (local), d=10.69.96.40 (FastEthernet0/0), len 328, sending

.Dec 29 09:30:23.664 PST: UDP src=67, dst=67

.Dec 29 09:30:23.664 PST: IP ARP: creating incomplete entry for IP address: 10.69.96.40 interface FastEthernet0/0

.Dec 29 09:30:23.664 PST: IP ARP: sent req src 10.209.2.254 0007.eb37.f5c0,

dst 10.69.96.40 0000.0000.0000 FastEthernet0/0

.Dec 29 09:30:23.664 PST: IP: s=10.209.2.254 (local), d=10.69.96.40 (FastEthernet0/0), len 328, encapsulation failed

.Dec 29 09:30:23.668 PST: UDP src=67, dst=67

.Dec 29 09:30:26.652 PST: IP: s=0.0.0.0 (FastEthernet0/0), d=255.255.255.255, len 328, rcvd 2

.Dec 29 09:30:26.652 PST: UDP src=68, dst=67

.Dec 29 09:30:26.656 PST: IP: s=10.209.2.254 (local), d=10.69.96.30 (FastEthernet0/0), len 328, sending

.Dec 29 09:30:26.656 PST: UDP src=67, dst=67

.Dec 29 09:30:26.656 PST: IP ARP: sent req src 10.209.2.254 0007.eb37.f5c0,

dst 10.69.96.30 0000.0000.0000 FastEthernet0/0

.Dec 29 09:30:26.656 PST: IP: s=10.209.2.254 (local), d=10.69.96.30 (FastEthernet0/0), len 328, encapsulation failed

.Dec 29 09:30:26.660 PST: UDP src=67, dst=67

.Dec 29 09:30:26.660 PST: IP: s=10.209.2.254 (local), d=10.69.96.40 (FastEthernet0/0), len 328, sending

.Dec 29 09:30:26.660 PST: UDP src=67, dst=67

.Dec 29 09:30:26.660 PST: IP ARP: sent req src 10.209.2.254 0007.eb37.f5c0,

Hall of Fame Super Gold

Re: encapsulation failed

Chuck

The additional information that you have posted pretty much confirms what I had said in an earlier post. Having both debug arp and debug ip packet looking for DHCP is helpful. It clearly demonstrates that you receive a DHCP packet, that your router is attempting to send to both configured helper address destinations, that it is sending ARP request for the helper address destinations, it receives no response, and having no destination MAC address it can not send the packet and it fails with encapsulation failed.

The basic problem is that the IOS should send the helper address packets via the default route. It should not ARP for the helper address destination. Harold says that this should work. So obviously there is some bug in the version of IOS that you are using. As Harold has pointed out the version of IOS that you are running is somewhat old. If you upgrade to a newer version of IOS it is quite possible that the buggy behavior will not be present. (Or if upgrading the code is not feasible I would suggest looking at possibilities of redesigning your network so that it is not such an odd version of router on a stick.)

HTH

Rick

Hall of Fame Super Gold

Re: encapsulation failed

Chuck

It occurs to me that the behavior that you are having is the behavior that would result if the default route just pointed at the FastEthernet interface rather than at the address of the next hop router. Is it possible that at one point you had the default route just specifying the outbound interface. If you reboot the router do you get the same behavior?

HTH

Rick

New Member

Re: encapsulation failed

This is definitely an IOS bug

You may try the following as a workaround

1/add these two static routes

ip route 10.69.96.30 255.255.255.255 10.209.2.22

ip route 10.69.96.40 255.255.255.255 10.209.2.22

it will solve your problem, if the bug is limited to the traffic routed by the default route

2/if possible, ask the admin for 10.209.2.22 to enable proxy arp on the LAN interface facing your router

Hope this helps

George

New Member

Re: encapsulation failed

A third good workaround would be configuring static arp entries for 10.69.96.30 and 10.69.96.40 as follows

conf t

arp 10.69.96.30 [mac_address_for_10.209.2.22] arpa

arp 10.69.96.40 [mac_address_for_10.209.2.22] arpa

George

New Member

Re: encapsulation failed

I made some more researches... you're hitting this BUG : CSCdp36754

----QUOTE----

CSCdp36754

Forwarding of bootp/dhcp address request UDP packets fail because of encapsulation failure.

Workaround:

1) Use Cisco IOS Release 12.0(5)T

2) For DDR, define IP DHCP server on the local router.

UniverCD document "Configuring DHCP" at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt1/1cddhcp.htm#35657

3) Configure a static arp entry for the "next hop" adresse's

mac-address.

Here is an example workaround with DHCP server on the other

side of a FDDI ring:

interface ethernet 0

ip helper-address 192.82.247.98

arp 192.82.247.98 4000.7507.0301 SNAP

----UNQUOTE----

So I think you may try the suggestion I made in the previous post.. or consider an IOS upgrade to 12.1T or 12.2.

or even downgrade to 12.0(5)T as it doesn't hit this bug

I hope it works by the next year ;)

Happy new year to all

George

New Member

Re: encapsulation failed

George,

Thanks for helping me get to the bottom of this. I'm testing the work-arounds and will post the results.

Have a wonderfull new year to all.

--cd

New Member

Re: encapsulation failed

For the record, the static ARP entries worked!!! It solved the router's ARP confusion. Thanks.

--chuck

1830
Views
8
Helpful
22
Replies
CreatePlease to create content