Much as I personally rant about cross posting the two lists, I believe this
one might be worth examination from all levels.
Recall the questions and answers about the purpose of the loopback
interface, particularly in OSPF. Among the answers proposed is that the
loopback, being always up, provides continuity, in case an interface fails.
In particular, the book answer is that because the loopback is always up, it
provides the means of reaching a router so long as the loopback is reachable
via any interface that remains operational.
I wish this lab had been a bit quicker and less dirty. But it has provided
an interesting learning experience for me. Thought I would pass along my
observations for those who want to ponder yet another protocol behaviour.
My supposition:
------------------------------------- ethernet
| | |
DR BDR DR/other
| | |
(---frame relay cloud ----)
>DR ethernet hardware fails.
>
>I would venture a guess that the BDR
>would be promoted because even though there is an alternative route to the
>DR loopback, hellos go only to adjacent routers, and the DR is no longer
>adjacent.
Well, I proved my point. Under this scenario, when I unplug the DR ethernet
port, the BDR becomes the DR.
Some router outputs are listed below. I hope this message falls below the
reject size threshold.
OK. The observations:
1) I am correct that in the case of the ethernet DR becoming disabled, the
BDR still becomes the DR.
2) If the frame cloud is a different area than the ethernet segment, the
loopback route disappears. This behaviour is specific to OSPF, because of
the fact that all inter-area traffic MUST pass through area 0. When the area
0 link goes down, the route to the loopback may disappear, depending upon
the OSPF topology.
3) When I reconfigured everything so that both the frame relay and ethernet
segments were area 0, and the loopback interfaces remained visible via the
frame segment after disconnecting the ethernet segment, the process still
occurred as predicted. That is, the BDR became the DR and the DR/Other
became the BDR. The fact that the loopback route remained visible had NO
EFFECT whatsoever on the DR/BDR situation. Why? Because the DR/BDR
relationship is unique to a segment. Again, this is a behaviour specific to
OSPF.
4) My frame cloud was configured as a point to multipoint network. As you
will see in the outputs, the routers form full adjacencies on the frame
segment, but elect no DR or BDR. I believe that if I were to configure the
frame segment as a broadcast network, that DR and BDR's would be elected,
but that those designations would remain local to that segment, and would
have no effect on any transactions on the ethernet segment. I leave that
experiment to some other brave soul.
Conclusion:
With regards to OSPF, at least, the idea that the loopback interface
provides any kind of reliability is in and of itself not true. Problems
arise with the advertising of the loopback throughout the OSPF domain,
particularly when the area 0 connection is lost, and the alternate routes do
not propogate.
This of course is not an issue with IGRP or EIGRP or even RIP, which do not
have the same restriction with regards to routing behaviours. So while in
OSPF the existence of a loopback interface might prove to be of no use, and
probably more often than one might care to imagine, it still will prove
quite useful within other routing protocols.
The outputs:
BackDesRouter#sh ip route
O IA 200.200.200.0/24 [110/11] via 192.168.1.1, 00:01:42, Ethernet0<------DR
RID
160.160.0.0/24 is subnetted, 1 subnets
O IA 160.160.160.0 [110/11] via 192.168.1.3, 00:01:42, Ethernet0
C 192.168.1.0/24 is directly connected, Ethernet0
192.168.2.0/24 is variably subnetted, 3 subnets, 2 masks
O 192.168.2.3/32 [110/10] via 192.168.1.3, 00:01:42, Ethernet0
C 192.168.2.0/24 is directly connected, Serial0
O 192.168.2.1/32 [110/10] via 192.168.1.1, 00:01:42, Ethernet0
180.180.0.0/24 is subnetted, 1 subnets
C 180.180.180.0 is directly connected, Loopback0
BackDesRouter#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
160.160.160.1 1 FULL/DROTHER 00:00:31 192.168.1.3 Ethernet0
200.200.200.1 1 FULL/DR 00:00:30 192.168.1.1
Ethernet0<------DR neighbor
200.200.200.1 1 FULL/ - 00:01:34 192.168.2.1 Serial0
160.160.160.1 1 FULL/ - 00:01:31 192.168.2.3 Serial0
unplug DR
BackDesRouter#deb ip ospf ev
OSPF events debugging is on
BackDesRouter#
00:47:23: OSPF: Neighbor change Event on interface Ethernet0
00:47:23: OSPF: DR/BDR election on Ethernet0
00:47:23: OSPF: Elect BDR 180.180.180.1
00:47:23: OSPF: Elect DR 180.180.180.1
00:47:23: OSPF: Elect BDR 160.160.160.1
00:47:23: OSPF: Elect DR 180.180.180.1
00:47:23: DR: 180.180.180.1 (Id) BDR: 160.160.160.1 (Id)
00:47:23: OSPF: Remember old DR 200.200.200.1 (id)
BackDesRouter#u all
All possible debugging has been turned off
BackDesRouter#sh ip route
O IA 200.200.200.0/24 [110/65] via 192.168.2.1, 00:00:19,
Serial0<---loopback address still visible via the frame segment
160.160.0.0/24 is subnetted, 1 subnets
O IA 160.160.160.0 [110/11] via 192.168.1.3, 00:00:19, Ethernet0
C 192.168.1.0/24 is directly connected, Ethernet0
192.168.2.0/24 is variably subnetted, 3 subnets, 2 masks
O 192.168.2.3/32 [110/10] via 192.168.1.3, 00:00:19, Ethernet0
C 192.168.2.0/24 is directly connected, Serial0
O 192.168.2.1/32 [110/64] via 192.168.2.1, 00:00:19, Serial0
180.180.0.0/24 is subnetted, 1 subnets
C 180.180.180.0 is directly connected, Loopback0
BackDesRouter#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
160.160.160.1 1 FULL/BDR 00:00:36 192.168.1.3 Ethernet0
200.200.200.1 1 FULL/ - 00:01:58 192.168.2.1 Serial0
160.160.160.1 1 FULL/ - 00:01:55 192.168.2.3 Serial0
BDR is now the DR, despite the fact that the RID of the former DR is still
visible via the frame segment.
QED
Chuck
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
