Wednesday, March 08, 2006
IS-IS neighbor problem. (Question #31)
Consider two routers connected back-to-back to each other via their serial interfaces. Here is the config from the two routers
Router1
Router2
The two routers fail to form an IS-IS neighbor adjacency. What is the problem with the configuration?
Router1
interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
interface Serial2
ip address 10.10.10.1 255.255.255.0
ip router isis
!
router isis 1
net 49.0100.1111.1111.1111.00
passive-interface Loopback0
Router2
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Serial2
ip address 10.10.10.2 255.255.255.0
ip router isis
!
router isis 1
net 49.0100.2222.2222.2222.00
passive-interface Loopback0
The two routers fail to form an IS-IS neighbor adjacency. What is the problem with the configuration?
Understanding OSPF Default Route Generation.
Here are some facts about default route generation with OSPF -
n nssa default-information originate .
At first glance, all these minor differences in the details of how the default route generation happens with OSPF is maddening. The method behind this seeming madness is not apparent. Why all these differences? When I first encountered these facts, I realized that there was no way I was going to be able to memorize these without reasoning out the story behind these particular choices.
Why were these choices made? Why couldn't the OSPF standard simply use the same type of LSAs for propagation of the default routes regardless of the area into which the route was being propagated? That the default route generation happens by default for stubby and
totally stubby areas makes perfect sense since routing information is withheld from routers in such areas precisely because we want them to treat the ABR as a default gateway. So, then why couldn't the same be done for NSSA and totally stubby NSSA areas which are similar in spirit to the stubby and totally stubby areas? Why did Cisco need to have two different commands for generating the default routes for cases (1) and (3)?
Let's try and reason through these facts to understand why things are as they are. Default routes are not generated by default into normal areas. That makes sense because normal areas have complete routing information and so default routes are likely not even necessary. When configured to do so, the default route is propagated as a type-5 LSA. That seems to be reasonable too because the default route is probably coming from a static default route which is after all considered as a routing process itself. So, generating a type-5 external is fine.
In stubby and totally stubby areas, the default routes are generated by default by the ABR and no configuration is necessary. Routing information is withheld from the routers in stubby and totally stubby areas. Also, there are no exits from a stubby and totally stubby areas other than via an ABR since ASBRs are not allowed in these areas. So, the stub area routers will always definitely need a default route to get out of the area. Since such is the case, it makes sense for the ABR to automatically generate a default route with no configuration being needed. Also, the default route is propagated as a type-3 LSA because type-5 LSAs are not allowed in stub areas. It was a bit surprising to me that even the totally stub receives a type-3 LSA for the default route because by definition totally stubby areas do not receive type-3 LSAs. However, since totally stubby areas are really just a Cisco extension to the stub area, the prohibition of type-3 LSAs from totally stubby areas is not a RFC dictat. So, it looks like ABRs for totally stubby areas filter out all type-3 LSAs but do generate a type-3 LSA for the default route.
Now with this line of reasoning, why type-7 LSAs are used for case(3) with NSSA and totally stubby NSSA areas becomes clear. That is obviously because type-5 LSAs are not allowed in these areas but type-7 external LSAs are. But why don't the NSSA ABRs generate the
default route automatically like they do for stubby and totally stubby areas? Well, the only difference between stubby and NSSA areas is that the NSSA areas can have ASBRs in them. And therein lies the cause for the lack of automatic default route generation. Traffic from NSSA area routers can exit the area either through an ABR or through an ASBR. Unlike the stubby area case, there is more than one exit path from the area! The ABR cannot simply assume that he is the default route of the area and so it would not be right to do automatic default route generation. The user would have to specifically specify if the default exit from a NSSA is via an ABR or an ASBR and so some configuration is needed.
OK, so the choices start to make sense now. But why did Cisco need two different kinds of configuration commands for default route generation? Well, let's handle this by assuming that the commands could be the same -- default-information originate -- for both cases (1) and (3). Let's then consider the case of an ABR that is ABR for both an NSSA area and a normal area. The command would generate default routes into both areas. What if you now wanted to generate a default route into the NSSA area but not into the normal area? Oops, it looks like I need to be able to specify the area in the default-information originate command. Well, that is exactly what the area n nssa default-information originate command allows you to do. The alert reader might now say that one could get rid of the default-information originate command and always use a command that specifies the area into which the default route generation needs to be done. That could well be the case, but now practical issues intervene. What must have happened is that the default-information originate command must have been implemented first before there was even NSSA support and the area n nssa default-information originate must have come later when that need was identified. But you can't just go remove old commands willy-nilly because users learn to use them and so that remains.
I think all the original questions that the details of OSPF default route generation threw up have now been answered. What was done was that a narrative of sorts was created such that the seemingly strange behavior now seems to be quite reasonable indeed. Once this reasoning is internalized, remembering this behavior will become much easier. This is the smart memorization technique that I referred to a couple of posts ago.
There is a good article on Cisco's website on this topic that explains the hows of default route generation with OSPF. Hopefully this blog post gave you the whys so that OSPF default route generation becomes clearer.
- Default routes are not generated by default into normal areas. When configured to do so, the ABR generates type-5 LSAs for these default routes.
- Default routes are generated by default into stub and totally stubby areas. The ABR generates type-3 LSAs in this case.
- Default routes not generated by default into NSSA and totally stubby NSSA areas. For this case, the default routes are propagated as type-7 LSAs.
At first glance, all these minor differences in the details of how the default route generation happens with OSPF is maddening. The method behind this seeming madness is not apparent. Why all these differences? When I first encountered these facts, I realized that there was no way I was going to be able to memorize these without reasoning out the story behind these particular choices.
Why were these choices made? Why couldn't the OSPF standard simply use the same type of LSAs for propagation of the default routes regardless of the area into which the route was being propagated? That the default route generation happens by default for stubby and
totally stubby areas makes perfect sense since routing information is withheld from routers in such areas precisely because we want them to treat the ABR as a default gateway. So, then why couldn't the same be done for NSSA and totally stubby NSSA areas which are similar in spirit to the stubby and totally stubby areas? Why did Cisco need to have two different commands for generating the default routes for cases (1) and (3)?
Let's try and reason through these facts to understand why things are as they are. Default routes are not generated by default into normal areas. That makes sense because normal areas have complete routing information and so default routes are likely not even necessary. When configured to do so, the default route is propagated as a type-5 LSA. That seems to be reasonable too because the default route is probably coming from a static default route which is after all considered as a routing process itself. So, generating a type-5 external is fine.
In stubby and totally stubby areas, the default routes are generated by default by the ABR and no configuration is necessary. Routing information is withheld from the routers in stubby and totally stubby areas. Also, there are no exits from a stubby and totally stubby areas other than via an ABR since ASBRs are not allowed in these areas. So, the stub area routers will always definitely need a default route to get out of the area. Since such is the case, it makes sense for the ABR to automatically generate a default route with no configuration being needed. Also, the default route is propagated as a type-3 LSA because type-5 LSAs are not allowed in stub areas. It was a bit surprising to me that even the totally stub receives a type-3 LSA for the default route because by definition totally stubby areas do not receive type-3 LSAs. However, since totally stubby areas are really just a Cisco extension to the stub area, the prohibition of type-3 LSAs from totally stubby areas is not a RFC dictat. So, it looks like ABRs for totally stubby areas filter out all type-3 LSAs but do generate a type-3 LSA for the default route.
Now with this line of reasoning, why type-7 LSAs are used for case(3) with NSSA and totally stubby NSSA areas becomes clear. That is obviously because type-5 LSAs are not allowed in these areas but type-7 external LSAs are. But why don't the NSSA ABRs generate the
default route automatically like they do for stubby and totally stubby areas? Well, the only difference between stubby and NSSA areas is that the NSSA areas can have ASBRs in them. And therein lies the cause for the lack of automatic default route generation. Traffic from NSSA area routers can exit the area either through an ABR or through an ASBR. Unlike the stubby area case, there is more than one exit path from the area! The ABR cannot simply assume that he is the default route of the area and so it would not be right to do automatic default route generation. The user would have to specifically specify if the default exit from a NSSA is via an ABR or an ASBR and so some configuration is needed.
OK, so the choices start to make sense now. But why did Cisco need two different kinds of configuration commands for default route generation? Well, let's handle this by assuming that the commands could be the same -- default-information originate -- for both cases (1) and (3). Let's then consider the case of an ABR that is ABR for both an NSSA area and a normal area. The command would generate default routes into both areas. What if you now wanted to generate a default route into the NSSA area but not into the normal area? Oops, it looks like I need to be able to specify the area in the default-information originate command.
I think all the original questions that the details of OSPF default route generation threw up have now been answered. What was done was that a narrative of sorts was created such that the seemingly strange behavior now seems to be quite reasonable indeed. Once this reasoning is internalized, remembering this behavior will become much easier. This is the smart memorization technique that I referred to a couple of posts ago.
There is a good article on Cisco's website on this topic that explains the hows of default route generation with OSPF. Hopefully this blog post gave you the whys so that OSPF default route generation becomes clearer.
