From: Pavel Bykov (slidersv@gmail.com)
Date: Fri Jan 23 2009 - 16:38:42 ARST
no FIB because R6 is using control plane for translation.
On Fri, Jan 23, 2009 at 7:21 PM, <joe_astorino@comcast.net> wrote:
> Interesting .... if I look at the debug of the successful ping to 4.4.4.4
> from R6's ethernet address I see something I do NOT see when it fails encap.
>
> R6(config-if)#do ping 4.4.4.4 so e0/0
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
> Packet sent with a source address of 141.41.67.6
> !
> *Jan 23 18:13:03.869: IP: tableid=0, s=141.41.67.6 (local), d=4.4.4.4
> (Serial2/0), routed via FIB
> *Jan 23 18:13:03.873: IP: s=141.41.67.6 (local), d=4.4.4.4 (Serial2/0), len
> 100, sending
> *Jan 23 18:13:03.873: ICMP type=8, code=0
>
>
> Notice that on the first line it says "routed via FIB". When it fails I do
> not see that. hmmmmmmm.............
>
>
> ----- Original Message -----
> From: "joe astorino" <joe_astorino@comcast.net>
> To: "Pavel Bykov" <slidersv@gmail.com>
> Cc: ccielab@groupstudy.com
> Sent: Friday, January 23, 2009 12:35:38 PM GMT -05:00 US/Canada Eastern
> Subject: Re: Frame-Relay Encapsulation Failed -- Driving me mad
>
> Hi guys,
>
> Thanks to everybody that is chipping in on this one. It sure is a
> frustrating issue! Yes, I have tried pinging 4.4.4.4 sourced from R6's
> ethernet (141.41.67.6) and it works just fine. That was actually one of the
> first things I tried. Scott, no I have not turned off any services or done
> anything "strange." The startup configurations are pretty straight forward,
> just interfaces and IP addresses, and I have carefully looked them over
> again just to be sure.
>
> Pavel -- I also thought of it possibly being related to CEF so I did try
> making sure ip cef was on and also ip route-cache cef on all interfaces. I
> can even see the 4.4.4.4 entry in the cef table pointing to the correct next
> hop....and like I said I can ping it fine even sourced from R6's ethernet.
>
> Just for fun, here are my frame configurations from R6, and some logs.
> maybe you guys see something I don't!
>
> interface Serial2/0
> ip address 141.41.26.6 255.255.255.0
> ip pim sparse-mode
> encapsulation frame-relay
> ip ospf authentication message-digest
> ip ospf message-digest-key 1 md5 cisco
> ip ospf priority 0
> serial restart-delay 0
> frame-relay map ip 141.41.26.2 602 broadcast
> frame-relay map ip 141.41.26.5 602 broadcast
> frame-relay map ip 141.41.26.6 602 broadcast
> no frame-relay inverse-arp
> frame-relay lmi-type cisco
>
> R6#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,
> broadcast,
> CISCO, status defined, active
> Serial2/0 (up): ip 141.41.26.6 dlci 602(0x25A,0x94A0), static,
> broadcast,
> CISCO, status defined, active
>
>
> Ok looks good.....lets ping 4.4.4.4 sourced from our loopback and e0/0
>
>
> R6#ping 4.4.4.4 so lo1
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
> Packet sent with a source address of 6.6.6.6
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 196/205/236 ms
> R6#ping 4.4.4.4 so e0/0
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
> Packet sent with a source address of 141.41.67.6
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 196/197/200 ms
>
>
> OK how about a traceroute for good measure???
>
> R6#trace 4.4.4.4
>
> Type escape sequence to abort.
> Tracing the route to 4.4.4.4
>
> 1 141.41.26.2 36 msec 32 msec 36 msec
> 2 141.41.26.5 76 msec 64 msec 68 msec
> 3 141.141.45.4 96 msec * 96 msec
>
> exactly as expected....it goes up to the frame hub, down to R5, then over
> to R4 through the PPPoFR virtual-template.
>
>
> Now, at this point R8 has an interface set for "ip dhcp" on the
> 141.41.67.0/24 subnet. Here is a debug ip packet of what is going on.
>
> R6#sh access-list 101
> Extended IP access list 101
> 10 permit udp any any eq bootpc
> 20 permit udp any any eq bootps
> 30 permit udp any any
> R6#debug ip packet 101 det
> IP packet debugging is on (detailed) for access list 101
>
> *Jan 23 17:22:51.464: IP: s=0.0.0.0 (Ethernet0/0), d=255.255.255.255, len
> 604, rcvd 2
> *Jan 23 17:22:51.464: UDP src=68, dst=67
> *Jan 23 17:22:51.468: IP: s=141.41.67.6 (local), d=4.4.4.4 (Serial2/0), len
> 604, sending
> *Jan 23 17:22:51.468: UDP src=67, dst=67
> *Jan 23 17:22:51.468: IP: s=141.41.67.6 (local), d=4.4.4.4 (Serial2/0), len
> 604, encapsulation failed
> *Jan 23 17:22:51.468: UDP src=67, dst=67
>
>
> Again, we see the DHCP broadcast come in from R8. We attempt to unicast a
> DHCP request packet to 4.4.4.4 and it poops.
>
> Now, we add a frame-map to 4.4.4.4 which DOESN'T MAKE ANY SENSE and it
> works!
>
> R6(config)#int s2/0
> R6(config-if)#frame map ip 4.4.4.4 602
>
> R6(config-if)#do sh frame map
> Serial2/0 (up): ip 4.4.4.4 dlci 602(0x25A,0x94A0), static,
> CISCO, status defined, active
> 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,
> broadcast,
> CISCO, status defined, active
> Serial2/0 (up): ip 141.41.26.6 dlci 602(0x25A,0x94A0), static,
> broadcast,
> CISCO, status defined, active
>
> *Jan 23 17:27:53.324: IP: s=0.0.0.0 (Ethernet0/0), d=255.255.255.255, len
> 604, rcvd 2
> *Jan 23 17:27:53.324: UDP src=68, dst=67
> *Jan 23 17:27:53.328: IP: s=141.41.67.6 (local), d=4.4.4.4 (Serial2/0), len
> 604, sending
> *Jan 23 17:27:53.328: UDP src=67, dst=67
> R6(config-if)#
> *Jan 23 17:27:56.152: IP: tableid=0, s=141.141.45.4 (Serial2/0),
> d=141.41.67.6 (Ethernet0/0), routed via RIB
> *Jan 23 17:27:56.152: IP: s=141.141.45.4 (Serial2/0), d=141.41.67.6, len
> 328, rcvd 4
> *Jan 23 17:27:56.152: UDP src=67, dst=67
> *Jan 23 17:27:56.156: IP: s=141.41.67.6 (local), d=255.255.255.255
> (Ethernet0/0), len 328, sending broad/multicast
> *Jan 23 17:27:56.156: UDP src=67, dst=68
> *Jan 23 17:27:56.160: IP: s=0.0.0.0 (Ethernet0/0), d=255.255.255.255, len
> 604, rcvd 2
> *Jan 23 17:27:56.160: UDP src=68, dst=67
> *Jan 23 17:27:56.164: IP: s=141.41.67.6 (local), d=4.4.4.4 (Serial2/0), len
> 604, sending
> *Jan 23 17:27:56.164: UDP src=67, dst=67
> R6(config-if)#
> *Jan 23 17:27:56.992: IP: tableid=0, s=141.141.45.4 (Serial2/0),
> d=141.41.67.6 (Ethernet0/0), routed via RIB
> *Jan 23 17:27:56.992: IP: s=141.141.45.4 (Serial2/0), d=141.41.67.6, len
> 328, rcvd 4
> *Jan 23 17:27:56.992: UDP src=67, dst=67
> *Jan 23 17:27:56.992: IP: s=141.41.67.6 (local), d=255.255.255.255
> (Ethernet0/0), len 328, sending broad/multicast
> *Jan 23 17:27:56.996: UDP src=67, dst=68
>
> R8(config-if)#do sh ip int brie
> Interface IP-Address OK? Method Status Protocol
> FastEthernet0/0 141.41.67.27 YES DHCP up up
>
> Am I going insane or what?!
>
> - Joe
>
>
>
>
>
>
>
>
>
> ----- Original Message -----
> From: "Pavel Bykov" <slidersv@gmail.com>
> To: "joe astorino" <joe_astorino@comcast.net>
> Cc: ccielab@groupstudy.com
> Sent: Friday, January 23, 2009 11:44:41 AM GMT -05:00 US/Canada Eastern
> Subject: Re: Frame-Relay Encapsulation Failed -- Driving me mad
>
> 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
>
> _______________________________________________________________________
> 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