Both P2P and P2MP OSPF network types support hellos to the multicast 224.0.0.5 TTL1 hence both times your relationships were built ok.
Hello's source from interface address and destination is the multicast address.
The reason you cannot ping the one interface is due to the L3 to L2 process unable to distinguish which DLCI to use until you tell each point-to-point FR sub-interface to treat them from the default P2P OSPF network type to P2MP OSPF network type which then enables the /32's to be installed and pings to be successful, why it pings one over the other I'd guess it's to do with the order of operations of how you configured them...
Also noticed that the successful ping to one spoke is using P2MP OSPF network type (default)
>>> *on R3*
>>>
>>>
>>>
>>> interface Serial0/0
>>> ip address 172.16.124.3 255.255.255.0
>>> encapsulation frame-relay
>>> i
>>> frame-relay map ip 172.16.124.1 301 broadcast
>>> frame-relay map ip 172.16.124.4 301 broadcast
>>> no frame-relay inverse-arp
>>> R1#ping 172.16.124.3
>>>
>>> Type escape sequence to abort.
>>> Sending 5, 100-byte ICMP Echos to 172.16.124.3, timeout is 2 seconds:
>>> !!!!!
>>> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/21/76 ms
vs the unsuccessful ping which you've explicitly configured as OSPF P2P network type, although I'd doubt this makes a difference, more like the L3 to L2 process being unable to distinguish between DLCI numbers...
>>> *on R2*
>>>
>>>
>>>
>>> !
>>> interface Serial0/0
>>> ip address 172.16.124.2 255.255.255.0
>>> encapsulation frame-relay
>>> ip ospf network point-to-point
>>> serial restart-delay 0
>>> frame-relay map ip 172.16.124.1 201 broadcast
>>> frame-relay map ip 172.16.124.4 201
>>> no frame-relay inverse-arp
>>> R1#ping 172.16.124.2
>>>
>>> Type escape sequence to abort.
>>> Sending 5, 100-byte ICMP Echos to 172.16.124.2, timeout is 2 seconds:
>>> .....
>>> Success rate is 0 percent (0/5)
-- BR Tony Sent from my iPad On 27 Sep 2013, at 20:14, Imran Ali <immrccie_at_gmail.com> wrote: > Narbik, > > initially before changing the network type to OSPF P2M ON " ALL " > devices.... hub cant ping one spoke > > > HUB pinging one spoke > > R1#ping 172.16.124.2 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 172.16.124.2, timeout is 2 seconds: > ..... > Success rate is 0 percent (0/5) > > hub pinging another spoke > > R1#ping 172.16.124.3 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 172.16.124.3, timeout is 2 seconds: > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max = 1/22/56 ms > R1#conf t > Enter configuration commands, one per line. End with CNTL/Z. > R1(config)#int s0/0.12 > R1(config-subif)#ip ospf network point-to-multipoint > R1(config-subif)#exit > R1(config)#ion > %OSPF-5-ADJCHG: Process 1, Nbr 172.16.124.2 on Serial0/0.12 from LOADING to > FULL, Loading Done > R1(config)#int s0/0.13 > R1(config-subif)#ip ospf network point-to-multipoint > R1(config-subif)#end > R1# > %OSPF-5-ADJCHG: Process 1, Nbr 172.16.124.3 on Serial0/0.13 from LOADING to > FULL, Loading Done > %SYS-5-CONFIG_I: Configured from console by console > > *now both spokes became adjacent * > R1#o > > Neighbor ID Pri State Dead Time Address Interface > 172.16.124.3 0 FULL/ - 00:01:59 172.16.124.3 > Serial0/0.13 > 172.16.124.2 0 FULL/ - 00:01:59 172.16.124.2 > Serial0/0.12 > > *that injected /32 host routes* > > > R1#ping 172.16.124.2 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 172.16.124.2, timeout is 2 seconds: > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max = 4/27/92 ms > R1#ping 172.16.124.3 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 172.16.124.3, timeout is 2 seconds: > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max = 4/26/60 ms > R1# > > Question: how come OSPF neighbor ship came up without even pinging > ??? From past 3 years i am thinking that ospf end points must be > reachable ...then they can come up ...what's different here on frame > relay ? > > > as i got my configs up and fine ...i am moving on..but still i am > missing basic undesrtanding of something here... > > > > > On Fri, Sep 27, 2013 at 7:00 PM, Narbik Kocharians <narbikk_at_gmail.com>wrote: > >> Imran, >> >> Can you configure the spokes as P2P, and then configure every >> sub-interface as OSPF P2M? because that works like a champ. >> >> >> On Fri, Sep 27, 2013 at 3:02 PM, Imran Ali <immrccie_at_gmail.com> wrote: >> >>> Hi , >>> >>> i have a task and i am required to configure two ip's from same >>> subnet , on two different frame relay interfaces. >>> >>> on a physical interface this is not possible , but on a point to >>> point >>> interface ..we can apply ip's from same subnet . >>> >>> >>> all i need is to configure OSPF network type " point to mutipoint " >>> and ping all interfaces >>> >>> R2======== R1 ============R3 >>> spoike------------hub----------------spoke >>> >>> >>> *on R1* >>> >>> interface Serial0/0.12 point-to-point >>> ip address 172.16.124.1 255.255.255.0 >>> frame-relay interface-dlci 102 >>> >>> R1#r s0/0.13 >>> Building configuration... >>> >>> Current configuration : 119 bytes >>> ! >>> interface Serial0/0.13 point-to-point >>> ip address 172.16.124.4 255.255.255.0 >>> frame-relay interface-dlci 103 >>> >>> >>> >>> >>> >>> *on R2* >>> >>> >>> >>> ! >>> interface Serial0/0 >>> ip address 172.16.124.2 255.255.255.0 >>> encapsulation frame-relay >>> ip ospf network point-to-point >>> serial restart-delay 0 >>> frame-relay map ip 172.16.124.1 201 broadcast >>> frame-relay map ip 172.16.124.4 201 >>> no frame-relay inverse-arp >>> >>> >>> >>> *on R3* >>> >>> >>> >>> interface Serial0/0 >>> ip address 172.16.124.3 255.255.255.0 >>> encapsulation frame-relay >>> i >>> frame-relay map ip 172.16.124.1 301 broadcast >>> frame-relay map ip 172.16.124.4 301 broadcast >>> no frame-relay inverse-arp >>> >>> >>> As you can see spokes have mappings for both ip's of hub. >>> >>> now lets try to ping the spokes from hub >>> >>> R1#ping 172.16.124.2 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.2, timeout is 2 seconds: >>> ..... >>> Success rate is 0 percent (0/5) >>> R1#ping 172.16.124.3 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.3, timeout is 2 seconds: >>> !!!!! >>> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/21/76 ms >>> >>> >>> lets try once again >>> >>> R1#ping 172.16.124.2 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.2, timeout is 2 seconds: >>> ..... >>> Success rate is 0 percent (0/5) >>> R1#ping 172.16.124.2 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.2, timeout is 2 seconds: >>> ..... >>> Success rate is 0 percent (0/5) >>> R1#ping 172.16.124.3 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.3, timeout is 2 seconds: >>> !!!!! >>> Success rate is 100 percent (5/5), round-trip min/avg/max = 4/26/60 ms >>> >>> >>> >>> *so it seems R2 is not rechable and R3 is always replying * >>> >>> >>> on R3 ...let turn debug >>> R3#show debug >>> Generic IP: >>> IP packet debugging is on >>> R3# >>> >>> >>> lets do " no service timestamps " so that actual message is more >>> apparent >>> >>> R1#ping 172.16.124.2 repeat 1 >>> >>> Type escape sequence to abort. >>> Sending 1, 100-byte ICMP Echos to 172.16.124.2, timeout is 2 seconds: >>> . >>> >>> >>> >>> >>> IP: tableid=0, s=172.16.124.1 (Serial0/0), d=172.16.124.2 (Serial0/0), >>> routed via RIB >>> *IP: s=172.16.124.1 (Serial0/0), d=172.16.124.2 (Serial0/0), len 100, >>> redirected* >>> >>> IP: tableid=0, s=172.16.124.3 (local), d=172.16.124.1 (Serial0/0), routed >>> via FIB >>> IP: s=172.16.124.3 (local), d=172.16.124.1 (Serial0/0), len 56, sending >>> IP: s=172.16.124.1 (Serial0/0), d=172.16.124.2 (Serial0/0), >>> g=172.16.124.2, >>> len 100, forward >>> *IP: s=172.16.124.1 (Serial0/0), d=172.16.124.2 (Serial0/0), len 100, >>> >>> encapsulation failed >>> * >>> >>> adding ...spoke to spoke statements >>> R2(config)#int s0/0 >>> R2(config-if)#fram >>> R2(config-if)#frame-relay map ip 172.16.124.3 201 >>> >>> R3(config)#int s0/0 >>> R3(config-if)#fram >>> R3(config-if)#frame-relay map ip 172.16.124.2 301 b >>> >>> *R1#debug frame-relay packet >>> >>> Frame Relay packet debugging is on >>> >>> >>> *R1#ping 172.16.124.2 repeat 1 >>> >>> >>> Type escape sequence to abort. >>> Sending 1, 100-byte ICMP Echos to 172.16.124.2, timeout is 2 seconds: >>> >>> *Serial0/0.13(o): dlci 103(*0x1871), pkt type 0x800(IP), datagramsize 104 >>> >>> Serial0/0(i): dlci 103(0x1871), pkt type 0x800, datagramsize 104. >>> Success rate is 0 percent (0/1) >>> R1# >>> R1# >>> R1#ping 172.16.124.3 repeat 1 >>> >>> Type escape sequence to abort. >>> Sending 1, 100-byte ICMP Echos to 172.16.124.3, timeout is 2 seconds: >>> ! >>> Success rate is 100 percent (1/1), round-trip min/avg/max = 40/40/40 ms >>> R1# >>> Serial0/0(i): dlci 102(0x1861), pkt type 0x800, datagramsize 80 >>> Serial0/0(i): dlci 103(0x1871), pkt type 0x800, datagramsize 80 >>> Serial0/0(i): dlci 103(0x1871), pkt type 0x800, datagramsize 80 >>> Serial0/0(i): dlci 103(0x1871), pkt type 0x800, datagramsize 80 >>> R1#* >>> >>> Serial0/0.13(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104 >>> Serial0/0(i): dlci 103(0x1871), pkt type 0x800, datagramsize 104* >>> >>> >>> >>> it seems now R1 is only using one DLCI to reach both spokes ...ie >>> 103 >>> >>> >>> but strangely when i add ospf process on hub routers ...both spoke >>> become adjacent >>> >>> R1(config-router)#network 172.16.124.1 0.0.0.0 a 0 >>> R1(config-router)#ne >>> %OSPF-5-ADJCHG: Process 1, Nbr 172.16.124.2 on Serial0/0.12 from LOADING >>> to >>> FULL, Loading Done >>> R1(config-router)#net >>> R1(config-router)#network 172.16.124.4 0.0.0.0 a 0 >>> R1(config-router)#exit >>> R1(config)#exit >>> R1# >>> %OSPF-5-ADJCHG: Process 1, Nbr 172.16.124.3 on Serial0/0.13 from LOADING >>> to >>> FULL, Loading Done >>> %SYS-5-CONFIG_I: Configured from console by console >>> R1#o >>> >>> *Neighbor ID Pri State Dead Time Address >>> Interface >>> >>> 172.16.124.3 0 FULL/ - 00:00:36 172.16.124.3 >>> Serial0/0.13 >>> 172.16.124.2 0 FULL/ - 00:00:36 172.16.124.2 >>> Serial0/0.12* >>> >>> R1# >>> >>> >>> >>> but even now i cant ping R2 .... >>> >>> R1#ping 172.16.124.2 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.2, timeout is 2 seconds: >>> ..... >>> Success rate is 0 percent (0/5) >>> R1#ping 172.16.124.2 so >>> R1#ping 172.16.124.2 source 172.16.124.4 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.2, timeout is 2 seconds: >>> Packet sent with a source address of 172.16.124.4 >>> ..... >>> Success rate is 0 percent (0/5) >>> R1#ping 172.16.124.3 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.3, timeout is 2 seconds: >>> !!!!! >>> Success rate is 100 percent (5/5), round-trip min/avg/max = 4/36/88 ms >>> R1#ping 172.16.124.3 source 172.16.124.4 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.3, timeout is 2 seconds: >>> Packet sent with a source address of 172.16.124.4 >>> !!!!! >>> Success rate is 100 percent (5/5), round-trip min/avg/max = 4/16/44 ms >>> R1#se >>> Interface IP-Address OK? Method Status >>> Protocol >>> Serial0/0.12 172.16.124.1 YES manual up >>> up >>> Serial0/0.13 172.16.124.4 YES manual up >>> up >>> >>> >>> >>> >>> Can any body try out the same senario ... and post it >>> >>> to summarize >>> >>> *R2#o* >>> >>> >>> Neighbor ID Pri State Dead Time Address >>> Interface >>> 172.16.124.4 0 FULL/ - 00:00:31 172.16.124.1 >>> Serial0/0 >>> R2#ping 172.16.124.4 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.4, timeout is 2 seconds: >>> ..... >>> Success rate is 0 percent (0/5) >>> R2#ping 172.16.124.1 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.1, timeout is 2 seconds: >>> >>> clear ip ospf process.. >>> >>> *Mar 1 01:27:28.571: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.124.4 on >>> Serial0/0 from FULL to DOWN, Neighbor Down: Interface down or detached >>> *Mar 1 01:27:29.099: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.124.4 on >>> Serial0/0 from LOADING to FULL, Loading Done >>> R2#o >>> >>> Neighbor ID Pri State Dead Time Address >>> Interface >>> 172.16.124.4 0 FULL/ - 00:00:38 172.16.124.1 >>> Serial0/0 >>> R2#ping 172.16.124.1 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 172.16.124.1, timeout is 2 seconds: >>> >>> ..... >>> >>> >>> Blogs and organic groups at http://www.ccie.net >>> >>> _______________________________________________________________________ >>> Subscription information may be found at: >>> http://www.groupstudy.com/list/CCIELab.html >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> -- >> *Narbik Kocharians >> *CCSI#30832, CCIE# 12410 (R&S, SP, Security) >> *www.MicronicsTraining.com* <http://www.micronicstraining.com/> >> Sr. Technical Instructor >> YES! We take Cisco Learning Credits! >> A Cisco Learning Partner > > > Blogs and organic groups at http://www.ccie.net > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html Blogs and organic groups at http://www.ccie.netReceived on Mon Sep 30 2013 - 14:19:03 ART
This archive was generated by hypermail 2.2.0 : Tue Oct 01 2013 - 06:36:35 ART