From: Pavel Bykov (slidersv@gmail.com)
Date: Sat Jan 24 2009 - 03:09:24 ARST
This came to me in a dream from which I just woke up, so take with salt:
Basically it was a recursivity problem. A packet came in, it had to be
processed by getting translated from broadcast to unicast, then the packet
had to be forwarded, but the next hop had to be resolved, because there was
no cache-entry, so after resolving the next hop the packet was almost
forwarded, but it was processed too many times to finish processing
correctly.
Adding map to 4.4.4.4 solved the problem because you didn't need to resolve
next hop.
The sure way to test if the problem is this dream thing, is to overcome that
last recursive lookup somehow. Basically setting IP of helper to the address
that is already resolved. Like static route that points out of the interface
only (no next hop), but the interface would have to be point to point for
that to work correctly.
Again, that was the dream, so... yeah..
On Sat, Jan 24, 2009 at 2:23 AM, Joe Astorino <joe_astorino@comcast.net>wrote:
> Hey Scott,
>
> Still no dice. I removed the 3 dhcp relay commands as requested. On a
> side
> note, if I create an ethernet subinterface on R6, e0/0.200 , give it an ip
> address in VLAN 200 (R4s ethernet), and trunk it down to the switch (so R6
> and R4 have ethernet interfaces in the same vlan) and make the
> helper-address R4s ethernet address it works fine. It just seems to be an
> issue with the serial interface for some reason.
>
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0
>
> mQGiBEY2qu8RBAD0E7Ydspmpn9/rRfd614pvDaqj4GKAUeWpc8NNJ3xNU9C5TAKg
> Ta/52f2DvxgPlw6m7W66AJP0HZODw2ameQ9tNMrz3upKRA+ISFaqkJa99UOTdLGC
> W/HtHWZNUJDopBHm3j/TBAAhI0EWvcNIudbHx5zYY4osfDNMaIXYaySwIwCg61Db
> RuST/K0PlSUFK9o6AqTmrcsD/ReQLYK/OEzZBQsPBqMD68ADtdYyIA3VZ7nhWCzc
> YODiBl36XIskcwyVAnU9YXs/Hf96MfI1R2fvYGW8jJ4WHb3wT1JxgiUG4rUbA2L3
> doxNseggGrKC31njFynVuOpdd/TRfsqzV3Yv5MGFPkNG3w/AoiRtwoMZFUtAox3j
> EWbBA/4mYkTKS/Rfgpv7QQHj4ajCHsTL/JNSN8LARwbBomUFdJ+0xdNdr7Ax1zC4
> FEUfP0plRMLMypKPSNYzlIF8dKGwW2I8hUMfQpmIBA4BXBE0/mbv21lU2AzTkvb1
> FssbIzhCkx3mMzESgYIwnnNkJBatTfFqKOxGm//G7s2y1eFPsrQnSm9lIEFzdG9y
> aW5vIDxqb2VfYXN0b3Jpbm9AY29tY2FzdC5uZXQ+iGAEExECACAFAkY2qu8CGwMG
> CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAb4dzwEzSi9chbAKCTz89zl4etDIdD
> Hewo7LNEmfT8uQCgmbneQqTT5VyIEx75nG5KzJh2K2m5Ag0ERjaq7xAIALgM2fwR
> tuhRNrwvkYFXTA5grAnnhGqFXPfLt5YlU86QLdu3Z9WJcAAHck1HMCUxdm0gZyNu
> q5XQnmr76dbWjftQ+mxYAdhZGjjGV1OQyjfyUoLbxyR0jvaLUTFvMmtxFsHpJvEc
> VLscWZUvjPbpcg/BH8EWbDUSCJc70EZMW6TpjyL+1Eq6+n4KB+IWDnn603U3vYFj
> ExVfg2CqTIzC/mxAGQ/lg1ujKBnL/VemGpjZzL8jyYVLhAtASTWnwuaL1Sf2kCYh
> fApP+06YxkQ39BrJmi7Dg6s5zeRu4le57kPLVAGK0ZYRbaq5asAi9Ni5j/ZLdh/b
> F3oUgAOTPQtqbi8AAwUH/1n9jpOXRX7LsfsI5K4gVhHYPUYuy5WuRRxJZ6Y1JbOq
> UfePLg+cutaxE8RAvEY1VZvNTvEt7UYPoA3qR3lb4IzLqJimbbKGhhVdHIOYLGnz
> nxiwfo4S+my9GEYKLb3iHIR1DCfihhDryVlFYGAMCPNh0w2sNSSenP4cZBuD6V1J
> QLitW9aZoURMvtFYU8aO/BlZ7hVlRVNU5juwwAM5t2n2gBeRhMthaAR7OApDypvB
> 1TM+BeSDchieEAFNkX4leSMbFgP3CJmAXMJXKj8MQmsR8gdccUHGplGFI6IzNklm
> L/eWLdhAZsM+LsAo4MpoJzPoQyFIH7wmIPm4b/z7YZmISQQYEQIACQUCRjaq7wIb
> DAAKCRAb4dzwEzSi9XiWAKCdDtdnTW9X/6rHxQL/obNiZsEtEwCgrlmYisNacJyf
> 74k/eLaYWYqu7YI=
> =8HMA
> -----END PGP PUBLIC KEY BLOCK-----
>
>
>
> -----Original Message-----
> From: Scott Morris [mailto:smorris@internetworkexpert.com]
> Sent: Friday, January 23, 2009 7:35 PM
> To: 'Joe Astorino'; 'Pavel Bykov'
> Cc: ccielab@groupstudy.com
> Subject: RE: Frame-Relay Encapsulation Failed -- Driving me mad
>
> Nothing's leaping out at me there... but what if you remove all your dhcp
> relay commands (two global and one interface). Let's rule that out of the
> equation as see if the "raw" method of forwarding works there.
>
> Scott
>
>
> -----Original Message-----
> From: Joe Astorino [mailto:joe_astorino@comcast.net]
> Sent: Friday, January 23, 2009 7:31 PM
> To: smorris@internetworkexpert.com; 'Pavel Bykov'
> Cc: ccielab@groupstudy.com
> Subject: RE: Frame-Relay Encapsulation Failed -- Driving me mad
>
> Hey Scott, I'd be very happy to post that information. Here you go!
> Thanks
> for the time. If you'd like to get your hands dirty I will glady provide
> you with a login to my rack.
>
>
>
>
> =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2009.01.23 19:26:05
> =~=~=~=~=~=~=~=~=~=~=~= term len 0 R6#show ver Cisco IOS Software, 3600
> Software (C3640-IK9O3S-M), Version 12.4(19), RELEASE SOFTWARE (fc1)
> Technical Support: http://www.cisco.com/techsupport Copyright (c)
> 1986-2008
> by Cisco Systems, Inc.
> Compiled Fri 29-Feb-08 22:36 by prod_rel_team
>
> ROM: System Bootstrap, Version 11.1(20)AA2, EARLY DEPLOYMENT RELEASE
> SOFTWARE (fc1)
>
> R6 uptime is 5 hours, 31 minutes
> System returned to ROM by reload at 13:43:19 EST Fri Jan 23 2009 System
> image file is "flash:c3640-ik9o3s-mz.124-19.bin"
>
>
> This product contains cryptographic features and is subject to United
> States
> and local country laws governing import, export, transfer and use. Delivery
> of Cisco cryptographic products does not imply third-party authority to
> import, export, distribute or use encryption.
> Importers, exporters, distributors and users are responsible for compliance
> with U.S. and local country laws. By using this product you agree to comply
> with applicable laws and regulations. If you are unable to comply with U.S.
> and local laws, return this product immediately.
>
> A summary of U.S. laws governing Cisco cryptographic products may be found
> at:
> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>
> If you require further assistance please contact us by sending email to
> export@cisco.com.
>
> Cisco 3640 (R4700) processor (revision 0x00) with 98304K/32768K bytes of
> memory.
> Processor board ID 26454825
> R4700 CPU at 100MHz, Implementation 33, Rev 1.0
> 2 Ethernet interfaces
> 4 Serial interfaces
> DRAM configuration is 64 bits wide with parity disabled.
> 125K bytes of NVRAM.
> 32768K bytes of processor board System flash (Read/Write)
>
> Configuration register is 0x2102
>
> R6#sh running-config
> Building configuration...
>
> Current configuration : 3073 bytes
> !
> version 12.4
> service timestamps debug datetime msec
> service timestamps log datetime msec
> no service password-encryption
> !
> hostname R6
> !
> boot-start-marker
> boot-end-marker
> !
> logging buffered 4096 debugging
> !
> no aaa new-model
> memory-size iomem 25
> clock timezone EST -5
> clock summer-time EDT recurring
> !
> !
> ip cef
> no ip domain lookup
> ip dhcp relay information option
> ip dhcp relay information trust-all
> !
> !
> ip multicast-routing
> ip auth-proxy max-nodata-conns 3
> ip admission max-nodata-conns 3
> !
> !
> !
> key chain EIGRP
> key 1
> key-string cisco
> accept-lifetime 00:00:00 Jan 1 1993 infinite
> send-lifetime 00:00:00 Jan 1 1993 infinite !
> interface Loopback1
> ip address 6.6.6.6 255.255.255.255
> ip pim sparse-mode
> ip igmp join-group 225.0.0.6
> !
> interface Ethernet0/0
> ip dhcp relay information trusted
> ip address 141.41.67.6 255.255.255.0
> ip helper-address 4.4.4.4
> ip authentication mode eigrp 679 md5
> ip authentication key-chain eigrp 679 EIGRP half-duplex !
> interface Ethernet0/1
> no ip address
> shutdown
> half-duplex
> !
> interface Serial2/0
> ip address 141.41.26.6 255.255.255.0
> ip pim sparse-mode
> encapsulation frame-relay
> no ip route-cache cef
> no ip route-cache
> ip ospf authentication message-digest
> ip ospf message-digest-key 1 md5 cisco
> ip ospf network broadcast
> 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 !
> interface Serial2/1
> ip address 141.41.69.6 255.255.255.0
> serial restart-delay 0
> !
> interface Serial2/2
> ip address 141.41.70.6 255.255.255.0
> serial restart-delay 0
> !
> interface Serial2/3
> no ip address
> shutdown
> serial restart-delay 0
> !
> router eigrp 679
> redistribute ospf 1 metric 1 1 1 1 1
> network 6.6.6.6 0.0.0.0
> network 141.41.67.0 0.0.0.255
> network 141.41.69.0 0.0.0.255
> network 141.41.70.0 0.0.0.255
> no auto-summary
> !
> router ospf 1
> router-id 6.6.6.6
> log-adjacency-changes
> area 256 virtual-link 2.2.2.2
> redistribute eigrp 679 subnets
> network 6.6.6.6 0.0.0.0 area 0
> network 141.41.26.0 0.0.0.255 area 256
> !
> router bgp 256
> no synchronization
> bgp log-neighbor-changes
> neighbor 2.2.2.2 remote-as 256
> neighbor 2.2.2.2 update-source Loopback1 neighbor 9.9.9.9 remote-as 66
> neighbor 9.9.9.9 local-as 99 neighbor 9.9.9.9 ebgp-multihop 255 neighbor
> 9.9.9.9 update-source Loopback1 no auto-summary !
> ip http server
> no ip http secure-server
> !
> ip forward-protocol nd
> !
> access-list 101 permit udp any any eq bootpc access-list 101 permit udp any
> any eq bootps access-list 101 permit udp any any access-list 102 permit
> icmp
> any any !
> !
> !
> control-plane
> !
> line con 0
> exec-timeout 0 0
> logging synchronous
> line aux 0
> line vty 0 4
> login
> !
> ntp clock-period 17179878
> ntp server 5.5.5.5
> !
> end
>
> R6#exit
>
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0
>
> mQGiBEY2qu8RBAD0E7Ydspmpn9/rRfd614pvDaqj4GKAUeWpc8NNJ3xNU9C5TAKg
> Ta/52f2DvxgPlw6m7W66AJP0HZODw2ameQ9tNMrz3upKRA+ISFaqkJa99UOTdLGC
> W/HtHWZNUJDopBHm3j/TBAAhI0EWvcNIudbHx5zYY4osfDNMaIXYaySwIwCg61Db
> RuST/K0PlSUFK9o6AqTmrcsD/ReQLYK/OEzZBQsPBqMD68ADtdYyIA3VZ7nhWCzc
> YODiBl36XIskcwyVAnU9YXs/Hf96MfI1R2fvYGW8jJ4WHb3wT1JxgiUG4rUbA2L3
> doxNseggGrKC31njFynVuOpdd/TRfsqzV3Yv5MGFPkNG3w/AoiRtwoMZFUtAox3j
> EWbBA/4mYkTKS/Rfgpv7QQHj4ajCHsTL/JNSN8LARwbBomUFdJ+0xdNdr7Ax1zC4
> FEUfP0plRMLMypKPSNYzlIF8dKGwW2I8hUMfQpmIBA4BXBE0/mbv21lU2AzTkvb1
> FssbIzhCkx3mMzESgYIwnnNkJBatTfFqKOxGm//G7s2y1eFPsrQnSm9lIEFzdG9y
> aW5vIDxqb2VfYXN0b3Jpbm9AY29tY2FzdC5uZXQ+iGAEExECACAFAkY2qu8CGwMG
> CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAb4dzwEzSi9chbAKCTz89zl4etDIdD
> Hewo7LNEmfT8uQCgmbneQqTT5VyIEx75nG5KzJh2K2m5Ag0ERjaq7xAIALgM2fwR
> tuhRNrwvkYFXTA5grAnnhGqFXPfLt5YlU86QLdu3Z9WJcAAHck1HMCUxdm0gZyNu
> q5XQnmr76dbWjftQ+mxYAdhZGjjGV1OQyjfyUoLbxyR0jvaLUTFvMmtxFsHpJvEc
> VLscWZUvjPbpcg/BH8EWbDUSCJc70EZMW6TpjyL+1Eq6+n4KB+IWDnn603U3vYFj
> ExVfg2CqTIzC/mxAGQ/lg1ujKBnL/VemGpjZzL8jyYVLhAtASTWnwuaL1Sf2kCYh
> fApP+06YxkQ39BrJmi7Dg6s5zeRu4le57kPLVAGK0ZYRbaq5asAi9Ni5j/ZLdh/b
> F3oUgAOTPQtqbi8AAwUH/1n9jpOXRX7LsfsI5K4gVhHYPUYuy5WuRRxJZ6Y1JbOq
> UfePLg+cutaxE8RAvEY1VZvNTvEt7UYPoA3qR3lb4IzLqJimbbKGhhVdHIOYLGnz
> nxiwfo4S+my9GEYKLb3iHIR1DCfihhDryVlFYGAMCPNh0w2sNSSenP4cZBuD6V1J
> QLitW9aZoURMvtFYU8aO/BlZ7hVlRVNU5juwwAM5t2n2gBeRhMthaAR7OApDypvB
> 1TM+BeSDchieEAFNkX4leSMbFgP3CJmAXMJXKj8MQmsR8gdccUHGplGFI6IzNklm
> L/eWLdhAZsM+LsAo4MpoJzPoQyFIH7wmIPm4b/z7YZmISQQYEQIACQUCRjaq7wIb
> DAAKCRAb4dzwEzSi9XiWAKCdDtdnTW9X/6rHxQL/obNiZsEtEwCgrlmYisNacJyf
> 74k/eLaYWYqu7YI=
> =8HMA
> -----END PGP PUBLIC KEY BLOCK-----
>
>
>
> -----Original Message-----
> From: Scott Morris [mailto:smorris@internetworkexpert.com]
> Sent: Friday, January 23, 2009 7:13 PM
> To: joe_astorino@comcast.net; 'Pavel Bykov'
> Cc: ccielab@groupstudy.com
> Subject: RE: Frame-Relay Encapsulation Failed -- Driving me mad
>
> Could you post the entire "show run" output and software version you have?
> That may be simpler.
>
> helper addresses aren't exactly a bleeding edge feature. :)
>
> Scott
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> joe_astorino@comcast.net
> Sent: Friday, January 23, 2009 4:55 PM
> To: Pavel Bykov
> Cc: ccielab@groupstudy.com
> Subject: Re: Frame-Relay Encapsulation Failed -- Driving me mad
>
> Hey guys,
>
> The general idea from several experts thusfar is that this has to be a
> "feature" and to try different code. It seems to ONLY effect dhcp traffic
> going out the serial frame interface. I will try the T train code
> recommended earlier in this thread tonight and try to keep you all posted.
>
> Thanks for the support
>
> - 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 1:38:42 PM GMT -05:00 US/Canada Eastern
> Subject: Re: Frame-Relay Encapsulation Failed -- Driving me mad
>
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.10.8/1899 - Release Date: 1/23/2009
> 7:28 AM
>
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.10.8/1899 - Release Date: 1/23/2009
> 7:28 AM
>
>
> 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