I have a few questions about the OSPF topology attached. Please comment/suggest on questions in seperate comments so that I can rate them individually.
1) Dont see R5, R2 and R4 in attached topology diagram, this is about R1 and R3. R1's loopback interface has an ip of 172.16.8.193/27. I did not issue bandwidth command in interfaces (for testing purposes), so all serial and frame-relay connections between R1 and R3 has a cost of 64.
Under these circumstances, R3 does not do equal cost load sharing. Only 1 entry for 172.16.8.193/29 appears in route table, which is via frame-relay. But if I establish a virtual-link and Area 1 becomes transit area, equal cost balancing occurs. But in fact, I have a valid OSPF relation over Point-To-Point link as described behaviour in below question. Can you please explain this and normal behaviour in this scenario?
2) Dont see R5, R2 and R4 in attached topology diagram, this is about R1 and R3. R3's loopback interface has an ip of 172.16.8.193/29. I did not issue bandwidth command in interfaces (for testing purposes), so all serial and frame-relay connections between R1 and R3 has a cost of 64. There is no virtual link configured
Under these circumstances, R3 has an interface in Area 0 to operate in OSPF correctly. For testing purposes, I removed the loopback 172.16.8.193/27, from R1 in posted diagram and added it to R3 (So L0/0 of R3 belongs to area 0 temporarily, unlike the diagram). Then I started pinging loopback interface of R3 from R1. Then I disabled ser1/0 interface of R3, which is the frame-relay interface that connects R3 to backbone area. Ping was not successfull, untill the dead time expired. After a lot of lost pings and reached dead time, pings came back, pings are successfull. How? R3 neither has an interface in Area 0 nor Area 1 is a transit area! When I issue âsh ip ospfâ in R3, I see âArea BACKBONE(0) (Inactive)â. And in route table of R3, I see 172.16.8.193/27 marked as IA (Inter Area)? Is it treating Area 1 as Backbone area when its interface in Area 0 is failed? Can you please explain this and normal behaviour in this scenario?
3) Dont see R5, R2 and R1 in attached topology diagram, this is about R3 and R4. F0/0 of R3 has an ip of 172.16.10.1/25, and L0 of R3 has an ip of 172.16.10.129/25. R4's loopback interfaces, which belongs to Area 3 are 172.16.11.1/25 and 172.16.11.129/25
Under these circumstances, I apply âarea 2 range 172.16.10.0 255.255.255.0â command in R3, then R1 gets the summarized one single route, thats fine. As you can see, R4 does not have an interface in Area 0, and we have to configure a virtual-link for area 3 connectivity. When I apply virtaul link and Area 2 becomes transit area, R1 gets Area 3 routes fine, but Area 2 routes, which is now a transit area, are all displayed without being summarized. Both summarized and not-summarized routes of Area 2 appear in route table of R1. Can you please explain this and normal behaviour in this scenario?
Any comments appreciated!
Alright, this is bringing back memories of IE preparation days. Let's see if I can take a stab at your question(s).
""this is about R1 and R3. R1's loopback interface has an ip of 172.16.8.193/27. I did not issue bandwidth command in interfaces (for testing purposes), so all serial and frame-relay connections between R1 and R3 has a cost of 64.
Under these circumstances, R3 does not do equal cost load sharing. Only 1 entry for 172.16.8.193/29 appears in route table, which is via frame-relay.""
This is normal OSPF behavior. OSPF would always choose an intra-area route over an inter-area route. Even if you make the cost lower via the p-t-p link it would still choose the frame relay.
""But if I establish a virtual-link and Area 1 becomes transit area, equal cost balancing occurs.""
Virtual link extends area 0 scope via the transit area 1 and thus R1's loopback appears as intra-area route in R3 and hence, R3 picks both routes for load balancing (equal-cost).
I am going to have step away for a few minutes. Shall respond to your other questions a little later if no one had responded by then.
I believe that Sundar has answered the first one perfectly, as for the second one, i believe this RFC has all your answers, you need to understand the ABR behavior and operation, specially in Cisco's implementation with all the recent modifications, in your case you have no active backbone connection, but the router will consider all the summary LSAs from all the attached areas, thats why the route will be received however no active backbone connection exists.
Hi Sundar and Mohammed,
Thanks for your participation guys, really revealed a lot in my mind.
Now by Sundar's comment, I modified my "Inter Area" understanding as "Any route !including routes belong to backbone area!, learned from an ABR". I thought R3 would know that the route learned over Area 1, belongs to Backbone area since it has an interface in Backbone Area, and would treat it as Intra Area.
By Mohammed's comment, I learned that an ABR does not have to have an interfcae in Backbone Area as described in RFC. So if I remove Area 2 from R3, R3 will still be an ABR since it has an interface in Area 0 and in Area 1. And when s1/0 int of R3 goes down, its connection to Area 0 will be lost and R3 will lose its ABR title since it has interface in only one Area, and will not be able to learn any routes correct?
Waiting comments on Q3 also. Thanks!
You are very welcomed, and to make my point clear, here you are my labing for OSPF ABR behavior:
(Area6) R6 <--(VLAN56-Area56)--> R5 <--(VLAN45-Area45)--> R4 (Area4)
. Without any interface configured in Area0 on any router, no interArea LSAs are exchanged.
. With loopback0 configured in Area0 on all the routers (but still no Area0 Adjacency - Partitioned backbone - no active backbone connection), each router will advertise its direct connceted LSAs to its neighbors over any attached area, but won't relay any LSAs from a neighbor to the other neighbor - Area0 LSAs will be also exchanged as InterArea routes since there is no adjacency in Area0 between all the routers.
. With virtual-link configured between the three routers (the backbone is not Partitioned anymore - all routers have active backbone connection) the LSAs will be exchanged normally between all the routers (and now the Area0 LSAs are exchanged as IntraArea routes).
Mohammed's response is accurate about ABR status of R3 even when no active backbone connection exists. R3 continues to remain an ABR even when it has no connection to the backbone. You can verify this by issuing the command 'show ip ospf border-routers' in R1. Area 0 becomes partioned after R3 loses it connection to the backbone.
You would need a virtual link through area 1 for only one of two reasons. Load balance traffic between R1 & R3 for any networks behind those routers. When area 0 becomes partitioned any area other than area 1 wouldn't be reachable if no virtual link exists via area 1.
Please allow me to welcome you back, i haven't noticed that you have left the forum for a while, as i my self disappeared for a while for completing my CCIE. Welcome back.
You are very welcomed.
Thanks, after struggling for around a year and a half to accomplish my CCIE i thought life would get easier, but after getting my number, people around me treats me with the concept of with great power comes great responsibilities :)
Thanks for the insight, especially for your every second on the lab you prepared and attached Mohammed. I will return to my lab asap and work on ABRs by help of your directions, then will again steal your valuable time with some questions.
Also any comments of you guys is greatly appreciated in the following question of mine.
Lab is OK now, but one thing is still a mystery.
In router 3, I have the following command for area 2 summarization
area 2 range 172.16.10.0 255.255.255.0
And R1 has the following route in its table
O IA 172.16.10.0/24 [110/65] via 172.16.8.251, 00:00:53, Serial1/0
But as I issue the following in R3 to make Area 2 a transit area and let R4 advertise Area 3 routes to OSPF domain,
area 2 virtual-link routeridofR4
and in R4
area 2 virtual-link routeridofR3
Area 3 is advertised fine but route table of R1 changes as following
O IA 172.16.10.0/25 [110/65] via 172.16.8.251, 00:00:53, Serial1/
O IA 172.16.10.128/25 [110/65] via 172.16.8.251, 00:00:53, Serial1/0
O IA 172.16.10.0/24 [110/65] via 172.16.8.251, 00:00:53, Serial1/0
It gets both summary address and not summarized address. What is the problem here? Is this the default behaviour? Transit areas can not be summarized?
I don't have access to my lab gear at this time to test. However, I believe you would have to summarize the area 2 routes in R4 as well to suppress the specific routes. Use the same 'area 2 range 172.16.10.0 255.255.255.0' and in R4 and see if that takes care of the specific routes.
BTW, these are very good questions.
Agree with Sundar, this is indeed a very good lab. And also agree with him regarding the area range issue, after you've configured the virtual-link between R3 and R4, R4 is now an active backbone ABR router (since it now has an adjacency in Area0), adding the area range command on R4 should address you issue.
That makes sense, it worked! Thanks guys.
And one last question, I am redistributing RIP into OSPF with a summary address of 192.168.4.0/22 with External type 1 metric. All fine, other routers see that summary route with correct metric.
As you know, "O" appears next to the summary Null0 interface in R1, that states this is an OSPF route. And when I redistribute OSPF routes into RIP, R5 also sees that summary route! I think split-horizon has nothing to do here, is this the default behaviour and my only way for preventing this, is applying a distribution-list in RIP to outbound of R1 that denies 192.168.4.0/22 and permits the rest?
You are very welcomed. As for your question, you have 2 options, the first is as you said, doing route filtering for RIP routes going from R1 to R5 (since the null route is installed into R1 routing table as OSPF route "O" and thus will be redistributed into RIP and will reach R5), your other option is to use "no discard-route external" under the ospf process on R1 to prevent the creation of the null route in the first place.
OSPF creates a null route when a route is summarized to prevent routing loops and to black hole traffic for a destination for which a specific route doesn't exist from the summary address range. As Mohammed said you can disable the route from added by using the syntax 'no discard-route external' under the OSPF process in R1 as your topology doesn't seem to indicate any potential routing loop possibilities. Alternatively, you can use distribute list to filter the routes from being advertised out from R1 or R5 from accepting it.
Thanks guys, this was just like I have thought.
Further news form my OSPF lab :)
I learned that an ABR can not advertise IA routes (Type 3 LSAs) when it doesnt have an interface in backbone area, but this does not prevent it from receiving routes, which means an ABR doesnt have to have an int in backbone area. Thats fine and tested this in my lab by shutting down int ser1/0 of R3. When I issued "sh ip ospf" Area 0 was stated as (INACTIVE), then checked R1's route table that Area 2's routes were not there. All perfect!
But here is something new. I shut int ser1/0 of R1 and following happens
*"sh ip ospf" states Area0 as inactive in R1, although f0/0 is also a member of Area 0, so it still has an interface in Backbone although s1/0 is shut. And it can advertise IA routes to R3 just fine. So why does it state Area 0 as inactive?
*When R1's s1/0 is shut, R3 lost its connectivity, but since R3's s1/0 is not shut, it is considered that R3 has still got an interface in backbone which we call this "partitioned backbone" right?. And thats why it still can advertise Area 2 routes that R1 has Area 2 routes in its route table over ser1/1, which makes sense. But the issue is, R3 does advertise Area 2 routes(172.16.10.0/24) to R1, but does not advertise Area 0 routes (172.16.8.0/24) to R4. R4 doesnt have routes for R1. Long story short, when I start a ping from R4 to R1's f0/0, and shut int ser1/0 in R1, network does not converge, ping timeouts forever. Why?
And I removed OSPF and applied EIGRP between R1 and R3 in same network topology, to observe behaviours. And here are my observations and assumptions, please make corrections if I stated any behaviour wrong.
There is no virtual link between R1 and R3 over Area 1. Ping from R3 f0/0 to R1 f0/0 started, then int s1/0 of R1 is shut. R1 calculated its new route table immediately (Amended its routes to Area 2 that has the f0/0 of R3, as over s1/1). But R3 keeps routes over s1/0 untill the down time expiers, because it can not get the triggered update about s1/0 that is flooded by DR, since it doesnt have an interface within same area, although it is not reachable. As down time expires, R3 recalculates routes, places new routes as over s1/1, then Ping starts working! But a long downtime!
This time, there is a virtual link between R3 and R1 over Area 1. So if a network change occurs, DR will flood this change to all DRothers, just like R3 over virtual link. Ping from R3 f0/0 to R1 f0/0 started, then int s1/0 of R1 is shut. R1 changed recalculated its route table, flooded triggered update (Is this LSA 2?), R3 got that update over virtual link and recalculated its routes. And only 1 or 2 pings lost. Very short downtime!
No area term in EIGRP, 172.16.8.0/24-172.16.9.252/30 and 172.16.10.0/24 are defined in concerned router within AS 100. All routes appear as D, which is all fine, and pings are successfull. BUT!
Ping from R3 f0/0 to R1 f0/0 started, then int s1/0 of R1 is shut. And?? I just get the exact behaviour that I observed in OSPF Situation 1! EIGRP waits for hold down timer to expire! What happened to triggered update! It is always told that EIGRP converges faster than OSPF! Any idea?
I know its been a long long topic, but as much as I go deeper, it gets darker and darker :). Your comments doesnt have to solve anything above. Even thoughts, redirections, workarounds will be helpful and greatly appreciated.
Sorry, things got a little busy around here and couldn't respond sooner. Even now I am in the middle of something I mayn't be able to respond to all your queries at this time. I shall however get to every one of them as and when I free up. I am sure Mohammed might want to chime in on this topic as well.
""There is no virtual link between R1 and R3 over Area 1. Ping from R3 f0/0 to R1 f0/0 started, then int s1/0 of R1 is shut. R1 calculated its new route table immediately (Amended its routes to Area 2 that has the f0/0 of R3, as over s1/1). But R3 keeps routes over s1/0 untill the down time expiers, because it can not get the triggered update about s1/0 that is flooded by DR, since it doesnt have an interface within same area, although it is not reachable. As down time expires, R3 recalculates routes, places new routes as over s1/1, then Ping starts working! But a long downtime!""
This is how OSPF is supposed to work. If the interface goes down OSPF would purge the neighbor and recalculate the routes. It looks like the Serial interface on R3 stayed up and it had to wait till the hold timer expired (40 seconds) before it started recalculating the routes. Most of the time a link failure would result in interface to go down and you won't have any problems with re-convergence. They may be certain situations where the interface mayn't go down when the link isn't capable of passing data and that would require some configuration tweaking for faster re-convergence. You can set the hello/hold timer to very minimal and the re-convergence would be much quicker. I believe OSPF now offers msec timers for faster reconvergence.
""This time, there is a virtual link between R3 and R1 over Area 1. So if a network change occurs, DR will flood this change to all DRothers, just like R3 over virtual link. Ping from R3 f0/0 to R1 f0/0 started, then int s1/0 of R1 is shut. R1 changed recalculated its route table, flooded triggered update (Is this LSA 2?), R3 got that update over virtual link and recalculated its routes. And only 1 or 2 pings lost. Very short downtime!""
This behavior makes sense as well. When the Serial interface was shut on R1 it triggered an update to all it's neighbors the Serial link is down. R3, on receiving the area 0 LSA over the virtual link, would have purged the OSPF neighbor because it was told by the neighbor it's lost connectivity over the Serial link. Without the virtual link R3 would have waited for the hold timer to expire and SPF would have been executed to recalculate the routes.
As we told you earlier, virtual link extends area 0 over the transit area. R1 wouldn't have been able to send the area 0 LSA over area 1 without a virtual link and it did after the virtual link was created. As you may already know all routers in the same area has to have an identical database. When the virtual link was established naturally R3's area 0 database would have reflected the same as R1's area 0 database. Despite the fact R3's Serial interface stayed up it wouldn't have waited for the hold timer to expire because area 0 database wouldn't have had an LSA for the Serial link and thus no neighbor - resulting in quick OSPF re-convergence :-)
Sorry, got a little busy my self, but i can see that Sundar has given tremendous valuable resolutions, agree with him on every aspect and really enjoyed his resolutions, as for OSPF fast re-convergence (sub-second convergence), you can use OSPF Fast Hellos, with this feature the hello packets are sent in less than 1 second intervals, using the command "ip ospf dead-interval minimal hello-multiplier x", where x is the multiplier, meaning that if x is 3, this will result in 3 hellos sent in 1 second, and obviously the hold-time is one second, and thus if at least 1 hello isn't received in 1 second, via 3 trials, then the neighbor is considered down.
Thanks again for marvellous explainations guys. And sorry if I rushed you.
So you agree with my observations and the way I explain them. That means I learned correctly.
From my researches, decreasing Hello timers, especially on WANs like my topology, is not a good practice, in terms of bandwidth utilization, and CPU utilization.
The sentence that lighted the bulb in my head instantaneously is, "Most of the time a link failure would result in interface to go down and you won't have any problems with re-convergence"
So the reason why router waits for Dead timer to expire is the Up interface although the link protocol is down, and couldnt get triggered updates since no interface left within same area correct? Can you give me some examples of links which the failure results with two end interfaces go down? For example frame-relay in my lab (dynamips) didnt behave that way.
But in EIGRP, there is no IA situation, so as the s1/0 in R1 is down, triggered update should flood from s1/1 of R1 to R3, and R3 should have purged the Successor route over its interface in frame cloud (s1/0) and inject the Feasible Successor which is over s1/1 instantaneously, instead waiting for dead timer to expire correct?
Cant explain with words how much your comments are appreciated, please comment in your free times, I dont like the feeling that I interrupt you in your busy times. Thanks again.