""Mike"" wrote in message
news:[EMAIL PROTECTED]
> Since the spoke routers are NBMA, multicast hello's will not locate the
> neighbor. The ospf router neighbor command must be used to manually
identify
> the neighbor so routing updates can be exchanged. I'm not sure why you
> would want to implement in this way, but it will work.
Parkhurst is attempting to tach a lesson about the neighbor statement.
Unfortunately, the lesson appears not be be complete.
You say it should work. So I srt this one up again. Observe:
Router 1 OSPF database excerpt
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 138 0x80000003 0x005E7F 4
2.2.2.2 2.2.2.2 214 0x80000004 0x00D1F1 1
206.6.6.6 206.6.6.6 138 0x80000002 0x00C348 1
Router 1 routing table:
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback1
10.0.0.0/30 is subnetted, 2 subnets
C 10.1.1.0 is directly connected, Serial1.2
C 10.1.1.4 is directly connected, Serial1.3
R1#
Router 2 OSPF database excerpt
OSPF Router with ID (2.2.2.2) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 198 0x80000003 0x5E7F 4
2.2.2.2 2.2.2.2 273 0x80000004 0xD1F1 1
206.6.6.6 206.6.6.6 199 0x80000002 0xC348 1
Router 2 routing table:
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback1
10.0.0.0/30 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Serial1
R2#
Router 3 OSPF database excerpt
OSPF Router with ID (206.6.6.6) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 238 0x80000003 0x5E7F 4
2.2.2.2 2.2.2.2 313 0x80000004 0xD1F1 1
206.6.6.6 206.6.6.6 238 0x80000002 0xC348 1
Router 3 routing table
Gateway of last resort is not set
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback0
10.0.0.0/30 is subnetted, 1 subnets
C 10.1.1.4 is directly connected, Serial1
R3#
Change the spoke ospf network types from non broadcast to
point-to-multipoint and ( sample from one router, but it is true for all:)
pops right up:
01:16:07: OSPF: Database request to 2.2.2.2
01:16:07: OSPF: sent LS REQ packet to 10.1.1.2, length 12
01:16:07: OSPF: Synchronized with 206.6.6.6 on Serial1.3, state FULL
01:16:07: %OSPF-5-ADJCHG: Process 1, Nbr 206.6.6.6 on Serial1.3 from LOADING
to
FULL, Loading Done
01
R1#:16:07: OSPF: Rcv DBD from 2.2.2.2 on Serial1.2 seq 0x9C5 opt 0x42 flag
0x1 l
en 32 mtu 1500 state EXCHANGE
01:16:07: OSPF: Exchange Done with 2.2.2.2 on Serial1.2
01:16:07: OSPF: Send DBD to 2.2.2.2 on Serial1.2 seq 0x9C5 opt 0x42 flag 0x0
len
32
01:16:07: OSPF: Synchronized with 2.2.2.2 on Serial1.2, state FULL
01:16:07: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1.2 from LOADING
to FU
LL, Loading Done
R1#
and routing table has ospf routes:
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback1
2.0.0.0/32 is subnetted, 1 subnets
O IA 2.2.2.2 [110/65] via 10.1.1.2, 00:00:02, Serial1.2
3.0.0.0/32 is subnetted, 1 subnets
O IA 3.3.3.3 [110/65] via 10.1.1.6, 00:00:02, Serial1.3
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O 10.1.1.2/32 [110/64] via 10.1.1.2, 00:00:02, Serial1.2
C 10.1.1.0/30 is directly connected, Serial1.2
O 10.1.1.6/32 [110/64] via 10.1.1.6, 00:00:03, Serial1.3
C 10.1.1.4/30 is directly connected, Serial1.3
R1#
as to whether this is one of the vagueries of the IOS versions I am running,
I cannot say. But even speaking teoretically, a point-to-point link will not
form a proper adjacency with an NMBA link, neighbor staement or no. Each
side thinks the other is like itself, and they are not the same.
Examples to the contrary are welcome.
>
> Regards
>
> ""The Long and Winding Road"" wrote in
> message news:[EMAIL PROTECTED]
> > Ran into something in Parkhurst's OSPF book while studying tonight.
> Looking
> > for validation of my observation.
> >
> > The example: OSPF over frame relay
> >
> > The topology: hub and spoke, with a twist. The hub uses subinterfaces (
> one
> > to each spoke router ) and the spokes use physical interfaces.
> >
> > Now, the Parkhurst examples show leaving the physical interfaces as ospf
> > type non-broadcast, change the ospf timers on the subinterfaces, place
> > neighbor statements on the spoke routers ( physical interfaces ) and all
> is
> > well.
> >
> > Except I don't believe it works this way.
> >
> > The subinterfaces are point-to-point networks, and expect the other side
> to
> > be a point-to-point connection and adjacency. the physical interfaces
are
> > non-broadcast, and expect DR elections to occur, something the router
with
> > the subinterfaces will not do.
> >
> > I believe the correct solution is to make the physical interfaces ospf
> type
> > point-to-multipoint.
> >
> > An alternative is to change the physical interfaces to ospf
> point-to-point.
> >
> > In any case - can anyone else verify what I see and do not see - that
> > Parkhurst chapter 11, example 3, pages 275-279 answer is incomplete?
> >
> > thanks.
> >
> > --
> > TANSTAAFL
> > "there ain't no such thing as a free lunch"
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=65576&t=65532
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
