OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
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 IA160.160.160.0 [110/11] via 192.168.1.3, 00:01:42, Ethernet0 C192.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/DROTHER00:00:31192.168.1.3 Ethernet0 200.200.200.1 1 FULL/DR 00:00:30192.168.1.1 Ethernet0<--DR neighbor 200.200.200.1 1 FULL/ -00:01:34192.168.2.1 Serial0 160.160.160.1 1 FULL/ -00:01:31192.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: OS
Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
As per david's msg, it would seem that I may be entirely mistaken! (like thats a first :) headed back to study :) pete *** REPLY SEPARATOR *** On 11/29/2000 at 8:58 AM Peter Van Oene wrote: >One or two comments inset. > >Chuck's Text >>>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. >> >>1) I am correct that in the case of the ethernet DR becoming disabled, the >>BDR still becomes the DR. >> >> >>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. > >A couple quick notes. The resiliency that using a loopback interface on an ospf >router has little to do with individual segments. Naturally, if you lose an >interface into a multi access segment you will lose your adjacencies on that segment. > > >However, let consider a router with 4 interfaces. Without using a loopback >interface, if the interface with the highest IP address dies, the routers RID >changes. What this means is that not only does the router lose its adjacencies on >the defective interface, it also must changes its RID to the next highest address. >This will force it to lose and rebuild all other adjacencies and as far as I know, >for every router in the area to recalculate their SPF tree's. Using a loopback >address, in the same situation, this failure would be contained to the one segment. > >Pete > > > >_ >FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
One or two comments inset. Chuck's Text >>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. > >1) I am correct that in the case of the ethernet DR becoming disabled, the >BDR still becomes the DR. > > >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. A couple quick notes. The resiliency that using a loopback interface on an ospf router has little to do with individual segments. Naturally, if you lose an interface into a multi access segment you will lose your adjacencies on that segment. However, let consider a router with 4 interfaces. Without using a loopback interface, if the interface with the highest IP address dies, the routers RID changes. What this means is that not only does the router lose its adjacencies on the defective interface, it also must changes its RID to the next highest address. This will force it to lose and rebuild all other adjacencies and as far as I know, for every router in the area to recalculate their SPF tree's. Using a loopback address, in the same situation, this failure would be contained to the one segment. Pete _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
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 IA160.160.160.0 [110/11] via 192.168.1.3, 00:01:42, Ethernet0 > C192.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 > > Neighbo
Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
Chuck and others, I've been following this conversation and it is a good review. Without a loopback interface, the OSPF RID (Router ID) will be the highest IP address on the router when the OSPF process becomes active. If that interface isn't stable (say the highest IP is on a WAN circuit) then when that interface bounces it will cause OSPF to re-converge. Using a loopback interface, the OSPF RID will be the highest IP on a loopback when the OSPF process starts. If you have OSPF running already and add loopback interfaces OSPF doesn't use the loopback IP address for a RID until the OSPF process is restarted, removed and added back (copy-paste), or the router is rebooted on saved cfg. So for a stable OSPF environment, using loopbacks reduces the chances of un-necessary OSPF re-convergance and updates occuring when a interface bounces. Example, if you had no loopbacks and had s1 and e1 interfaces. s1 having highest IP and was RID but s1 wasn't running OSPF - when s1 bounced for whatever reason OSPF would re-converge because the OSPF RID went down and came back up. Also, you don't need to advertise the loopback IP address into routing protocols unless you want to reach that from another device. I hope this clears things up... it's late so I hope my explanation makes sense. :) If not, hit me for the mistakes if your ever in Chicago area. Erick B. - Prepping for attempt 2. (Why am I still up at 6am?) --- Chuck Larrieu <[EMAIL PROTECTED]> 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.
Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
I thought OSPF is suppose to converge whenever you have a change in the route. I.e whenever any interface bounce.. regardless of the OSPF Router ID. The difference is probably in terms of the amount of "data" being sent.. but definitely a covergence would occur.. - Original Message - From: "Erick B." <[EMAIL PROTECTED]> To: "Chuck Larrieu" <[EMAIL PROTECTED]>; "CCIE_Lab Groupstudy List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: "Priscilla Oppenheimer" <[EMAIL PROTECTED]> Sent: Thursday, November 30, 2000 8:04 PM Subject: Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces > Chuck and others, > > I've been following this conversation and it is a good > review. > > Without a loopback interface, the OSPF RID (Router ID) > will be the highest IP address on the router when the > OSPF process becomes active. If that interface isn't > stable (say the highest IP is on a WAN circuit) then > when that interface bounces it will cause OSPF to > re-converge. > > Using a loopback interface, the OSPF RID will be the > highest IP on a loopback when the OSPF process starts. > If you have OSPF running already and add loopback > interfaces OSPF doesn't use the loopback IP address > for a RID until the OSPF process is restarted, removed > and added back (copy-paste), or the router is rebooted > on saved cfg. > > So for a stable OSPF environment, using loopbacks > reduces the chances of un-necessary OSPF > re-convergance and updates occuring when a interface > bounces. Example, if you had no loopbacks and had s1 > and e1 interfaces. s1 having highest IP and was RID > but s1 wasn't running OSPF - when s1 bounced for > whatever reason OSPF would re-converge because the > OSPF RID went down and came back up. > > Also, you don't need to advertise the loopback IP > address into routing protocols unless you want to > reach that from another device. > > I hope this clears things up... it's late so I hope my > explanation makes sense. :) If not, hit me for the > mistakes if your ever in Chicago area. > > Erick B. - Prepping for attempt 2. > (Why am I still up at 6am?) > > --- Chuck Larrieu <[EMAIL PROTECTED]> 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
RE: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
OSPF would not reconverge if the interface serving as the router ID was not part of OSPF (i.e. a router with an interface in BGP or EIGRP that has a higher IP address than any interface on the same router that is part of OSPF). In that situation, a link flapping, would cause reconvergence (due to the disappearing RID) even though there was no change in the OSPF topology). Of course this assumes no redistribution is taking place. John Galt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Sent: Thursday, November 30, 2000 10:26 AM To: Erick B.; Chuck Larrieu; CCIE_Lab Groupstudy List; [EMAIL PROTECTED] Subject: Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces I thought OSPF is suppose to converge whenever you have a change in the route. I.e whenever any interface bounce.. regardless of the OSPF Router ID. The difference is probably in terms of the amount of "data" being sent.. but definitely a covergence would occur.. - Original Message - From: "Erick B." <[EMAIL PROTECTED]> To: "Chuck Larrieu" <[EMAIL PROTECTED]>; "CCIE_Lab Groupstudy List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: "Priscilla Oppenheimer" <[EMAIL PROTECTED]> Sent: Thursday, November 30, 2000 8:04 PM Subject: Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces > Chuck and others, > > I've been following this conversation and it is a good > review. > > Without a loopback interface, the OSPF RID (Router ID) > will be the highest IP address on the router when the > OSPF process becomes active. If that interface isn't > stable (say the highest IP is on a WAN circuit) then > when that interface bounces it will cause OSPF to > re-converge. > > Using a loopback interface, the OSPF RID will be the > highest IP on a loopback when the OSPF process starts. > If you have OSPF running already and add loopback > interfaces OSPF doesn't use the loopback IP address > for a RID until the OSPF process is restarted, removed > and added back (copy-paste), or the router is rebooted > on saved cfg. > > So for a stable OSPF environment, using loopbacks > reduces the chances of un-necessary OSPF > re-convergance and updates occuring when a interface > bounces. Example, if you had no loopbacks and had s1 > and e1 interfaces. s1 having highest IP and was RID > but s1 wasn't running OSPF - when s1 bounced for > whatever reason OSPF would re-converge because the > OSPF RID went down and came back up. > > Also, you don't need to advertise the loopback IP > address into routing protocols unless you want to > reach that from another device. > > I hope this clears things up... it's late so I hope my > explanation makes sense. :) If not, hit me for the > mistakes if your ever in Chicago area. > > Erick B. - Prepping for attempt 2. > (Why am I still up at 6am?) > > --- Chuck Larrieu <[EMAIL PROTECTED]> 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 > >
Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
Right. But if a interface bounces that isn't part of OSPF that shouldn't cause a OSPF reconvergence to occur. Thats what I was attempting to say below. --- Jason <[EMAIL PROTECTED]> wrote: > I thought OSPF is suppose to converge whenever you > have a change in the > route. I.e whenever any interface bounce.. > regardless of the OSPF Router ID. > The difference is probably in terms of the amount of > "data" being sent.. but > definitely a covergence would occur.. > > > > - Original Message - > From: "Erick B." <[EMAIL PROTECTED]> > To: "Chuck Larrieu" <[EMAIL PROTECTED]>; "CCIE_Lab > Groupstudy List" > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Cc: "Priscilla Oppenheimer" <[EMAIL PROTECTED]> > Sent: Thursday, November 30, 2000 8:04 PM > Subject: Re: OSPF Lab - DR behaviour with loopbacks > WAS: RE: question about > loopback interfaces > > > > Chuck and others, > > > > I've been following this conversation and it is a > good > > review. > > > > Without a loopback interface, the OSPF RID (Router > ID) > > will be the highest IP address on the router when > the > > OSPF process becomes active. If that interface > isn't > > stable (say the highest IP is on a WAN circuit) > then > > when that interface bounces it will cause OSPF to > > re-converge. > > > > Using a loopback interface, the OSPF RID will be > the > > highest IP on a loopback when the OSPF process > starts. > > If you have OSPF running already and add loopback > > interfaces OSPF doesn't use the loopback IP > address > > for a RID until the OSPF process is restarted, > removed > > and added back (copy-paste), or the router is > rebooted > > on saved cfg. > > > > So for a stable OSPF environment, using loopbacks > > reduces the chances of un-necessary OSPF > > re-convergance and updates occuring when a > interface > > bounces. Example, if you had no loopbacks and had > s1 > > and e1 interfaces. s1 having highest IP and was > RID > > but s1 wasn't running OSPF - when s1 bounced for > > whatever reason OSPF would re-converge because the > > OSPF RID went down and came back up. > > > > Also, you don't need to advertise the loopback IP > > address into routing protocols unless you want to > > reach that from another device. > > > > I hope this clears things up... it's late so I > hope my > > explanation makes sense. :) If not, hit me for the > > mistakes if your ever in Chicago area. > > > > Erick B. - Prepping for attempt 2. > > (Why am I still up at 6am?) > > > > --- Chuck Larrieu <[EMAIL PROTECTED]> 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 b
Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
Yes, a convergence would occur anyway, but if the Router ID changes, a lot more things could go wrong. For example, virtual links are configured using the Router ID. If the router ID changes (like by having a serial interface your RID), the virtual link goes down. Having loopbacks as your Router IDs also allows for you to more easily manage your OSPF network. All entries in the OSPF database are based on RIDs. If you make all your loopbacks in the same network (i.e. R1 is 10.0.0.1, R2 is 10.0.0.2), it makes it easier to identify the routers. Since the loopback itself does not need to be in OSPF, it doesn't matter that they're all on the same network. Or, you could just use a mask of /32. I'm not saying you'll be able to do this in the lab, just real world tips. Tony - Original Message - From: "Jason" <[EMAIL PROTECTED]> To: "Erick B." <[EMAIL PROTECTED]>; "Chuck Larrieu" <[EMAIL PROTECTED]>; "CCIE_Lab Groupstudy List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 30, 2000 11:26 AM Subject: Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces > I thought OSPF is suppose to converge whenever you have a change in the > route. I.e whenever any interface bounce.. regardless of the OSPF Router ID. > The difference is probably in terms of the amount of "data" being sent.. but > definitely a covergence would occur.. > > > > - Original Message - > From: "Erick B." <[EMAIL PROTECTED]> > To: "Chuck Larrieu" <[EMAIL PROTECTED]>; "CCIE_Lab Groupstudy List" > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Cc: "Priscilla Oppenheimer" <[EMAIL PROTECTED]> > Sent: Thursday, November 30, 2000 8:04 PM > Subject: Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about > loopback interfaces > > > > Chuck and others, > > > > I've been following this conversation and it is a good > > review. > > > > Without a loopback interface, the OSPF RID (Router ID) > > will be the highest IP address on the router when the > > OSPF process becomes active. If that interface isn't > > stable (say the highest IP is on a WAN circuit) then > > when that interface bounces it will cause OSPF to > > re-converge. > > > > Using a loopback interface, the OSPF RID will be the > > highest IP on a loopback when the OSPF process starts. > > If you have OSPF running already and add loopback > > interfaces OSPF doesn't use the loopback IP address > > for a RID until the OSPF process is restarted, removed > > and added back (copy-paste), or the router is rebooted > > on saved cfg. > > > > So for a stable OSPF environment, using loopbacks > > reduces the chances of un-necessary OSPF > > re-convergance and updates occuring when a interface > > bounces. Example, if you had no loopbacks and had s1 > > and e1 interfaces. s1 having highest IP and was RID > > but s1 wasn't running OSPF - when s1 bounced for > > whatever reason OSPF would re-converge because the > > OSPF RID went down and came back up. > > > > Also, you don't need to advertise the loopback IP > > address into routing protocols unless you want to > > reach that from another device. > > > > I hope this clears things up... it's late so I hope my > > explanation makes sense. :) If not, hit me for the > > mistakes if your ever in Chicago area. > > > > Erick B. - Prepping for attempt 2. > > (Why am I still up at 6am?) > > > > --- Chuck Larrieu <[EMAIL PROTECTED]> 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 behavio
RE: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
Everyone, this has been, and continues to be an excellent thread. My thanks to all of you for participating. I for on have learned a new thing or two. Furthermore, I have enjoyed reading all of the responses. I probably didn't make it clear in my original post that the genesis of this Q&D lab was to demonstrate one way or another the value of configuring a loopback address for a particular reason. Someone stated the belief that having a RID based on a loopback address would prevent the loss of the DR on a segment even though the interface on that segment went down, because the loopback remained up, and the BDR would continue to be aware of the DR, and therefore would not be promoted. I believe that my Q&D amply demonstrated that this supposition was false. That led to my wondering about the value of the loopback in terms of route stability in general. You all have made several excellent points about the purpose of the RID in the OSPF process. Enough so that you have convinced me that in OSPF design in particular it is far better to include a well thought out loopback addressing scheme as f the overall design than it is to just leave things to chance. Thanks again for this wonderful discussion. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tony Olzak Sent: Thursday, November 30, 2000 7:15 PM To: Jason; Erick B.; Chuck Larrieu; CCIE_Lab Groupstudy List; [EMAIL PROTECTED] Subject: Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces Yes, a convergence would occur anyway, but if the Router ID changes, a lot more things could go wrong. For example, virtual links are configured using the Router ID. If the router ID changes (like by having a serial interface your RID), the virtual link goes down. Having loopbacks as your Router IDs also allows for you to more easily manage your OSPF network. All entries in the OSPF database are based on RIDs. If you make all your loopbacks in the same network (i.e. R1 is 10.0.0.1, R2 is 10.0.0.2), it makes it easier to identify the routers. Since the loopback itself does not need to be in OSPF, it doesn't matter that they're all on the same network. Or, you could just use a mask of /32. I'm not saying you'll be able to do this in the lab, just real world tips. Tony - Original Message - From: "Jason" <[EMAIL PROTECTED]> To: "Erick B." <[EMAIL PROTECTED]>; "Chuck Larrieu" <[EMAIL PROTECTED]>; "CCIE_Lab Groupstudy List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 30, 2000 11:26 AM Subject: Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces > I thought OSPF is suppose to converge whenever you have a change in the > route. I.e whenever any interface bounce.. regardless of the OSPF Router ID. > The difference is probably in terms of the amount of "data" being sent.. but > definitely a covergence would occur.. > > > > - Original Message - > From: "Erick B." <[EMAIL PROTECTED]> > To: "Chuck Larrieu" <[EMAIL PROTECTED]>; "CCIE_Lab Groupstudy List" > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Cc: "Priscilla Oppenheimer" <[EMAIL PROTECTED]> > Sent: Thursday, November 30, 2000 8:04 PM > Subject: Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about > loopback interfaces > > > > Chuck and others, > > > > I've been following this conversation and it is a good > > review. > > > > Without a loopback interface, the OSPF RID (Router ID) > > will be the highest IP address on the router when the > > OSPF process becomes active. If that interface isn't > > stable (say the highest IP is on a WAN circuit) then > > when that interface bounces it will cause OSPF to > > re-converge. > > > > Using a loopback interface, the OSPF RID will be the > > highest IP on a loopback when the OSPF process starts. > > If you have OSPF running already and add loopback > > interfaces OSPF doesn't use the loopback IP address > > for a RID until the OSPF process is restarted, removed > > and added back (copy-paste), or the router is rebooted > > on saved cfg. > > > > So for a stable OSPF environment, using loopbacks > > reduces the chances of un-necessary OSPF > > re-convergance and updates occuring when a interface > > bounces. Example, if you had no loopbacks and had s1 > > and e1 interfaces. s1 having highest IP and was RID > > but s1 wasn't running OSPF - when s1 bounced for > > whatever reason OSPF would re-converge because the > > OSPF RID went down and came back up. > > > > Also, you
Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
If you remove the router ospf configuration and paste it back, OSPF will restart with a new router ID if you have a new high IP address. You can only do this in a test/non-production network environment though. I've done this before in my labs because it is faster then waiting for the router to reboot. > And you are right, the RID doesn't change at all > without rebooting the > router. But, what do most techs do when a link is > having problems? Reboot > the routers. Now your RID will change. > > Tony __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
I usually just reboot routers on the fly and work on something else while that router is rebooting. Tony - Original Message - From: "Erick B." <[EMAIL PROTECTED]> To: "Tony Olzak" <[EMAIL PROTECTED]>; "Chuck Larrieu" <[EMAIL PROTECTED]>; "Louie Belt" <[EMAIL PROTECTED]>; "'CCIE_Lab Groupstudy List'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, December 01, 2000 3:35 PM Subject: Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces > If you remove the router ospf configuration and paste > it back, OSPF will restart with a new router ID if you > have a new high IP address. You can only do this in a > test/non-production network environment though. I've > done this before in my labs because it is faster then > waiting for the router to reboot. > > > And you are right, the RID doesn't change at all > > without rebooting the > > router. But, what do most techs do when a link is > > having problems? Reboot > > the routers. Now your RID will change. > > > > Tony > > > __ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ > _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
I have a question regarding OSPF behavior and the loopback address. Our backbone is running OSPF and we have installed a Cache-Flow server to cache webpages. The cache-flow does not support OSPF so I attempted to redistribute OSPF into RIP. I use a private address for the loopback on all of our routers and the advertisement to the cacheflow shows the loopback as the interface the advertisement is coming from. So, say a network of 192.168.5.1 lies of router A's serial port and the loopback of that router is set to 10.0.2.2. The route in the cache-flow is: 192.168.5.1 via 10.0.2.2 even though the ethernet address is a totally different network. Can someone explain why this is happening and what I can do about it? I have static routes configured now, but I would like to make it dynamic if possible. Thanks, -- Anthony Anderson, MCSE, CCNA "Man's life, as required by his nature, is not the life of a mindless brute, of a looting thug or a mooching mystic, but the life of a thinking being -- not life by means of force or fraud, but life by means of achievement."- Ayn Rand ""Erick B."" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Chuck and others, > > I've been following this conversation and it is a good > review. > > Without a loopback interface, the OSPF RID (Router ID) > will be the highest IP address on the router when the > OSPF process becomes active. If that interface isn't > stable (say the highest IP is on a WAN circuit) then > when that interface bounces it will cause OSPF to > re-converge. > > Using a loopback interface, the OSPF RID will be the > highest IP on a loopback when the OSPF process starts. > If you have OSPF running already and add loopback > interfaces OSPF doesn't use the loopback IP address > for a RID until the OSPF process is restarted, removed > and added back (copy-paste), or the router is rebooted > on saved cfg. > > So for a stable OSPF environment, using loopbacks > reduces the chances of un-necessary OSPF > re-convergance and updates occuring when a interface > bounces. Example, if you had no loopbacks and had s1 > and e1 interfaces. s1 having highest IP and was RID > but s1 wasn't running OSPF - when s1 bounced for > whatever reason OSPF would re-converge because the > OSPF RID went down and came back up. > > Also, you don't need to advertise the loopback IP > address into routing protocols unless you want to > reach that from another device. > > I hope this clears things up... it's late so I hope my > explanation makes sense. :) If not, hit me for the > mistakes if your ever in Chicago area. > > Erick B. - Prepping for attempt 2. > (Why am I still up at 6am?) > > --- Chuck Larrieu <[EMAIL PROTECTED]> 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 > >
Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces
Chuck, The virtual link would not reconverge because of how it is configured. It needs to use Area 1 as a transit area and terminate on a specific routed ID. It wouldn't be able to go through other routers in your setup because it would have to either terminate on a different RID (not acceptable) or transit area 0. Best thing would be just to have two virtual links (better yet, no virtual links at all!). And you are right, the RID doesn't change at all without rebooting the router. But, what do most techs do when a link is having problems? Reboot the routers. Now your RID will change. Tony - Original Message - From: "Chuck Larrieu" <[EMAIL PROTECTED]> To: "Louie Belt" <[EMAIL PROTECTED]>; "'CCIE_Lab Groupstudy List'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, December 01, 2000 1:39 AM Subject: RE: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about loopback interfaces > I'm not so sure that this would happen as you describe. > > Assuming the RID is based on a non-OSPF interface address, and assuming that > the OSPF process initialized, and that the OSPF domain reached stability, I > don't believe the flapping of the non-OSPF interface, or even the > disappearance of the non-OSPF interface, would have any effect on the OSPF > side of things. > > I am certain that once the RID is determined, it is permanently installed > into the OSPF process, and it is hell to remove it. I did some experiments > reported recently in another thread in answer to Howard's problem. I and I > am sure I have seen the question elsewhere as well. > Once the RID has been determined by the OSPF process, bringing up another > interface with a higher IP address, or changing the IP address of the > interface that is the basis of the RID, has no effect, until such time as > one reloads the router. > > Reloading is the only way I have found to change the RID. Clear IP OSPF > Process does not do so. Re-addressing each and every interface, and removing > old network statements and installing new network statements does not do so. > > This does bring to question the exact nature of a virtual link. In a > situation where the topology permits, will a virtual link re-establish > itself if it's first path interface fails? > > EG: > > RID1.1.1.1 > RouterA--Area_0---RouterB > | | > | | > RouterC--Area_1--RouterD > | > | > RouterE(Area_2) > RID 2.2.2.2 > > The virtual link on router C is defined as area 1 virtual-link 1.1.1.1 > The virtual link on router A is defined as area 1 virtual-link 2.2.2.2 > > If the link between C and A goes down, will the virtual link remain alive, > because there is a path to router A via routers D and B? > Without trying another Q&D, I am surmising the answer is "no" because the > virtual link termination points must be on an ABR, and RouterA is not an ABR > with respect to RouterD > > Damn, yet another experiment. > > Chuck > > > > > _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
