Using addresses associated with loopback interfaces (with ospf) has two
advantage :
1) The lo interface is more stable than any physical interface. It is active
when a
router boots up, and it only fails if the entire router fails.
2) The network administrator usually prefer to use a predictable or recognize
addresses as the Router IDs.
Information: OSPF will continue to use a Router ID learned even if the interface
subsequently fails. Therefore, the stability ot a loopback interface is only a
minor
advantage. The primary benefit is the ability to control the router ID ....
(Jeff doyle).
Hope this help.
Chuck Larrieu wrote:
> 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
>
> _______________________________________________________
> To unsubscribe from the CCIELAB list, send a message to
> [EMAIL PROTECTED] with the body containing:
> unsubscribe ccielab
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
