From: Scott Morris (swm@emanon.com)
Date: Wed Feb 13 2008 - 04:08:37 ARST
I'm not entirely sure what the problem you are seeing is. It's perfectly
acceptable to mix and match the interface types as long as your routers
agree on things! Point-to-(anything) agree on the idea of using or not
using a DR which is good! They don't agree on timers, but that's fixable!
I've labbed this up real quickly (as I'm working on other things) so keep in
mind that I'm not matching the other specifics of Lab39 here... nor have I
looked at that specific lab right this moment. (Sorry I didn't respond to
your first post also!)
However, just a quick setup:
R1, R4, R6, R7, R8, R9
router ospf 1
network 0.0.0.0 0.0.0.0 area 0
R2, R5
router ospf 1
passive s0/2/0
network 0.0.0.0 0.0.0.0 area 0
I'm obviously going to have issues on the frame clouds... Between R2 'n' R4
I just set it up as Point-to-point on both sides. But on the R2, R5, R6
multipoint cloud, I mimic what you are saying doesn't work. The two spokes
are set as point-to-point. The hub is set as point-to-multipoint
non-broadcast. And it works just fine.
R2(config-subif)#
*Feb 13 06:26:17.047: %OSPF-5-ADJCHG: Process 1, Nbr 200.0.0.5 on
Serial0/1/0.256 from LOADING to FULL, Loading Done
*Feb 13 06:26:18.035: %OSPF-5-ADJCHG: Process 1, Nbr 200.0.0.6 on
Serial0/1/0.256 from LOADING to FULL, Loading Done
R2(config-subif)#do sh ip o i s0/1/0.256
Serial0/1/0.256 is up, line protocol is up
Internet Address 150.100.100.2/24, Area 0
Process ID 1, Router ID 200.0.0.2, Network Type POINT_TO_MULTIPOINT, Cost:
64
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:06
Supports Link-local Signaling (LLS)
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 2, Adjacent neighbor count is 2
Adjacent with neighbor 200.0.0.6
Adjacent with neighbor 200.0.0.5
Suppress hello for 0 neighbor(s)
R2(config-subif)#
Here are the different config parts that I have. Again, this was fast and
missing perhaps other things from lab 39! R2 is the hub in my test.
R2(config-subif)#do sh run int s0/1/0.256
Building configuration...
Current configuration : 291 bytes
!
interface Serial0/1/0.256 multipoint
description Frame Relay Cloud 1
ip address 150.100.100.2 255.255.255.0
ip ospf network point-to-multipoint non-broadcast
ip ospf hello-interval 10
frame-relay map ip 150.100.100.5 205 broadcast
frame-relay map ip 150.100.100.6 206 broadcast
end
R2(config-subif)#
R5(config-if)#do sh run int s0/1/0
Building configuration...
Current configuration : 270 bytes
!
interface Serial0/1/0
ip address 150.100.100.5 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-point
frame-relay map ip 150.100.100.2 502 broadcast
frame-relay map ip 150.100.100.6 502
no frame-relay inverse-arp
frame-relay lmi-type cisco
end
R5(config-if)#
R6(config-if)#do sh run int s0/1/0
Building configuration...
Current configuration : 270 bytes
!
interface Serial0/1/0
ip address 150.100.100.6 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-point
frame-relay map ip 150.100.100.2 602 broadcast
frame-relay map ip 150.100.100.5 602
no frame-relay inverse-arp
frame-relay lmi-type cisco
end
R6(config-if)#
And I have full reachability inside the network....
R9(config-router)#do sh ip ro os
100.0.0.0/24 is subnetted, 3 subnets
O 100.100.100.0 [110/130] via 150.100.69.6, 00:01:15, Serial0/2/0
O 100.100.200.0 [110/130] via 150.100.69.6, 00:01:15, Serial0/2/0
200.0.0.0/32 is subnetted, 8 subnets
O 200.0.0.8 [110/130] via 150.100.69.6, 00:01:15, Serial0/2/0
O 200.0.0.1 [110/130] via 150.100.69.6, 00:01:15, Serial0/2/0
O 200.0.0.2 [110/129] via 150.100.69.6, 00:01:15, Serial0/2/0
O 200.0.0.4 [110/193] via 150.100.69.6, 00:01:15, Serial0/2/0
O 200.0.0.5 [110/66] via 150.100.69.6, 00:01:15, Serial0/2/0
O 200.0.0.6 [110/65] via 150.100.69.6, 00:01:15, Serial0/2/0
O 200.0.0.7 [110/66] via 150.100.69.6, 00:01:15, Serial0/2/0
150.100.0.0/16 is variably subnetted, 13 subnets, 2 masks
O 150.100.220.0/24 [110/65] via 150.100.69.6, 00:01:15, Serial0/2/0
O 150.100.221.0/24 [110/65] via 150.100.69.6, 00:01:15, Serial0/2/0
O 150.100.100.2/32 [110/128] via 150.100.69.6, 00:01:15, Serial0/2/0
O 150.100.100.0/24 [110/128] via 150.100.69.6, 00:01:16, Serial0/2/0
O 150.100.81.0/24 [110/130] via 150.100.69.6, 00:01:16, Serial0/2/0
O 150.100.78.0/24 [110/129] via 150.100.69.6, 00:01:16, Serial0/2/0
O 150.100.40.0/24 [110/193] via 150.100.69.6, 00:01:16, Serial0/2/0
O 150.100.41.0/24 [110/193] via 150.100.69.6, 00:01:16, Serial0/2/0
O 150.100.24.0/24 [110/192] via 150.100.69.6, 00:01:16, Serial0/2/0
O 150.100.25.0/24 [110/129] via 150.100.69.6, 00:01:16, Serial0/2/0
O 150.100.12.0/24 [110/129] via 150.100.69.6, 00:01:16, Serial0/2/0
R9(config-router)#do ping 200.0.0.1 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 200.0.0.9
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/30/32 ms
R9(config-router)#
The two furthest points can ping just fine...
The point here being (and I've been watching this with 'debug ip routing' on
for 30 minutes now) that there's not a problem in the basic functionality
here. There may be SOMETHING ELSE that you have configured, or the lab had
you configure that needs to be worked through.
But the basics of brining the peers up with one side point-to-point and the
other side not is not the problem! I think that lab uses R5 as the hub
where I have R2, but no big deal.
Try looking at "debug ip ospf events" or "debug ip ospf adjacency" and see
if there are perhaps other issues coming into play there causing the problem
that you are seeing.
I'm sorry that I'm not able to put Lab39 on my pod right at the moment to
help in more detail.... But the problem you are seeing is not because of
lack of basic functionality there.
HTH,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE-M
#153, JNCIS-ER, CISSP, et al.
CCSI/JNCI-M/JNCI-ER
VP - Technical Training - IPexpert, Inc.
IPexpert Sr. Technical Instructor
A Cisco Learning Partner - We Accept Learning Credits!
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
http://www.ipexpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Chan, Hong
Sent: Tuesday, February 12, 2008 8:37 PM
To: Rich Collins; Chan Hong
Cc: certification Cisco
Subject: RE: IPExpert LAB 39
Dear Collins,
Sorry, there is a typing mistake.
Final config is config R5 as ip ospf network point-to-multipoint
non-broadcast + neighbor, R2 & R6 still keep ip ospf network point-to-point.
and the result is that the ospf neighbor on R6 will get flapping. When the
neighbor form with R2, it will disconnect with R5. few second later,
disconnect with R2 and connect to R5.
Regards,
Howard
-----Original Message-----
From: Rich Collins [mailto:nilsi2002@gmail.com]
Sent: Wednesday, February 13, 2008 8:17 AM
To: Chan Hong
Cc: certification Cisco; Chan, Hong
Subject: Re: IPExpert LAB 39
How about configuring R5 as "ip ospf network point-to-multipoint
non-broadcast"? This should work with the hub a normal "ip ospf network
point-to-multipoint".
-Rich
On Feb 12, 2008 10:24 AM, Chan Hong < chan_hong33@yahoo.com
<mailto:chan_hong33@yahoo.com> > wrote:
Dear all,
In the IPExpert LAB 39, OSPF part. There is a hub & spoke between
R2,R5,R6 and R6 is the hub. The task request to config "ip ospf network
point-to-point" between R2 & R6 and config R5 to not broadcast ospf packet.
The final confi is to config ip ospf network point-to-multipoint
I'm ok with
the R5 config, but this will make the ospf neighbor flapping because R6 is
the point to point ospf interface. the neighbor won't be stable and I supose
it's a problem before I read the final config.
I'm really doubt that it won't
acceable in the real lab, isn't it?
Regards,
Howard
Yahoo!
g62d8
e. e (f ;g %o< f d= e& d= i 2g/ i; e."!
h+ e
e> http://hk.promo.yahoo.com/security/index.html
<http://hk.promo.yahoo.com/security/index.html> d: h'#f 4e$ c
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2008 - 16:54:48 ARST