From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue Aug 05 2003 - 19:21:55 GMT-3
Hey Patrick,
I was trying to force R2 to become the DR by changing it's router-id. I
purposely didn't use the easy way of changing the interface priority ( part
of the experiment in case that's not allowed on the actual lab).
After using the router-id command and then clearing the ospf process and
shutting down interfaces on various routers, I finally was able to force a
new DR election which resulted in R2 becoming the DR.
Here's my take away from all this:
It's very difficult and time consuming to force a new DR election that has
the intended result - a new DR based on a new router-id. I'm still trying
to finding the easiest and quickest way of forcing a new election.
Apparently, after R3 won the first DR election, clearing the ospf process on
R2 doesn't work. R3 remains the DR. I'm checking to see whether after
changing R2's router-id by changing the loopback's ip addr, clearing R3's
ospf process or shutting down R3's s0 will force a new DR election.
Thanks for your help. Raj
----- Original Message -----
From: "Brown, Patrick (NSOC-OCF}" <PBrown4@chartercom.com>
To: "'ccie2be '" <ccie2be@nyc.rr.com>; "'Group Study '"
<ccielab@groupstudy.com>
Sent: Tuesday, August 05, 2003 6:02 PM
Subject: RE: iBGP peers over frame relay & ospf DR elections
> My take if I understand you correctly would be a simple issue. R3
considers
> itself the DR for that segment, so any other router joining will only
become
> the BDR or a Drother, even if I has a higher router id. Shut r3 interface
or
> clear it's ospf process. r1 only see's r2 and not r3 because the OSPF
ttl=1.
> So r1 thinks r2 is the DR for the segement.
> Put " ip ospf priority 255" on r2(hub) serial interface, and clear all
OSPF
> processes.
>
> -----Original Message-----
> From: ccie2be
> To: Group Study
> Sent: 8/5/2003 4:30 PM
> Subject: iBGP peers over frame relay & ospf DR elections
>
> Hi,
>
> First of all, I'd like to thank everybody that responded to my earlier
> post
> regarding the above issue. It's been very helpful.
>
> It also made me take a closer look at OSPF over F/R where something
> quite
> surprising occurred.
>
>
> It's the same basic topology as before:
>
> R1 ------- R2 ------- R3
> spoke hub spoke
>
>
> Each router starts out with their loopback addressed as follows:
> 192.168.x.x
> where x= router #.
>
> I left all the interfaces (both the loopbacks and serial interfaces) at
> their
> default ospf values for priority, ospf network interface type, cost,
> etc.
>
> Because of the constraints in the practice lab I was doing, I was only
> allowed
> one frame relay map on R1 and R3 and I was only allowed to used the
> specified
> f/r dlci's which meant I had to disable inverse-arp on all the f/r
> serial
> interfaces.
>
> I wanted to see which loopback interfaces would show up in each
> router's
> route table and how they would appear (as a host route and/or subnet).
>
> The intial config's were like this:
>
> R1 (R3's config is the same except that the addresses and dlci's were
> change
> as appropriate.)
> int s0
> encap frame-relay
> ip addr 172.16.100.1 255.255.255.0
> fram map ip 172.16.100.2 112 broad
> no frame inverse-arp
>
> router ospf 1
> net 192.168.1.0 0.0.0.255 area 0
> net 172.16.100.0 0.0.0.255 area 0
>
> R2
> int s0
> encap frame relay
> ip addr 172.16.100.2 255.255.255.0
> fram map ip 172.16.100.1 211 broad
> fram map ip 172.16.100.3 233 broad
> no fram inverse-arp
>
> router ospf 1
> net 172.16.100.0 0.0.0.255 area 0
> net 192.168.2.0 0.0.0.255 area 0
>
> The result:
>
> R2 can ping both R1 and R3 but R1 can't ping R3 or vice versa.
> The loopback interfaces of all 3 routers are in the route tables of all
> 3
> routers but R1 and R3 can't ping each others loopback addresses.
>
> On R2, the output of show ip os nei is
>
> nei id Pri State
> 192.168.3.3 1 Full/Dr
> 192.168.1.1 1 Full/DRother
>
> This result wasn't unexpected but I wondered what would happen if I
> forced R2
> to be the DR. So, I changed R2's loopback int to be 192.168.22.2/24 and
> added
> that subnet under the ospf process and cleared the ospf process.
>
> Here's the surprise!!!
>
> The output of show ip os nei stayed the same. Then I checked the output
> of
> show ip os int s0 and it confirmed that R3 was still the designated
> router. I
> also tried using the router-id command under the ospf process on R2 and
> cleared the ospf process again. (BTW, it takes over 3 minutes for the
> new
> ospf adjacencies to form) Still, R3 remained the DR.
>
> I also checked in Doyle book Routing TCP/IP vol 1 how the DR is elected.
> And,
> it confirmed that, essentially, the router with the router with the
> highest
> router id becomes the DR if all the priorities are equal.
>
> I also shut down int s0 on R2 then turned it back on. Still the same
> result -
> R3 remains the DR.
>
> Why can't I force R2 to be the DR? And, why does R3 considers R2 the
> BDR but
> R1 considers R2 the DR.
>
> Sorry for such a long post. Raj
>
>
> _______________________________________________________________________
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Sep 02 2003 - 18:53:53 GMT-3