RE: OSPF Topology Question - Parkhurst's Book [7:65532]

2003-03-16 Thread richard dumoulin
Hey Chuck,

 Which book is this one ?

Cheers.


Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=65550&t=65532
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]


RE: OSPF Topology Question - Parkhurst's Book [7:65532]

2003-03-16 Thread cebuano
Hey Chuck,
I don't know how this slipped past me ;->
You are correct. Not only is RtrB configured the same as RtrC, but the
solution only allows the hub/spoke to form adjacencies. This is one of
the many reasons why routes are in the OSPF database but NOT in the
routing table. I'm not sure if all he wanted to show was the effect of
different Hello parameters.
Interesting that the only corrections on the Ciscopress site are the
ones I sent to Bill. You should send him this as well, in case he hasn't
yet noticed this issue.

Elmer

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
The Long and Winding Road
Sent: Sunday, March 16, 2003 1:14 AM
To: [EMAIL PROTECTED]
Subject: OSPF Topology Question - Parkhurst's Book [7:65532]

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=65557&t=65532
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]


Re: OSPF Topology Question - Parkhurst's Book [7:65532]

2003-03-16 Thread Mike
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.

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=65560&t=65532
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]


RE: OSPF Topology Question - Parkhurst's Book [7:65532]

2003-03-16 Thread Daniel Cotts
"Cisco OSPF Command and Configuration Handbook"
by William R Parkhurst ISBN 1587050714

> -Original Message-
> From: richard dumoulin [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 16, 2003 2:06 PM
> To: [EMAIL PROTECTED]
> Subject: RE: OSPF Topology Question - Parkhurst's Book [7:65532]
> 
> 
> Hey Chuck,
> 
>  Which book is this one ?
> 
> Cheers.




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=65562&t=65532
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]


Re: OSPF Topology Question - Parkhurst's Book [7:65532]

2003-03-17 Thread The Long and Winding Road
""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 0x8003 0x005E7F 4
2.2.2.2 2.2.2.2 214 0x8004 0x00D1F1 1
206.6.6.6   206.6.6.6   138 0x8002 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 0x8003 0x5E7F   4
2.2.2.2 2.2.2.2 273 0x8004 0xD1F1   1
206.6.6.6   206.6.6.6   199 0x8002 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 0x8003 0x5E7F   4
2.2.2.2 2.2.2.2 313 0x8004 0xD1F1   1
206.6.6.6   206.6.6.6   238 0x8002 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 IA2.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 IA3.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.
> >
> > Exc

Re: OSPF Topology Question - Parkhurst's Book [7:65532]

2003-03-17 Thread Priscilla Oppenheimer
Parkhurst's example didn't work on my routers either, for what it's worth.
With the spoke configured with a neighbor it tried to elect a BDR and DR,
using unicast packets to its neighbor.

The hub router, which was using subinterfaces, seemed to ignore these pleas
to be neighborly.

They didn't become neighbors and the routing table was missing OSPF routes.

I changed the spoke to point-to-multipoint and the spoke started sending
multicasts to 224.0.0.5. No BDR or DR was established, but neighborliness
was established, and OSPF routes got installed. I forgot to keep the debug
output, but I think that's what happened and that is what should happen,
from what I understand.

Priscilla

The Long and Winding Road wrote:
> 
> ""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 0x8003 0x005E7F
> 4
> 2.2.2.2 2.2.2.2 214 0x8004 0x00D1F1
> 1
> 206.6.6.6   206.6.6.6   138 0x8002 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 0x8003 0x5E7F  
> 4
> 2.2.2.2 2.2.2.2 273 0x8004 0xD1F1  
> 1
> 206.6.6.6   206.6.6.6   199 0x8002 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 0x8003 0x5E7F  
> 4
> 2.2.2.2 2.2.2.2 313 0x8004 0xD1F1  
> 1
> 206.6.6.6   206.6.6.6   238 0x8002 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 IA2.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 IA3.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,

Re: OSPF Topology Question - Parkhurst's Book [7:65532]

2003-06-24 Thread ericbrouwers
I haven't seen any feedback from others on your thoughts. See my comments
below.

Eric

- Original Message -
From: "The Long and Winding Road" 
To: 
Sent: Sunday, March 16, 2003 8:13 AM
Subject: OSPF Topology Question - Parkhurst's Book [7:65532]


> 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.

Neither do I, but I'm not sure. I wouldn't configure it like this. The spoke
routers ( physical interfaces ) try to elect DR/BDR, which is not applicable
for point-to-point interface on hub router.

Note: if it were IS-IS, it would fail, since network types must match.

>
> 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.

Yep.

>
> I believe the correct solution is to make the physical interfaces ospf
type
> point-to-multipoint.

If hub is p2p and spokes are p2m, then:
- neither side requires DR/BDR election, which is good;
- no manual neighbor configuration needed, which is good as well;
- hello/dead timer are different (10/40 vs. 30/120 s), so you need to change
one side, don't you?

This should work.

>
> An alternative is to change the physical interfaces to ospf
point-to-point.
>

Yes.

> 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?
>

I don't have that book. My still-to-read-pile is already too big.

> 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=71301&t=65532
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]