From: Pavel Bykov (slidersv@gmail.com)
Date: Fri Jan 23 2009 - 14:44:41 ARST
Looks like control plane / data plane issue to me
Try "ip cef" on all routers and "ip route-cache cef" on all interfaces.
On Fri, Jan 23, 2009 at 9:01 AM, <joe_astorino@comcast.net> wrote:
> Hello everybody. I am hoping somebody might be able to explain to me an
> issue I am having regarding frame-relay that is driving me mad in the
> practice lab. Here is the scenario:
>
> R2, R5, R6 are in a frame-relay hub/spoke topology whereby R2 is the hub.
> DLCIs are X0Y where X is the source router number and Y is the destination
> router number. Additionally, R5 has a PPPoFR link to R4. The R2,R5,R6 cloud
> is the 141.41.26.0/24 network. The R5/R4 P2P is the 141.141.45.0/24network.
> I have full ip reachability, all my routing is working fine and I run into
> this IOS services task.
>
> R4 has an ethernet interface on the 141.141.200.0/24 subnet. R6, which is
> on the other end of the frame-relay cloud from R4 has an ethernet interface
> on the 141.41.67.0/24 subnet. The task requires that you configure R4 to
> be a DHCP server to hand out addresses on the 141.41.67.0/24 subnet. In
> other words, you need a helper address on R6's ethernet. In order to verify
> your configuration, you need to bring up R8's ethernet interface and set it
> for dhcp.
>
> Here is where it gets weird. On R6 I have the following frame mappings as
> you would expect of a spoke: A static mapping to the hub, the other spoke,
> and itself.
>
> R6(config-if)#do sh frame map
> Serial2/0 (up): ip 141.41.26.2 dlci 602(0x25A,0x94A0), static,
> broadcast,
> CISCO, status defined, active
> Serial2/0 (up): ip 141.41.26.5 dlci 602(0x25A,0x94A0), static,
> CISCO, status defined, active
> Serial2/0 (up): ip 141.41.26.6 dlci 602(0x25A,0x94A0), static,
> CISCO, status defined, active
>
>
> After I have everything setup, R8 is not pulling a DHCP address, so I turn
> on some debugging and see this:
>
> .Jan 23 07:52:32.443: IP: s=0.0.0.0 (Ethernet0/0), d=255.255.255.255, len
> 604, rcvd 2
> .Jan 23 07:52:32.443: UDP src=68, dst=67
> .Jan 23 07:52:32.443: IP: s=141.41.67.6 (local), d=4.4.4.4 (Serial2/0), len
> 604, sending
> .Jan 23 07:52:32.443: UDP src=67, dst=67
> .Jan 23 07:52:32.447: IP: s=141.41.67.6 (local), d=4.4.4.4 (Serial2/0), len
> 604, encapsulation failed
> .Jan 23 07:52:32.447: UDP src=67, dst=67
>
> So, I see the DHCP broadcast come in from R8, thats good. Then I see R6
> attempt to unicast to R4 because it has ip helper-address 4.4.4.4 configured
> (R4's loopback) so thats good ....... and then boom encapsulation failed.
> First off I don't understand why this is happening. I have a route to
> 4.4.4.4, which R6 learnes via ospf from R5 from across the frame. I would
> think that like ANY other route it has that it would first lookup 4.4.4.4 in
> the routing table, see that the next hop is 141.41.26.5, then send the
> packet source 141.41.67.6 , destination 4.4.4.4 with a DLCI of 602 as it is
> destined for R5. Here is the route entry on R6.
>
> Routing entry for 4.4.4.4/32
> Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric
> 64
> Redistributing via eigrp 679
> Advertised by eigrp 679 metric 1 1 1 1 1
> Last update from 141.41.26.5 on Serial2/0, 01:37:43 ago
> Routing Descriptor Blocks:
> * 141.41.26.5, from 5.5.5.5, 01:37:43 ago, via Serial2/0
> Route metric is 20, traffic share count is 1
>
> No, here is the really insane part! If I change absolutely NOTHING and ping
> 4.4.4.4 from R6 it works just fine. If I ping ANY other route in my lab
> network, it works just fine. I am stumped, hoping for some help!
> Here is the first packet sent, and first received: So why is it that if I
> send an icmp packet it works, but if I send a UDP packet to the exact same
> ip address it fails encapsulation? FYI there are no ACLs or filtering
> involved. Also if I do a frame map to 141.141.45.4 out DLCI 602 it works. I
> just don't get why I would need that at all, since as I said above I think
> it should recursively look up the route, and send it out the proper DLCI to
> the next hop address.
>
> R6(config-if)#do ping 4.4.4.4
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
> !!
> .Jan 23 07:57:37.352: IP: tableid=0, s=141.41.26.6 (local), d=4.4.4.4
> (Serial2/0), routed via FIB
> .Jan 23 07:57:37.352: IP: s=141.41.26.6 (local), d=4.4.4.4 (Serial2/0), len
> 100, sending
> .Jan 23 07:57:37.352: ICMP type=8, code=0
> .Jan 23 07:57:37.548: IP: tableid=0, s=4.4.4.4 (Serial2/0), d=141.41.26.6
> (Serial2/0), routed via RIB
> .Jan 23 07:57:37.548: IP: s=4.4.4.4 (Serial2/0), d=141.41.26.6 (Serial2/0),
> len 100, rcvd 3
> .Jan 23 07:57:37.548: ICMP type=0, code=0
>
>
> Thanks for ANY help on this one!
>
> - Joe
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
-- Pavel Bykov ---------------- Don't forget to help stopping the braindumps, use of which reduces value of your certifications. Sign the petition at http://www.stopbraindumps.com/Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:39 ARST