Re: OSPF DR problem [7:34379]
I don't recall the entire context of this particular discussion, but there is an error in the commentary below that I wanted to correct. Unfortunately, the RFC only addresses virtual links as a means to repair a partitioned backbone. It does not address providing bacbone connectivity to a non-backbone area. Nor does the RFC discuss demand circuits, which, of course, is a Cisco implementation. So there may very well be a gottcha in there that simply isn't addressed in the official OSPF documentation. First, I wondered about this, and asked John Moy, editor and primary author of the OSPF specification. John is generally considered the inventor of virtual links. He told me that his original concept was to provide backbone connectivity to a non-backbone area; the backbone restoral application came later. I can't remember if this was in his first book, OSPF: Anatomy of an Internet Routing Protocol, for which I was a technical reviewer. It may be. He certainly discusses there some of the original ideas that were never implemented widely or at all, because people found a better way (e.g., pervasive iBGP rather than BGP-OSPF interaction and database overflow). Second, the current specification (RFC 2328) contains both virtual links and demand circuits. RFC 1753 does indeed address OSPF demand circuits. They are not a Cisco implimentation A virtual link is a kind of demand circuit, and is described in RFC 1753 as well. Us router jocks sometimes can forget that the folks who designed the standards put a lot of thought into the process. If something wasn't covered, or something came up subsequent to the original standard, it tends to get addressed later. There's some truth to this here, because the original specification for virtual links in OSPF version 1 was buggy. The bugs were fixed in version 2, the current version. Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=40743t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF DR problem [7:34379]
now I'm gonna have to set up a test - seeing if a virtual link will indeed join two non-backbone areas. Funny, the issue has never come up in any of the study materials or various test lab scenarios that I have seen. although to be truthful, if the transit area is the backbone, I'm not sure what kind of havoc this might create. I'll check the thread started by Aussie Jenny a couple of days ago. That might prove to be a good source for the scenario. I'll set something up later this week and report back. Chuck Howard C. Berkowitz wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I don't recall the entire context of this particular discussion, but there is an error in the commentary below that I wanted to correct. Unfortunately, the RFC only addresses virtual links as a means to repair a partitioned backbone. It does not address providing bacbone connectivity to a non-backbone area. Nor does the RFC discuss demand circuits, which, of course, is a Cisco implementation. So there may very well be a gottcha in there that simply isn't addressed in the official OSPF documentation. First, I wondered about this, and asked John Moy, editor and primary author of the OSPF specification. John is generally considered the inventor of virtual links. He told me that his original concept was to provide backbone connectivity to a non-backbone area; the backbone restoral application came later. I can't remember if this was in his first book, OSPF: Anatomy of an Internet Routing Protocol, for which I was a technical reviewer. It may be. He certainly discusses there some of the original ideas that were never implemented widely or at all, because people found a better way (e.g., pervasive iBGP rather than BGP-OSPF interaction and database overflow). Second, the current specification (RFC 2328) contains both virtual links and demand circuits. RFC 1753 does indeed address OSPF demand circuits. They are not a Cisco implimentation A virtual link is a kind of demand circuit, and is described in RFC 1753 as well. Us router jocks sometimes can forget that the folks who designed the standards put a lot of thought into the process. If something wasn't covered, or something came up subsequent to the original standard, it tends to get addressed later. There's some truth to this here, because the original specification for virtual links in OSPF version 1 was buggy. The bugs were fixed in version 2, the current version. Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=40748t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF DR problem [7:34379]
I don't recall the entire context of this particular discussion, but there is an error in the commentary below that I wanted to correct. Unfortunately, the RFC only addresses virtual links as a means to repair a partitioned backbone. It does not address providing bacbone connectivity to a non-backbone area. Nor does the RFC discuss demand circuits, which, of course, is a Cisco implementation. So there may very well be a gottcha in there that simply isn't addressed in the official OSPF documentation. RFC 1753 does indeed address OSPF demand circuits. They are not a Cisco implimentation A virtual link is a kind of demand circuit, and is described in RFC 1753 as well. Us router jocks sometimes can forget that the folks who designed the standards put a lot of thought into the process. If something wasn't covered, or something came up subsequent to the original standard, it tends to get addressed later. Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=40720t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF DR problem [7:34379]
Hello intervals are link specific. I'm not sure why varying hello timers on different links would be relevant. At 06:23 PM 2/4/2002 -0500, Walter Rogowski wrote: If you debug ospf adjacencies you might see complaints re mismatched hello intervals. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Baker, Jason Sent: 04 February 2002 22:51 To: [EMAIL PROTECTED] Subject: RE: OSPF DR problem [7:34379] hmmm in ospf NBMA network i thought when you specified point to point there was no DR, BDR election. so maybe playing with the priorities may have caused problems -Original Message- From: Kane, Christopher A. [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, 5 February 2002 9:36 am To: [EMAIL PROTECTED] Subject: RE: OSPF DR problem [7:34379] Priscilla, Now that you have R1 as the DR, it's his responsibility to announce that network out to everyone else. Is R1 sending out LSAs (Network LSA, type 2) to wherever it is that you are trying to see that network? (Is it R3's routing table that you can't see the Ethernet segment of R1 and R2?) Does the network show up in the OSPF database but not the routing table? Or just the routing table? Chris -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 4:31 PM To: [EMAIL PROTECTED] Subject: OSPF DR problem [7:34379] Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34458t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF DR problem [7:34379]
This is why I didn't make too big of a deal about the two instances of area one. I know a discontiguous area 0 is bad, but I seemed to recall that it doesn't matter if there are multiple instances of other areas. I wasn't sure of that, though, it was just in the back of my mind. It will be interesting to see how this turns out. John Chuck Larrieu 2/5/02 12:07:24 AM Two comments: 1) so long as there is an area 0, and all other areas connect to it, those other areas can all be area 1 ( or any other arbitrary number ) and there will be no reachability problems. This assumes no overlapping subnets. Other than making summarization a bear, there is nothing wrong with doing it this way. Bad practice and bad design, but not bad behaviour. 2) I'm interested in your rationale as to why a discontiguous area 1 would in and of itself cause a problem with routers in either of the discontiguous areas such that they cannot see area 0 routes. I can't think of one myself, which may or may not mean anything. Chuck Dusty Harper wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Maybe Discontiguous is the wrong word for it.The problem I see with this design is that there is basically 2 Area 1s. The point -to- point connections would be fine, however in order for the Areas to function properly they need to know of each other ( all of Area 1 as a whole needs to know of the other) This is done via LSA Types 1 and 2. I know the reasoning for the Area 2, however I still stand behind the notion that if you were to change the Frame-Relay Area to 3 your problem would be solved You might also get around this by changing from point to point to a non-broadcast environment and specify all of your neighbors Router IDs' : R1 (S0) R2(BRI0) R9(S0) and R8(BRI0) on each of the routers. -Original Message- From: Chuck Larrieu [mailto:[EMAIL PROTECTED]] Sent: Mon 2/4/2002 8:33 PM To: [EMAIL PROTECTED] Cc: Subject: Re: OSPF DR problem [7:34379] Cil, I drew this one out a little differently just to put a fresh perspective on it. Without seeing the requirements of the particular practice lab you are using, it's hard to say why you were seeing or not seeing what you did. area 0 -- || R1R2 || frame relay area 1 ISDN area 1 || R9R8 || -- - area 2 The discontiguous area 1's are irrelevant unless there is overlapping addressing. The area 2 is placed the way it is in order to force the creation of a virtual link - common in practice labs and study materials, as all us CCIE candidates know full well ;- I am inferring from other comments in other posts that you needed to use the IP ospf priority command on the R2 ethernet because the requirement is that R1 is the DR in area 0. So, given what I see ( not knowing the particulars of your addressing and various other things, there is no good reason why R9 and R8 should not see the ethernet network that is area 0. Along the trail of broken things, I have sometimes run across bizarre issues which are solved only by reloading routers. My humble pod of 2501's running enterprise 12.1.11 code sometimes have bizarre problems. I have a theory that these bloatware images just barely operate within the confined spaces of 16 megs of DRAM and sometimes you have to clear it out. I have had bizarre things happen when configuring and unconfiguring various routing protocols and features. Sometimes, admittedly, mistakes happen when you are tired, and you can't see straight to correct errors you have made. But other times, reloads have made magic happen. I am at the point where I am thinking about backloading to an IOS build that takes less space, just to see if the occasional weirdness disappears. Again, based upon what I have seen throughout this thread, and given that your areas and other configurations are correct, I see no reason why the area 0 network should not be visible from R9 and R8. Chuck PS as has been discussed here and elsewhere many a time, good practice and good design have little in common with the CCIE Lab ;- PPS which practice lab are you looking at? I have NLI, IPExpert, and SolutionLabs at my disposal. Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Remember, I think from a design point of view. I say for some reason there's an Area 2 because I think it's a bad design not because I was surprised to see it there in the show output. ;-) But thanks for replying, because it made me question
Re: OSPF DR problem [7:34379]
Priscilla Oppenheimer wrote: Remember, I think from a design point of view. I say for some reason there's an Area 2 because I think it's a bad design not because I was surprised to see it there in the show output. ;-) Well that certainly makes sense. I thought you were surprised by the area because you were using a remote practice lab and weren't certain of the state of the entire network. Nevermind. But thanks for replying, because it made me question my expectations. Here's what part of the network design looks like: ---R2---Area-1-ISDNR8---Area-1-Ethernet | Area 0 | Ethernet | | ---R1---Area-1-Frame Relay---R9---Area-2-Ethernet There was some back and forth about whether or not the partitioned area 1 was a problem. I think Moy says it best (RFC 2178, pgs 33 34)... (to save myself some typing, the discussion is centered on areas as being different colors, all meeting up with the edge of the backbone) ...When the AS topology changes, one of the areas may become partitioned. The graph of the AS will then have multiple regions of the same color (area ID). The routing in the Autonomous System will continue to function as long as these regions of the same color are connected by the single backbone region. When I did a show ip route on R9 and R8 I thought I would see the Ethernet LAN in Area 0. That was not a logical expectation? I should just see a default route on ABRs? Unless configured as stub areas (which would preclude using them as transit areas), I would think you should see the topology of the backbone. Unfortunately, the RFC only addresses virtual links as a means to repair a partitioned backbone. It does not address providing bacbone connectivity to a non-backbone area. Nor does the RFC discuss demand circuits, which, of course, is a Cisco implementation. So there may very well be a gottcha in there that simply isn't addressed in the official OSPF documentation. I guess the answer will most likely be revealed when you revisit the remote lab and do some magic with debug and show. Regards, Scott Thanks. Priscilla Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34475t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF DR problem [7:34379]
I'm not going to argue with Chuck whether it's valid or not valid to split areas (because yes Chuck is correct, it is valid). From a network design perspective, it's bad enough for the use of a Virtual Link, but splitting the Areas is totally unnecessary. A colleague of mine has the term Network Masturbation for designs like these. Basically by breaking the KISS principle (Keep It Simple Stupid) you are just begging for trouble. Just by taking a look at the network layout as it is, my suggestion was to change the Frame Relay Area 1 to a different Area (Area 3). This still allowed for the test of the Virtual Link, and constituted a better designed network. What you didn't see were my direct responses to Priscilla referring to examining the different topological databases to see exactly where these links were and whether the next logical phase of an LSA was being performed. (LSA Types 1 and 2 shows the link in Area 0, are LSA type 3's getting sent into Area 1 and 2 with the information...) -Original Message- From: s vermill [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 05, 2002 8:40 AM To: [EMAIL PROTECTED] Subject: Re: OSPF DR problem [7:34379] Priscilla Oppenheimer wrote: Remember, I think from a design point of view. I say for some reason there's an Area 2 because I think it's a bad design not because I was surprised to see it there in the show output. ;-) Well that certainly makes sense. I thought you were surprised by the area because you were using a remote practice lab and weren't certain of the state of the entire network. Nevermind. But thanks for replying, because it made me question my expectations. Here's what part of the network design looks like: ---R2---Area-1-ISDNR8---Area-1-Ethernet | Area 0 | Ethernet | | ---R1---Area-1-Frame Relay---R9---Area-2-Ethernet There was some back and forth about whether or not the partitioned area 1 was a problem. I think Moy says it best (RFC 2178, pgs 33 34)... (to save myself some typing, the discussion is centered on areas as being different colors, all meeting up with the edge of the backbone) ...When the AS topology changes, one of the areas may become partitioned. The graph of the AS will then have multiple regions of the same color (area ID). The routing in the Autonomous System will continue to function as long as these regions of the same color are connected by the single backbone region. When I did a show ip route on R9 and R8 I thought I would see the Ethernet LAN in Area 0. That was not a logical expectation? I should just see a default route on ABRs? Unless configured as stub areas (which would preclude using them as transit areas), I would think you should see the topology of the backbone. Unfortunately, the RFC only addresses virtual links as a means to repair a partitioned backbone. It does not address providing bacbone connectivity to a non-backbone area. Nor does the RFC discuss demand circuits, which, of course, is a Cisco implementation. So there may very well be a gottcha in there that simply isn't addressed in the official OSPF documentation. I guess the answer will most likely be revealed when you revisit the remote lab and do some magic with debug and show. Regards, Scott Thanks. Priscilla Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34557t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
OSPF DR problem [7:34379]
Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34379t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF DR problem [7:34379]
Priscilla, I can't think of anything that could have been broken by using the ip ospf priority command. Unless you've run into some sort of bug I'm guessing that there must be another issue. Were you playing around with the loopback addresses? Do you have any virtual links configured? I'm just wondering if you configured something that depended on a static router ID and by adding or changing a loopback you've confused one or two of the other routers. You mentioned that the frame relay interface is configured as point-to-point. Is the opposite side configured the same way? It must be since you said the adjacencies are forming...nevermind. Hmm... Are the missing routes in the OSPF database, just not in the routing table? If so, check out this link: http://www.cisco.com/warp/public/104/26.html I can't think of any one thing that describes this issue but I'll keep pondering... John Priscilla Oppenheimer 2/4/02 2:30:35 PM Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34389t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF DR problem [7:34379]
Have you checked your hello and dead time intervals (sho ip ospf interfaces) to make sure they match on your participating routers??Priscilla Oppenheimer wrote: Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34391t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF DR problem [7:34379]
There was a virtual link. The virtual link was from R1 over to another router across the Frame Relay cloud. R1 is an ABR connecting Area 0 and Area 1. Area 0 is the Ethernet LAN. Area 1 is the Frame Relay cloud. For some unknown reason, there's an Area 2 also on the other side of Area 1. Does that ring a bell regarding any gotchas?? Thanks Priscilla At 03:03 PM 2/4/02, John Neiberger wrote: Priscilla, I can't think of anything that could have been broken by using the ip ospf priority command. Unless you've run into some sort of bug I'm guessing that there must be another issue. Were you playing around with the loopback addresses? Do you have any virtual links configured? I'm just wondering if you configured something that depended on a static router ID and by adding or changing a loopback you've confused one or two of the other routers. You mentioned that the frame relay interface is configured as point-to-point. Is the opposite side configured the same way? It must be since you said the adjacencies are forming...nevermind. Hmm... Are the missing routes in the OSPF database, just not in the routing table? If so, check out this link: http://www.cisco.com/warp/public/104/26.html I can't think of any one thing that describes this issue but I'll keep pondering... John Priscilla Oppenheimer 2/4/02 2:30:35 PM Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34393t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF DR problem [7:34379]
Priscilla, Now that you have R1 as the DR, it's his responsibility to announce that network out to everyone else. Is R1 sending out LSAs (Network LSA, type 2) to wherever it is that you are trying to see that network? (Is it R3's routing table that you can't see the Ethernet segment of R1 and R2?) Does the network show up in the OSPF database but not the routing table? Or just the routing table? Chris -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 4:31 PM To: [EMAIL PROTECTED] Subject: OSPF DR problem [7:34379] Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34395t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF DR problem [7:34379]
Compare the OSPF hello interval on the FR interfaces with that on the Ethernet interfaces... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Neiberger Sent: 04 February 2002 22:03 To: [EMAIL PROTECTED] Subject: Re: OSPF DR problem [7:34379] Priscilla, I can't think of anything that could have been broken by using the ip ospf priority command. Unless you've run into some sort of bug I'm guessing that there must be another issue. Were you playing around with the loopback addresses? Do you have any virtual links configured? I'm just wondering if you configured something that depended on a static router ID and by adding or changing a loopback you've confused one or two of the other routers. You mentioned that the frame relay interface is configured as point-to-point. Is the opposite side configured the same way? It must be since you said the adjacencies are forming...nevermind. Hmm... Are the missing routes in the OSPF database, just not in the routing table? If so, check out this link: http://www.cisco.com/warp/public/104/26.html I can't think of any one thing that describes this issue but I'll keep pondering... John Priscilla Oppenheimer 2/4/02 2:30:35 PM Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34394t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF DR problem [7:34379]
hmmm in ospf NBMA network i thought when you specified point to point there was no DR, BDR election. so maybe playing with the priorities may have caused problems -Original Message- From: Kane, Christopher A. [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, 5 February 2002 9:36 am To: [EMAIL PROTECTED] Subject: RE: OSPF DR problem [7:34379] Priscilla, Now that you have R1 as the DR, it's his responsibility to announce that network out to everyone else. Is R1 sending out LSAs (Network LSA, type 2) to wherever it is that you are trying to see that network? (Is it R3's routing table that you can't see the Ethernet segment of R1 and R2?) Does the network show up in the OSPF database but not the routing table? Or just the routing table? Chris -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 4:31 PM To: [EMAIL PROTECTED] Subject: OSPF DR problem [7:34379] Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34396t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF DR problem [7:34379]
Definitely! The biggest gotcha is if the router ID changed on either router that has virtual links configured. The configs will have to be changed to reflect the new router IDs or the virtual link won't work. If it's a virtual link problem, though, at the console (or by using term mon) or R1 you should see some virtual-link-related errors every few seconds. You can also use show ip ospf virt to help troubleshoot that particular issue. That's my official guess. Somewhere the VL is broken and it's probably due to a change in router ID. Let me know if that's not the problem and I'll put the thinking cap back on! John Priscilla Oppenheimer 2/4/02 3:30:18 PM There was a virtual link. The virtual link was from R1 over to another router across the Frame Relay cloud. R1 is an ABR connecting Area 0 and Area 1. Area 0 is the Ethernet LAN. Area 1 is the Frame Relay cloud. For some unknown reason, there's an Area 2 also on the other side of Area 1. Does that ring a bell regarding any gotchas?? Thanks Priscilla At 03:03 PM 2/4/02, John Neiberger wrote: Priscilla, I can't think of anything that could have been broken by using the ip ospf priority command. Unless you've run into some sort of bug I'm guessing that there must be another issue. Were you playing around with the loopback addresses? Do you have any virtual links configured? I'm just wondering if you configured something that depended on a static router ID and by adding or changing a loopback you've confused one or two of the other routers. You mentioned that the frame relay interface is configured as point-to-point. Is the opposite side configured the same way? It must be since you said the adjacencies are forming...nevermind. Hmm... Are the missing routes in the OSPF database, just not in the routing table? If so, check out this link: http://www.cisco.com/warp/public/104/26.html I can't think of any one thing that describes this issue but I'll keep pondering... John Priscilla Oppenheimer 2/4/02 2:30:35 PM Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34398t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF DR problem [7:34379]
At 05:33 PM 2/4/02, Walter Rogowski wrote: Compare the OSPF hello interval on the FR interfaces with that on the Ethernet interfaces... I think they were different but that's normal, isn't it? The Hello timer for Ethernet is 10 seconds. For non-broadcast networks it's 30 seconds. The Frame Relay cloud was configured as point-to-point links. The Ethernet routers formed an adjacency. The FR routers formed adjacencies. The Ethernet routers simply failed to tell the FR side about the Ethernet LAN!! This was a remote lab that I only used for a few hours and now I'm not on it anymore. I will get back in soon and do some more research. Thanks for everyone's suggestions. Priscilla -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Neiberger Sent: 04 February 2002 22:03 To: [EMAIL PROTECTED] Subject: Re: OSPF DR problem [7:34379] Priscilla, I can't think of anything that could have been broken by using the ip ospf priority command. Unless you've run into some sort of bug I'm guessing that there must be another issue. Were you playing around with the loopback addresses? Do you have any virtual links configured? I'm just wondering if you configured something that depended on a static router ID and by adding or changing a loopback you've confused one or two of the other routers. You mentioned that the frame relay interface is configured as point-to-point. Is the opposite side configured the same way? It must be since you said the adjacencies are forming...nevermind. Hmm... Are the missing routes in the OSPF database, just not in the routing table? If so, check out this link: http://www.cisco.com/warp/public/104/26.html I can't think of any one thing that describes this issue but I'll keep pondering... John Priscilla Oppenheimer 2/4/02 2:30:35 PM Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34399t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF DR problem [7:34379]
If you debug ospf adjacencies you might see complaints re mismatched hello intervals. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Baker, Jason Sent: 04 February 2002 22:51 To: [EMAIL PROTECTED] Subject: RE: OSPF DR problem [7:34379] hmmm in ospf NBMA network i thought when you specified point to point there was no DR, BDR election. so maybe playing with the priorities may have caused problems -Original Message- From: Kane, Christopher A. [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, 5 February 2002 9:36 am To: [EMAIL PROTECTED] Subject: RE: OSPF DR problem [7:34379] Priscilla, Now that you have R1 as the DR, it's his responsibility to announce that network out to everyone else. Is R1 sending out LSAs (Network LSA, type 2) to wherever it is that you are trying to see that network? (Is it R3's routing table that you can't see the Ethernet segment of R1 and R2?) Does the network show up in the OSPF database but not the routing table? Or just the routing table? Chris -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 4:31 PM To: [EMAIL PROTECTED] Subject: OSPF DR problem [7:34379] Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34400t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF DR problem [7:34379]
Priscilla, On my lab a while ago I had the same problem. Once I had matching OSPF timers, the FR and the Ethernet routers managed to form adjacencies. Not too sure why, but it worked. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Priscilla Oppenheimer Sent: 04 February 2002 23:12 To: [EMAIL PROTECTED] Subject: RE: OSPF DR problem [7:34379] At 05:33 PM 2/4/02, Walter Rogowski wrote: Compare the OSPF hello interval on the FR interfaces with that on the Ethernet interfaces... I think they were different but that's normal, isn't it? The Hello timer for Ethernet is 10 seconds. For non-broadcast networks it's 30 seconds. The Frame Relay cloud was configured as point-to-point links. The Ethernet routers formed an adjacency. The FR routers formed adjacencies. The Ethernet routers simply failed to tell the FR side about the Ethernet LAN!! This was a remote lab that I only used for a few hours and now I'm not on it anymore. I will get back in soon and do some more research. Thanks for everyone's suggestions. Priscilla -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Neiberger Sent: 04 February 2002 22:03 To: [EMAIL PROTECTED] Subject: Re: OSPF DR problem [7:34379] Priscilla, I can't think of anything that could have been broken by using the ip ospf priority command. Unless you've run into some sort of bug I'm guessing that there must be another issue. Were you playing around with the loopback addresses? Do you have any virtual links configured? I'm just wondering if you configured something that depended on a static router ID and by adding or changing a loopback you've confused one or two of the other routers. You mentioned that the frame relay interface is configured as point-to-point. Is the opposite side configured the same way? It must be since you said the adjacencies are forming...nevermind. Hmm... Are the missing routes in the OSPF database, just not in the routing table? If so, check out this link: http://www.cisco.com/warp/public/104/26.html I can't think of any one thing that describes this issue but I'll keep pondering... John Priscilla Oppenheimer 2/4/02 2:30:35 PM Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34403t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF DR problem [7:34379]
The hello intervals on any given link must match, but the intervals on the ethernet side have nothing to do with the intervals on the FR side. Also, if the network type point-to-point is used, no DR election occurs but the timers must still match or an adjacency will not form. In Priscilla's scenario, she said that adjacencies were forming but the routes were not showing up in the routing table. This doesn't sound like a timer issue. Since she mentioned that there were virtual links involved, I'm guessing that something happened that broke them and that issue needs to be resolved. If the router in area 2--on the other side of the VL--does not have anything in its OSPF database then this is most likely a VL problem. If that is resolved and the routes are still not in the table, then we need to see if the LSAs have at least made it into the database. That should lead us to the source of the problem. John Walter Rogowski 2/4/02 4:23:40 PM If you debug ospf adjacencies you might see complaints re mismatched hello intervals. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Baker, Jason Sent: 04 February 2002 22:51 To: [EMAIL PROTECTED] Subject: RE: OSPF DR problem [7:34379] hmmm in ospf NBMA network i thought when you specified point to point there was no DR, BDR election. so maybe playing with the priorities may have caused problems -Original Message- From: Kane, Christopher A. [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, 5 February 2002 9:36 am To: [EMAIL PROTECTED] Subject: RE: OSPF DR problem [7:34379] Priscilla, Now that you have R1 as the DR, it's his responsibility to announce that network out to everyone else. Is R1 sending out LSAs (Network LSA, type 2) to wherever it is that you are trying to see that network? (Is it R3's routing table that you can't see the Ethernet segment of R1 and R2?) Does the network show up in the OSPF database but not the routing table? Or just the routing table? Chris -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 4:31 PM To: [EMAIL PROTECTED] Subject: OSPF DR problem [7:34379] Hi Group Study, Playing with IP OSPF priority to influence which router became the Designated Router (DR) caused routing problems for me in a recent bout with a lab exercise. Can anyone help me understand if I did something wrong? I have 2 routers on an Ethernet LAN. Both of them also have WAN connections to remote sites. R1 has a Frame Relay link to the corporate cloud via its S0 port. S0 is configured as ip ospf network point-to-point. R2 has an ISDN link to yet another router, R3. This link is configured as an OSPF point-to-point demand circuit. R1 and R2 are connected via an Ethernet switch. My goal was to make sure R1 became the DR on Ethernet. Both routers have loopbacks, but R2's is higher, so to make sure R2 did not become the DR, I configured it with: ip ospf priority 0 R1 then did indeed become the DR on the Ethernet LAN because it was using the default priority 1. Now, finally to the question.. On the other side of the ISDN and across the Frame Relay cloud, I couldn't see the Ethernet LAN in the routing table. Routers formed adjacencies correctly and could reach most networks, but not that darn Ethernet LAN. R1 and R2 on the Ethernet LAN formed an adjacency and could see the rest of the internetwork. Could I have broken something by playing with the priority?? Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34404t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF DR problem [7:34379]
Priscilla Oppenheimer wrote: There was a virtual link. The virtual link was from R1 over to another router across the Frame Relay cloud. R1 is an ABR connecting Area 0 and Area 1. Area 0 is the Ethernet LAN. Area 1 is the Frame Relay cloud. For some unknown reason, there's an Area 2 also on the other side of Area 1. Does that ring a bell regarding any gotchas? Priscilla, There must be at least three areas involved in a virtual link. So I am intrigued by the phantom area 2. What area were you expecting to see on the other side of area 1? In your case, it seems as if the ABRs are directly connected. That is to say, the transit area is in essence a p-t-p connection. That isn't always necessarily the case so I don't think OSPF makes any kind of distinction. As I understand it, the virtual connection/tunnel is treated like an unnumbered one. So the network statements have to be in place for the transit area in both routers, area 0 in the backbone ABR, and the discontiguous area in the discontiguous ABR. So that is the basis for my interest in your phantom area 2. Of course, this doesn't seem to be in any way related to why you wouldn't be able to see the area 0 network across the ISDN connection. The interesting parallel is that virtual links and demand circuits are both treated the same. That is, the DNA bit is set for routes learned via either one. So is there anything in your setup not consistent with having DNA show up in the topo table? I can't imagine what but I have never tried anything like your setup. Tough one! Scott Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34410t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF DR problem [7:34379]
Remember, I think from a design point of view. I say for some reason there's an Area 2 because I think it's a bad design not because I was surprised to see it there in the show output. ;-) But thanks for replying, because it made me question my expectations. Here's what part of the network design looks like: ---R2---Area-1-ISDNR8---Area-1-Ethernet | Area 0 | Ethernet | | ---R1---Area-1-Frame Relay---R9---Area-2-Ethernet When I did a show ip route on R9 and R8 I thought I would see the Ethernet LAN in Area 0. That was not a logical expectation? I should just see a default route on ABRs? Thanks. Priscilla At 07:09 PM 2/4/02, s vermill wrote: Priscilla Oppenheimer wrote: There was a virtual link. The virtual link was from R1 over to another router across the Frame Relay cloud. R1 is an ABR connecting Area 0 and Area 1. Area 0 is the Ethernet LAN. Area 1 is the Frame Relay cloud. For some unknown reason, there's an Area 2 also on the other side of Area 1. Does that ring a bell regarding any gotchas? Priscilla, There must be at least three areas involved in a virtual link. So I am intrigued by the phantom area 2. What area were you expecting to see on the other side of area 1? In your case, it seems as if the ABRs are directly connected. That is to say, the transit area is in essence a p-t-p connection. That isn't always necessarily the case so I don't think OSPF makes any kind of distinction. As I understand it, the virtual connection/tunnel is treated like an unnumbered one. So the network statements have to be in place for the transit area in both routers, area 0 in the backbone ABR, and the discontiguous area in the discontiguous ABR. So that is the basis for my interest in your phantom area 2. Of course, this doesn't seem to be in any way related to why you wouldn't be able to see the area 0 network across the ISDN connection. The interesting parallel is that virtual links and demand circuits are both treated the same. That is, the DNA bit is set for routes learned via either one. So is there anything in your setup not consistent with having DNA show up in the topo table? I can't imagine what but I have never tried anything like your setup. Tough one! Scott Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34421t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF DR problem [7:34379]
That network design is horrendous. The only way you'd see a default route is if 1) you were advertising one, or 2) you set up stub networks. I think the problem is the Area Configuration. Area 1 is discontiguous. I bet if you change the Frame Relay Area number to 2, you'll have no problem -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 6:06 PM To: [EMAIL PROTECTED] Subject: Re: OSPF DR problem [7:34379] Remember, I think from a design point of view. I say for some reason there's an Area 2 because I think it's a bad design not because I was surprised to see it there in the show output. ;-) But thanks for replying, because it made me question my expectations. Here's what part of the network design looks like: ---R2---Area-1-ISDNR8---Area-1-Ethernet | Area 0 | Ethernet | | ---R1---Area-1-Frame Relay---R9---Area-2-Ethernet When I did a show ip route on R9 and R8 I thought I would see the Ethernet LAN in Area 0. That was not a logical expectation? I should just see a default route on ABRs? Thanks. Priscilla At 07:09 PM 2/4/02, s vermill wrote: Priscilla Oppenheimer wrote: There was a virtual link. The virtual link was from R1 over to another router across the Frame Relay cloud. R1 is an ABR connecting Area 0 and Area 1. Area 0 is the Ethernet LAN. Area 1 is the Frame Relay cloud. For some unknown reason, there's an Area 2 also on the other side of Area 1. Does that ring a bell regarding any gotchas? Priscilla, There must be at least three areas involved in a virtual link. So I am intrigued by the phantom area 2. What area were you expecting to see on the other side of area 1? In your case, it seems as if the ABRs are directly connected. That is to say, the transit area is in essence a p-t-p connection. That isn't always necessarily the case so I don't think OSPF makes any kind of distinction. As I understand it, the virtual connection/tunnel is treated like an unnumbered one. So the network statements have to be in place for the transit area in both routers, area 0 in the backbone ABR, and the discontiguous area in the discontiguous ABR. So that is the basis for my interest in your phantom area 2. Of course, this doesn't seem to be in any way related to why you wouldn't be able to see the area 0 network across the ISDN connection. The interesting parallel is that virtual links and demand circuits are both treated the same. That is, the DNA bit is set for routes learned via either one. So is there anything in your setup not consistent with having DNA show up in the topo table? I can't imagine what but I have never tried anything like your setup. Tough one! Scott Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=34425t=34379 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF DR problem [7:34379]
Cil, I drew this one out a little differently just to put a fresh perspective on it. Without seeing the requirements of the particular practice lab you are using, it's hard to say why you were seeing or not seeing what you did. area 0 -- || R1R2 || frame relay area 1 ISDN area 1 || R9R8 || -- - area 2 The discontiguous area 1's are irrelevant unless there is overlapping addressing. The area 2 is placed the way it is in order to force the creation of a virtual link - common in practice labs and study materials, as all us CCIE candidates know full well ;- I am inferring from other comments in other posts that you needed to use the IP ospf priority command on the R2 ethernet because the requirement is that R1 is the DR in area 0. So, given what I see ( not knowing the particulars of your addressing and various other things, there is no good reason why R9 and R8 should not see the ethernet network that is area 0. Along the trail of broken things, I have sometimes run across bizarre issues which are solved only by reloading routers. My humble pod of 2501's running enterprise 12.1.11 code sometimes have bizarre problems. I have a theory that these bloatware images just barely operate within the confined spaces of 16 megs of DRAM and sometimes you have to clear it out. I have had bizarre things happen when configuring and unconfiguring various routing protocols and features. Sometimes, admittedly, mistakes happen when you are tired, and you can't see straight to correct errors you have made. But other times, reloads have made magic happen. I am at the point where I am thinking about backloading to an IOS build that takes less space, just to see if the occasional weirdness disappears. Again, based upon what I have seen throughout this thread, and given that your areas and other configurations are correct, I see no reason why the area 0 network should not be visible from R9 and R8. Chuck PS as has been discussed here and elsewhere many a time, good practice and good design have little in common with the CCIE Lab ;- PPS which practice lab are you looking at? I have NLI, IPExpert, and SolutionLabs at my disposal. Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Remember, I think from a design point of view. I say for some reason there's an Area 2 because I think it's a bad design not because I was surprised to see it there in the show output. ;-) But thanks for replying, because it made me question my expectations. Here's what part of the network design looks like: ---R2---Area-1-ISDNR8---Area-1-Ethernet | Area 0 | Ethernet | | ---R1---Area-1-Frame Relay---R9---Area-2-Ethernet When I did a show ip route on R9 and R8 I thought I would see the Ethernet LAN in Area 0. That was not a logical expectation? I should just see a default route on ABRs? Thanks. Priscilla At 07:09 PM 2/4/02, s vermill wrote: Priscilla Oppenheimer wrote: There was a virtual link. The virtual link was from R1 over to another router across the Frame Relay cloud. R1 is an ABR connecting Area 0 and Area 1. Area 0 is the Ethernet LAN. Area 1 is the Frame Relay cloud. For some unknown reason, there's an Area 2 also on the other side of Area 1. Does that ring a bell regarding any gotchas? Priscilla, There must be at least three areas involved in a virtual link. So I am intrigued by the phantom area 2. What area were you expecting to see on the other side of area 1? In your case, it seems as if the ABRs are directly connected. That is to say, the transit area is in essence a p-t-p connection. That isn't always necessarily the case so I don't think OSPF makes any kind of distinction. As I understand it, the virtual connection/tunnel is treated like an unnumbered one. So the network statements have to be in place for the transit area in both routers, area 0 in the backbone ABR, and the discontiguous area in the discontiguous ABR. So that is the basis for my interest in your phantom area 2. Of course, this doesn't seem to be in any way related to why you wouldn't be able to see the area 0 network across the ISDN connection. The interesting parallel is that virtual links and demand circuits are both treated the same. That is, the DNA bit is set for routes learned via either one. So is there anything in your setup not consistent with having DNA show up in the topo table? I can't imagine what but I have never tried anything like your
RE: OSPF DR problem [7:34379]
Maybe Discontiguous is the wrong word for it.The problem I see with this design is that there is basically 2 Area 1s. The point -to- point connections would be fine, however in order for the Areas to function properly they need to know of each other ( all of Area 1 as a whole needs to know of the other) This is done via LSA Types 1 and 2. I know the reasoning for the Area 2, however I still stand behind the notion that if you were to change the Frame-Relay Area to 3 your problem would be solved You might also get around this by changing from point to point to a non-broadcast environment and specify all of your neighbors Router IDs' : R1 (S0) R2(BRI0) R9(S0) and R8(BRI0) on each of the routers. -Original Message- From: Chuck Larrieu [mailto:[EMAIL PROTECTED]] Sent: Mon 2/4/2002 8:33 PM To: [EMAIL PROTECTED] Cc: Subject: Re: OSPF DR problem [7:34379] Cil, I drew this one out a little differently just to put a fresh perspective on it. Without seeing the requirements of the particular practice lab you are using, it's hard to say why you were seeing or not seeing what you did. area 0 -- || R1R2 || frame relay area 1 ISDN area 1 || R9R8 || -- - area 2 The discontiguous area 1's are irrelevant unless there is overlapping addressing. The area 2 is placed the way it is in order to force the creation of a virtual link - common in practice labs and study materials, as all us CCIE candidates know full well ;- I am inferring from other comments in other posts that you needed to use the IP ospf priority command on the R2 ethernet because the requirement is that R1 is the DR in area 0. So, given what I see ( not knowing the particulars of your addressing and various other things, there is no good reason why R9 and R8 should not see the ethernet network that is area 0. Along the trail of broken things, I have sometimes run across bizarre issues which are solved only by reloading routers. My humble pod of 2501's running enterprise 12.1.11 code sometimes have bizarre problems. I have a theory that these bloatware images just barely operate within the confined spaces of 16 megs of DRAM and sometimes you have to clear it out. I have had bizarre things happen when configuring and unconfiguring various routing protocols and features. Sometimes, admittedly, mistakes happen when you are tired, and you can't see straight to correct errors you have made. But other times, reloads have made magic happen. I am at the point where I am thinking about backloading to an IOS build that takes less space, just to see if the occasional weirdness disappears. Again, based upon what I have seen throughout this thread, and given that your areas and other configurations are correct, I see no reason why the area 0 network should not be visible from R9 and R8. Chuck PS as has been discussed here and elsewhere many a time, good practice and good design have little in common with the CCIE Lab ;- PPS which practice lab are you looking at? I have NLI, IPExpert, and SolutionLabs at my disposal. Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Remember, I think from a design point of view. I say for some reason there's an Area 2 because I think it's a bad design not because I was surprised to see it there in the show output. ;-) But thanks for replying, because it made me question my expectations. Here's what part of the network design looks like: ---R2---Area-1-ISDNR8---Area-1-Ethernet | Area 0 | Ethernet | | ---R1---Area-1-Frame Relay---R9---Area-2-Ethernet When I did a show ip route on R9 and R8 I thought I would see the Ethernet LAN in Area 0. That was not a logical expectation? I should just see a default route on ABRs? Thanks. Priscilla At 07:09 PM 2/4/02, s vermill wrote: P
Re: OSPF DR problem [7:34379]
Two comments: 1) so long as there is an area 0, and all other areas connect to it, those other areas can all be area 1 ( or any other arbitrary number ) and there will be no reachability problems. This assumes no overlapping subnets. Other than making summarization a bear, there is nothing wrong with doing it this way. Bad practice and bad design, but not bad behaviour. 2) I'm interested in your rationale as to why a discontiguous area 1 would in and of itself cause a problem with routers in either of the discontiguous areas such that they cannot see area 0 routes. I can't think of one myself, which may or may not mean anything. Chuck Dusty Harper wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Maybe Discontiguous is the wrong word for it.The problem I see with this design is that there is basically 2 Area 1s. The point -to- point connections would be fine, however in order for the Areas to function properly they need to know of each other ( all of Area 1 as a whole needs to know of the other) This is done via LSA Types 1 and 2. I know the reasoning for the Area 2, however I still stand behind the notion that if you were to change the Frame-Relay Area to 3 your problem would be solved You might also get around this by changing from point to point to a non-broadcast environment and specify all of your neighbors Router IDs' : R1 (S0) R2(BRI0) R9(S0) and R8(BRI0) on each of the routers. -Original Message- From: Chuck Larrieu [mailto:[EMAIL PROTECTED]] Sent: Mon 2/4/2002 8:33 PM To: [EMAIL PROTECTED] Cc: Subject: Re: OSPF DR problem [7:34379] Cil, I drew this one out a little differently just to put a fresh perspective on it. Without seeing the requirements of the particular practice lab you are using, it's hard to say why you were seeing or not seeing what you did. area 0 -- || R1R2 || frame relay area 1 ISDN area 1 || R9R8 || -- - area 2 The discontiguous area 1's are irrelevant unless there is overlapping addressing. The area 2 is placed the way it is in order to force the creation of a virtual link - common in practice labs and study materials, as all us CCIE candidates know full well ;- I am inferring from other comments in other posts that you needed to use the IP ospf priority command on the R2 ethernet because the requirement is that R1 is the DR in area 0. So, given what I see ( not knowing the particulars of your addressing and various other things, there is no good reason why R9 and R8 should not see the ethernet network that is area 0. Along the trail of broken things, I have sometimes run across bizarre issues which are solved only by reloading routers. My humble pod of 2501's running enterprise 12.1.11 code sometimes have bizarre problems. I have a theory that these bloatware images just barely operate within the confined spaces of 16 megs of DRAM and sometimes you have to clear it out. I have had bizarre things happen when configuring and unconfiguring various routing protocols and features. Sometimes, admittedly, mistakes happen when you are tired, and you can't see straight to correct errors you have made. But other times, reloads have made magic happen. I am at the point where I am thinking about backloading to an IOS build that takes less space, just to see if the occasional weirdness disappears. Again, based upon what I have seen throughout this thread, and given that your areas and other configurations are correct, I see no reason why the area 0 network should not be visible from R9 and R8. Chuck PS as has been discussed here and elsewhere many a time, good practice and good design have little in common with the CCIE Lab ;- PPS which practice lab are you looking at? I have NLI, IPExpert, and SolutionLabs at my disposal. Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Remember, I think from a design point of view. I say for some reason there's an Area 2 because I think it's a bad design not because I was surprised to see it there in the show output. ;-) But thanks for replying, because it made me question my expectations. Here's what part of the network design looks like: ---R2---Area-1-ISDNR8---Area-1-Ethernet | Area 0 | Ethernet | | ---R1---Area-1-Frame Relay---R9---Area-2-Ethernet When I did a show ip route on R9 and R8 I thought I would see the Ethernet LAN in Area 0. That was not a logical expectatio
