Re: OSPF over NBMA

From: fwells12 (fwells12@xxxxxxxxxxx)
Date: Fri Nov 02 2001 - 18:38:27 GMT-3


   
Reboot the routers...

----- Original Message -----
From: "Kirby, Ron" <Ron.Kirby@getronics.com>
To: "'Ajaz Nawaz'" <anawaz@cisco.com>; <ccielab@groupstudy.com>
Sent: Friday, November 02, 2001 12:58 PM
Subject: RE: OSPF over NBMA

> Interestingly, after reviewing the "sh ip ospf int" (shown below) I found
> that R3 and R4 both thought they were the DR and R1 was the BDR for both.
I
> checked the routing tables, R3 has no info on loopbacks on r1 and r4. I
> also checked the Linkstate database and found that 3 didn't have some of
the
> links from 4. My conclusion is that R1 is taking updates from R4, and in
> keeping with the DR/BDR scheme, not sending them to R3, but expecting R4
to
> send updates to R3. Now this adds to the problem, as I have set up a
simple
> hub and spoke, and by expecting the neighbor command to work as Doyle
> explained, I should have seen the hub become the DR, because the default
> priority is zero for the spokes. While working on this, I explicitly set
> the priority to zero and reset the interface, R4 came up as the DR and the
> config showed the priorities set to 1. Is this a bug? Do I need the
> neighbor command on the spokes with a priority set to something higher
than
> the defaults to ensure the hub becomes the DR?
>
>
> r1#sh ip ospf int s0/0 (3620 with c3620-ds-mz.121-5.T9.bin)
> Serial0/0 is up, line protocol is up
> Internet Address 134.5.20.1/28, Area 0
> Process ID 1, Router ID 134.5.1.1, Network Type NON_BROADCAST, Cost: 48
> Transmit Delay is 1 sec, State BDR, Priority 1
> Designated Router (ID) 134.5.4.4, Interface address 134.5.20.4
> Backup Designated router (ID) 134.5.1.1, Interface address 134.5.20.1
> Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
> Hello due in 00:00:28
> Index 2/2, flood queue length 0
> Next 0x0(0)/0x0(0)
> Last flood scan length is 0, 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 134.5.4.4 (Designated Router)
> Adjacent with neighbor 134.5.3.3
> Suppress hello for 0 neighbor(s)
>
>
> R3#sh ip ospf int s0 (2501 with c2500-d-l.120-18.bin)
> Serial0 is up, line protocol is up
> Internet Address 134.5.20.3/28, Area 0
> Process ID 1, Router ID 134.5.3.3, Network Type NON_BROADCAST, Cost: 64
> Transmit Delay is 1 sec, State DR, Priority 1
> Designated Router (ID) 134.5.3.3, Interface address 134.5.20.3
> Backup Designated router (ID) 134.5.1.1, Interface address 134.5.20.1
> Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
> Hello due in 00:00:03
> Neighbor Count is 1, Adjacent neighbor count is 1
> Adjacent with neighbor 134.5.1.1 (Backup Designated Router)
> Suppress hello for 0 neighbor(s)
>
> r4#sh ip ospf int s0 (2501 with c2500-d-l.120-18.bin)
> Serial0 is up, line protocol is up
> Internet Address 134.5.20.4/28, Area 0
> Process ID 1, Router ID 134.5.4.4, Network Type NON_BROADCAST, Cost: 64
> Transmit Delay is 1 sec, State DR, Priority 1
> Designated Router (ID) 134.5.4.4, Interface address 134.5.20.4
> Backup Designated router (ID) 134.5.1.1, Interface address 134.5.20.1
> Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
> Hello due in 00:00:05
> Neighbor Count is 1, Adjacent neighbor count is 1
> Adjacent with neighbor 134.5.1.1 (Backup Designated Router)
> Suppress hello for 0 neighbor(s)
>
> Ron Kirby
> CCNP, MCSE, CNA
> Network Engineer
> Getronics, Houston ESC
> 713-852-5567 / 832-256-5403
> ron.kirby@getronics.com
>
> This e-mail message and any attachments are confidential and may be
> privileged. If you are not the intended recipient, please notify me
> immediately by replying to this message and please destroy all copies of
> this message and attachments. Thank you.
>
>
>
>
>
> -----Original Message-----
> From: Ajaz Nawaz [mailto:anawaz@cisco.com]
> Sent: Friday, November 02, 2001 1:22 PM
> To: Kirby, Ron; ccielab@groupstudy.com
> Subject: RE: OSPF over NBMA
>
>
> please mail us the output from show ip ospf interface from the hub and the
> spokes.
>
> tia
> jaz
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Kirby, Ron
> Sent: 02 November 2001 18:43
> To: 'ccielab@groupstudy.com'
> Subject: OSPF over NBMA
>
>
> In his book, IP routing V.I, Doyle says (pg 558):
>
> "The neighbor command configures...with address..of its three neighbors.
> The default priority is zero; by not changing the default...none of its
> neighbors is eligible to become the DR or BDR."
>
> I'm running a multipoint subinterface (R1 hub) to two physical serial
frame
> interfaces utilizing the neighbor command on the hub. With 12.1-5T code,
> the router automatically added a priority to one of my neighbor
statements:
>
> R1:
> router ospf 1
> network 134.5.1.0 0.0.0.255 area 0
> network 134.5.20.0 0.0.0.255 area 0
> neighbor 134.5.20.3 priority 1 <--- added by IOS
> neighbor 134.5.20.4
> !
>
> And then the highest IP loopback became the DR after the 3.3 router was
the
> DR:
>
> r1#sh ip ospf nei
> Neighbor ID Pri State Dead Time Address
Interface
> 134.5.3.3 1 FULL/DR 00:01:44 134.5.20.3
> Serial0/0.2
> N/A 0 ATTEMPT/DROTHER 00:01:14 134.5.20.4
> Serial0/0.2
> 1w0d: %OSPF-5-ADJCHG: Process 1, Nbr 134.5.4.4 on Serial0/0.2 from LOADING
> to FULL, Loading r1#sh ip ospf nei
> Neighbor ID Pri State Dead Time Address
Interface
> 134.5.3.3 1 FULL/DROTHER 00:01:57 134.5.20.3
> Serial0/0.2
> 134.5.4.4 1 FULL/DR 00:01:57 134.5.20.4
> Serial0/0.2
>
>
> And then the router added the priority to the second neighbor statement:
>
> R1:
> router ospf 1
> network 134.5.1.0 0.0.0.255 area 0
> network 134.5.20.0 0.0.0.255 area 0
> neighbor 134.5.20.3 priority 1 <--added by IOS
> neighbor 134.5.20.4 priority 1 <--added by IOS
>
> Doyle's next paragraph states that, in his example, the spoke routers were
> configured with the IP address of the hub with a priority of 10, "which
> means.....will become the DR." Well, didn't the use of the neighbor
> statement with a default priority of zero ensure that the hub router would
> become the DR? I found this exact behavior when I used physical
interfaces
> all around. So I ruled out differences of physical interfaces compared to
> subinterfaces. Am I missing something?
>
> Thanks
> Ron Kirby
> CCNP, MCSE, CNA
> Network Engineer
> Getronics, Houston ESC
> 713-852-5567 / 832-256-5403
> ron.kirby@getronics.com
>
> This e-mail message and any attachments are confidential and may be
> privileged. If you are not the intended recipient, please notify me
> immediately by replying to this message and please destroy all copies of
> this message and attachments. Thank you.
>
>
>
>
>
> -----Original Message-----
> From: Dennis Laganiere [mailto:dennisl@advancedbionics.com]
> Sent: Friday, November 02, 2001 11:37 AM
> To: 'ccielab@groupstudy.com'
> Subject: Redistribution matrix
>
>
> I've sent out almost 100 copies of what we have so far. The e-mails were
> coming fast and furious, so if you still want a copy or if I missed you,
> please send me an e-mail. This is a slightly different version then I
sent
> yesterday. I tried to incorporate Eric's excellent thoughts (EA Louie).
>
> If even a portion of the people I sent it to feel like contributing, we
> should be able to put together an excellent guide to redistribution that
we
> can all use to study from. If you do send me any changes or additions,
> please use a different colored text so I can easily identify the changes.
> Here's what I would like to accomplish:
> * What I was trying to put together was something easy to
> navigate that would have a sample configuration and a list of the issues
for
> each possible redistribution.
> * I would like to keep the document "open" so people can
> adapted it to their own study style. I used an MS Word document, but if
you
> want something else, let me know.
> * I'd like to keep it simple enough that even someone of my
> limited intelligence could figure out what's going on.
> Let me know your thoughts...
> --- Dennis
>
> <<Redistribution Matrix.doc>>
>
> [GroupStudy.com removed an attachment of type application/msword which had
a
> name of Redistribution Matrix.doc]



This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 06:45:02 GMT-3