Solved: Ask the Expert: Open Shortest Path First (OSPF)

ciscomoderator · ‎06-14-2013

With Vignesh R. P.

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions to Cisco expert Vignesh R. P. about how to configure and troubleshoot Open Shortest Path First (OSPF)

Open Shortest Path First (OSPF) is classified as an Interior Gateway Protocol (IGP). This means that it distributes routing information between routers belonging to a single Autonomous System. The OSPF protocol is based on link-state or SPF technology. This is a departure from the Bellman-Ford base used by traditional TCP/IP internet routing protocols.

Vignesh R. P. is a customer support engineer in the Cisco High Touch Technical Support center in Bangalore, India, supporting Cisco's major service provider customers in routing and MPLS technologies. His areas of expertise include routing, switching, and MPLS. Previously at Cisco he worked as a network consulting engineer for enterprise customers. He has been in the networking industry for 8 years and holds CCIE certification in the Routing & Switching and Service Provider tracks.

Remember to use the rating system to let Vignesh know if you have received an adequate response.

Vignesh might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Network Infrastructure sub-community discussion forum shortly after the event. This event lasts through through June 28, 2013. Visit this forum often to view responses to your questions and the questions of other community members.

Peter Paluch · ‎06-22-2013

Hello Vignesh,

It is nice to meet you, and thank you immensely for hosting this Ask the Expert session!

I am having trouble understanding the true nature of the no capability transit command in Cisco's IOS. The command reference regarding the capability transit command states:

If you want to retain a traffic pattern through the virtual-link path, you can disable capability transit by entering the no capability transit command.

I do not see how this can happen, though. Please bear with me as I explain.

Assume a specific case of a partitioned backbone interconnected by a transit area, and I will borrow a topology from RFC 2328 (it's the Figure 17 in Section 16.3):

                      ........................ 
                      . Area 1 (transit)     .            + 
                      .                      .            | 
                      .      +---+1        1+---+100      | 
                      .      |RT2|----------|RT4|=========| 
                      .    1/+---+********* +---+         | 
                      .    /*******          .            | 
                      .  1/*Virtual          .            | 
                   1+---+/*  Link            .         Net|work 
             =======|RT1|*                   .            | N1 
                    +---+\                   .            | 
                      .   \                  .            | 
                      .    \                 .            | 
                      .    1\+---+1        1+---+20       | 
                      .      |RT3|----------|RT5|=========| 
                      .      +---+          +---+         | 
                      .                      .            | 
                      ........................            +

Here, assume that RT1, RT4, and RT5 are all ABRs between partitioned Area 0 and transit Area 1, and no capability transit is configured on them. Regardless of even the existence of a virtual link, both RT4 and RT5 will inject a LSA-3 describing the network N1 into Area 1. Before the virtual link is configured, routers RT2 and RT3 in Area 1 will converge on the path via RT5 based on the total cost. RT1 will, at this point, ignore LSA-3 from both RT4 and RT5 because it is an ABR, and ABRs process LSA-3 received in Area 0 only.

If a virtual link between RT1 and RT4 is configured, RT1's Area 0 link state database will claim that N1 is reachable via RT4. RT1 will therefore install a route to N1 via RT2, as RT2 is RT1's next hop towards RT4 as the other virtual link's end. However, to internal routers in Area 1, nothing changes with the creation of the virtual link. In particular, the LSA-3 originated by RT5 does not ever change, no better LSA-3 regarding N1 is ever advertised to Area 1, and RT2 will continue to route packets towards network N1 via RT1, while RT1 points to RT2 for the same network. Hence, a permanent routing loop is created.

So the claim about the no capability transit causing a transit area to carry transit traffic along the path of a virtual link is not generally true. In fact, with the no capability transit, the traffic not only follows a potentially worse path, it may actually get caught in a routing loop.

To me, the "optimization" step as described in RFC 2328 Section 16.3 is not just about improving existing paths, but actually about allowing ABRs to converge on transit paths using the same summary information that is used on internal routers in a transit area. Otherwise, one of the basic requirements for link-state routing protocols - that each router in an area computes the shortest paths using an identical link-state database - is not met, resulting into routing loops or traffic blackholing.

This leaves me wondering - if the use of no capability transit can result into creation of permanent routing loops, what is it good for?

I understand this post is overly long - but any ideas, corrections and explanations are most welcome!

Best regards,

Peter

View solution in original post

Peter Paluch · ‎06-24-2013

Hello Marwan,

Thank you for joining the discussion!

I believe the situation is slightly different from what you describe so let us gradually proceed over your post.

first the virtual link cost will be built based on the link its created over

This is absolutely true. Specifically in the topology I have posted, the cost of the virtual link will be 2 (note the '1' signs in the topology signifying the interface costs).

in your case the cost associated with RT1 advertisements to RT2 will be higher than with theLSAs advertised by RT4 and RT5

Quite correct. There will be 3 instances of LSA-3 in the Area 1 after the virtual link is configured, each of them originated by a different router. The costs as indicated in LSA-3 regarding the N1 network will be:

Originated by RT4: 100
Originated by RT5: 20
Originated by RT1: 100+2=102

RT2 will never select the summary LSAs advertised by RT1, only from RT4 and RT5

Yes, that is perfectly correct. So let's see what RT2 has at hand:

LSA-3 originated by RT4, total cost being 1+100=101
LSA-3 originated by RT5, total cost being 3+20=23
LSA-3 originated by RT1, total cost being 1+102=103

Obviously, from the RT2's viewpoint, the path through RT5 is the lowest cost path. Notice, however, that the shortest path from RT2 to RT5 includes RT1!

Now, RT1 is an ABR and because of no capability transit, it completely ignores any LSA-3 received from Area 1. The only information about the N1 network on RT1 is received via the virtual link towards RT4 in the form of LSA-1 and possibly LSA-2. So by the virtue of SPF computation in the Area 0, RT1 will conclude that N1 is reachable via the virtual link through RT4. During the routing table resolution on RT1, the path to RT4 will resolve through RT2. Now, what is the state of the routing tables?

RT1 believes that the best path to N1 is via RT4, and that recursively resolves into the path via RT2
RT2 believes that the best path to N1 is via RT5, and that recursively resolves into the path via RT1

And voila - here we have the routing loop.

without the transit capability the only and only path will be over the  virtual link because RT1 will ignore N1 LSA-3 from RT5 since its not  coming over area 0

This is what Area 0 link-state database tells RT1 about the N1 network. However, keep in mind that while Area 0 database says: "From RT1, go to RT4 and from there you can reach the N1", the jump between RT1 and RT4 is resolved within Area 1. There, the path from RT1 to RT4 leads via RT2. RT2 knows nothing about the virtual link - which exists as an unnumbered point-to-point link only in Area 0 - and it routes packets according to its own routing table that points towards RT5, back through RT1.

If you want to retain a traffic pattern through the virtual-link path, you can disable capability transit by entering the no capability transit command

This statement has never made sense to me. The virtual link, while created over a transit area, exists (i.e. is modeled) in Area 0 only. How can routers in a transit area know about any topological detail in Area 0? How can they know what path a virtual link follows so that the transit traffic can be carried over that path, too? The truth is - they can not - and they do not.

Best regards,

Peter

View solution in original post

Vignesh Rajendran Praveen · ‎06-25-2013

Hello Peter & Marwan,

I was actually able to reproduce the scenario in my lab and below are my observations.

When Transit Capability parameter is set to True on the ABRs:-

RT1 recieves a Type 1 LSA for N1 across the Virtual Link between RT1 & RT4 originated by RT4.

RT1 also recieves a Type 3 LSA for N1 originated by RT5. The other internal routers in Area 1 also recieve a Type 3 LSA for N1 originated by RT5.

The Type 3 LSA originated by RT5 has a better metric than the Type 1 LSA recieved on RT1 for network N1.

RFC 2328

16.3. Examining transit areas' summary-LSAs

        (4) Look up the routing table entry for the advertising router
            BR associated with the Area A. If it is unreachable, examine
            the next LSA. Otherwise, the cost to destination N is the
            sum of the cost in BR's Area A routing table entry and the
            cost advertised in the LSA. Call this cost IAC.

        (5) If this cost is less than the cost occurring in N's routing
            table entry, overwrite N's list of next hops with those used
            for BR, and set N's routing table cost to IAC. Else, if IAC
            is the same as N's current cost, add BR's list of next hops
            to N's list of next hops. In any case, the area associated
            with N's routing table entry must remain the backbone area,
            and the path type (either intra-area or inter-area) must
            also remain the same.

Based on the above points mentioned in the RFC under section 16.3, the Type 3 LSA is preferred on RT1 and the path via RT1-RT3-RT5 is chosen to reach the destination network N1.

When No Capability Transit is configured on the ABRs:-

RT1 recieves a Type 1 LSA for N1 across the Virtual Link between RT1 & RT4 originated by RT4.

RT1 also recieves a Type 3 LSA for N1 originated by RT5.

The Type 3 LSA has a better metric than the Type 1 LSA recieved on RT1.

Since the Transit Capability parameter has been disabled on the ABRs, RT1 prefers the Type1 LSA with R2 being the next hop. And as already explained by Peter in his previous post this leads to a permanent routing loop.

Based on the above two scenarios my observation is that the Virtual Links should have existed between RT1 - RT4 as well as RT1 - RT5. In simple words both the ABRs RT4 & RT5 should generate a Type 1 LSA for network N1 in order to avoid the routing loop. I believe since the usage of Virtual Links is not being encouraged much & that too the scenario we are discussing is a very rare corner case, it does not have a mention about it in the RFC nor the Drafts.

Kindly share your thoughts.

Thanks & Regards,

Vignesh R P

View solution in original post

Vignesh Rajendran Praveen · ‎06-27-2013

Hello Giuseppe,

I have attached my reply as a notepad file. Kindly refer the same.

Thanks & Regards,

Vignesh R P

View solution in original post

paul driver · ‎06-14-2013

Hello Vignesh

Can you explain when a type 4 lsa will becomes applicable - as I understand it - this lsa is advertised by the abr into a non backbone area to provide a next hop towards the asbr which is the advertising router of an external route.

Also in ospfv3 -

Can you explain lsa type 8 and 9

Res
Paul

Sent from Cisco Technical Support iPad App

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Vignesh Rajendran Praveen · ‎06-17-2013

Hello Paul,

Type 4 lsa is advertised by the ABR into area 0 to provide a next hop towards the asbr which is the advertising router of an external route.

Link LSA (Type 8):

===============

A router originates a separate Link LSA for each link it is attached to. These LSAs have link-local flooding scope and are never flooded beyond a link that they are associated with. These LSAs have three purposes:-
     - notify the link-local address of the router's interface to the routers attached to the link
     - inform other routers attached to the link of the list of IPv6 prefixes to associate with the link
     - allow the router to assert the collection of Option bits to associate with the Network LSA that will be originated for the link

The Link-State ID is set to the Interface ID of link of the originating router.

Intra-Area Prefix LSA (Type 9):

=========================

A router uses Intra-Area Prefix LSA to advertise IPv6 prefixes that are associated with
     a) the router itself
     b) an attached stub network segment
     c) an attached transit network segment

A router can originate multiple Intra-Area Prefix LSAs for each router or transit network; each LSA is distinguished by its Link State ID.

Thanks & Regards,

Vignesh R P

Prashant Sheshasayee · ‎06-19-2013

I have a query in EIGRP if I redistribute OSPF I don't get the redistributed output in show ip route why?I tried out many times.Could u suggest me.

Rolf Fischer · ‎06-19-2013

Prashant,

the first thing which crosses my mind is "incompatible metrics" but without knowing the details of your configuration, that's impossible to answer.

Could you please post the relevant part of your configuration?

I'd also suggest to move this posting into a Routing and Switching section (LAN or WAN).

Best regards

Rolf

Vignesh Rajendran Praveen · ‎06-19-2013

Hi Prashanth,

Kindly share the relevant configurations & the output of sh ip ro from the devices involved for me to help you.

Thanks & Regards,

Vignesh R P

yogeshdua · ‎06-20-2013

Hello Vignesh,

I have a issue regarding ospf in Mpls vpn.

My ques. is..

I want to seperate data traffic(10.10.84.0/24) and voice traffic(10.10.85.0/24) over two links running ospf as PE to CE routing protocol.

Both links are terminated to single ce router.

Is it possible to load balance traffic in ospf(PE-CE) mpls vpn.

Currently, i am having single instance of ospf in CE..so traffic is on single link.

i can do it by changing LP attribute of bGP in PE router..

BUT, i only to change configuration at CE router not PE..is it possible in ospf..????

Thanks in advance..

Vignesh Rajendran Praveen · ‎06-22-2013

Hello Yogesh,

I dont think it is possible to achieve without changing any configuration on the PE device.

Thanks & Regards,

Vignesh R P

Peter Paluch · ‎06-22-2013

Hello Vignesh,

It is nice to meet you, and thank you immensely for hosting this Ask the Expert session!

I am having trouble understanding the true nature of the no capability transit command in Cisco's IOS. The command reference regarding the capability transit command states:

If you want to retain a traffic pattern through the virtual-link path, you can disable capability transit by entering the no capability transit command.

I do not see how this can happen, though. Please bear with me as I explain.

Assume a specific case of a partitioned backbone interconnected by a transit area, and I will borrow a topology from RFC 2328 (it's the Figure 17 in Section 16.3):

                      ........................ 
                      . Area 1 (transit)     .            + 
                      .                      .            | 
                      .      +---+1        1+---+100      | 
                      .      |RT2|----------|RT4|=========| 
                      .    1/+---+********* +---+         | 
                      .    /*******          .            | 
                      .  1/*Virtual          .            | 
                   1+---+/*  Link            .         Net|work 
             =======|RT1|*                   .            | N1 
                    +---+\                   .            | 
                      .   \                  .            | 
                      .    \                 .            | 
                      .    1\+---+1        1+---+20       | 
                      .      |RT3|----------|RT5|=========| 
                      .      +---+          +---+         | 
                      .                      .            | 
                      ........................            +

Here, assume that RT1, RT4, and RT5 are all ABRs between partitioned Area 0 and transit Area 1, and no capability transit is configured on them. Regardless of even the existence of a virtual link, both RT4 and RT5 will inject a LSA-3 describing the network N1 into Area 1. Before the virtual link is configured, routers RT2 and RT3 in Area 1 will converge on the path via RT5 based on the total cost. RT1 will, at this point, ignore LSA-3 from both RT4 and RT5 because it is an ABR, and ABRs process LSA-3 received in Area 0 only.

If a virtual link between RT1 and RT4 is configured, RT1's Area 0 link state database will claim that N1 is reachable via RT4. RT1 will therefore install a route to N1 via RT2, as RT2 is RT1's next hop towards RT4 as the other virtual link's end. However, to internal routers in Area 1, nothing changes with the creation of the virtual link. In particular, the LSA-3 originated by RT5 does not ever change, no better LSA-3 regarding N1 is ever advertised to Area 1, and RT2 will continue to route packets towards network N1 via RT1, while RT1 points to RT2 for the same network. Hence, a permanent routing loop is created.

So the claim about the no capability transit causing a transit area to carry transit traffic along the path of a virtual link is not generally true. In fact, with the no capability transit, the traffic not only follows a potentially worse path, it may actually get caught in a routing loop.

To me, the "optimization" step as described in RFC 2328 Section 16.3 is not just about improving existing paths, but actually about allowing ABRs to converge on transit paths using the same summary information that is used on internal routers in a transit area. Otherwise, one of the basic requirements for link-state routing protocols - that each router in an area computes the shortest paths using an identical link-state database - is not met, resulting into routing loops or traffic blackholing.

This leaves me wondering - if the use of no capability transit can result into creation of permanent routing loops, what is it good for?

I understand this post is overly long - but any ideas, corrections and explanations are most welcome!

Best regards,

Peter

Vignesh Rajendran Praveen · ‎06-23-2013

Hello Peter,

I am currently researching on the same and would need some more time. I would post my response as soon as I arrive at an answer.

Thanks a lot for posting such a good question.

Thanks & Regards,

Vignesh R P

Marwan ALshawi · ‎06-24-2013

Hi Peter

looking at the topology there are couple of points I want to highlight

first the virtual link cost will be built based on the link its created over so in your case the cost associated with RT1 advertisements to RT2 will be higher than with theLSAs advertised by RT4 and RT5 because RT1 will advertises the cost of the virtual link in the summary LSAs and the virtual-link goes across RT2. Therefore, RT2 will never select the summary LSAs advertised by RT1, only from RT4 and RT5

secondly, after the creation of the virtual link area 1 is considered a transit area and the OSPF transit capability here will help RT1 to select the best ABR for LSAs on N1 based on metric so even there is no virtual link to RT5 but it will be selected as a next hope since the metric from RT5 is preferred

without the transit capability the only and only path will be over the virtual link because RT1 will ignore N1 LSA-3 from RT5 since its not coming over area 0

and thats why:

If you want to retain a traffic pattern through the virtual-link path, you can disable capability transit by entering the no capability transit command

also Vignesh can comment on this !

hope this help

Peter Paluch · ‎06-24-2013

Hello Marwan,

Thank you for joining the discussion!

I believe the situation is slightly different from what you describe so let us gradually proceed over your post.

first the virtual link cost will be built based on the link its created over

This is absolutely true. Specifically in the topology I have posted, the cost of the virtual link will be 2 (note the '1' signs in the topology signifying the interface costs).

in your case the cost associated with RT1 advertisements to RT2 will be higher than with theLSAs advertised by RT4 and RT5

Quite correct. There will be 3 instances of LSA-3 in the Area 1 after the virtual link is configured, each of them originated by a different router. The costs as indicated in LSA-3 regarding the N1 network will be:

Originated by RT4: 100
Originated by RT5: 20
Originated by RT1: 100+2=102

RT2 will never select the summary LSAs advertised by RT1, only from RT4 and RT5

Yes, that is perfectly correct. So let's see what RT2 has at hand:

LSA-3 originated by RT4, total cost being 1+100=101
LSA-3 originated by RT5, total cost being 3+20=23
LSA-3 originated by RT1, total cost being 1+102=103

Obviously, from the RT2's viewpoint, the path through RT5 is the lowest cost path. Notice, however, that the shortest path from RT2 to RT5 includes RT1!

Now, RT1 is an ABR and because of no capability transit, it completely ignores any LSA-3 received from Area 1. The only information about the N1 network on RT1 is received via the virtual link towards RT4 in the form of LSA-1 and possibly LSA-2. So by the virtue of SPF computation in the Area 0, RT1 will conclude that N1 is reachable via the virtual link through RT4. During the routing table resolution on RT1, the path to RT4 will resolve through RT2. Now, what is the state of the routing tables?

RT1 believes that the best path to N1 is via RT4, and that recursively resolves into the path via RT2
RT2 believes that the best path to N1 is via RT5, and that recursively resolves into the path via RT1

And voila - here we have the routing loop.

without the transit capability the only and only path will be over the  virtual link because RT1 will ignore N1 LSA-3 from RT5 since its not  coming over area 0

This is what Area 0 link-state database tells RT1 about the N1 network. However, keep in mind that while Area 0 database says: "From RT1, go to RT4 and from there you can reach the N1", the jump between RT1 and RT4 is resolved within Area 1. There, the path from RT1 to RT4 leads via RT2. RT2 knows nothing about the virtual link - which exists as an unnumbered point-to-point link only in Area 0 - and it routes packets according to its own routing table that points towards RT5, back through RT1.

If you want to retain a traffic pattern through the virtual-link path, you can disable capability transit by entering the no capability transit command

This statement has never made sense to me. The virtual link, while created over a transit area, exists (i.e. is modeled) in Area 0 only. How can routers in a transit area know about any topological detail in Area 0? How can they know what path a virtual link follows so that the transit traffic can be carried over that path, too? The truth is - they can not - and they do not.

Best regards,

Peter

Marwan ALshawi · ‎06-24-2013

Hi Peter

Ospf transit area is a non-backbone area that allows this area to transport traffic for other areas (either zero or non-zero). Per the OSPF definition, a transit area is the area that has a virtual-link connecting two or more ABRs attached to this area.

In your topology this apply to RT1 not RT2

Because once you have the vlink Area 1 is now considered transit

Wiehter to enforce the traffic Togo over the virtual link or use the ABR with lowest cost this depends on the activation of transit capability of ospfv2

Not sure if it's make senesce to you now !

Peter Paluch · ‎06-24-2013

Hi Marwan,

I believe we are running in circles. I have twice in detail and step-by-step explained how the routing loop will be created with the no capability transit configured - first in my original post, then in my response to your post. If I am wrong then at least one of the steps I have described can be proved incorrect. If you believe I am wrong then please try to find the exact spot where I am making a mistaken judgement. Please be as specific as possible. So far, I am afraid you have not followed my explanations carefully.

And by the way - I am not just theoretizing here. I have configured the exact topology in the exhibit with the no capability transit on routers running 12.4(15)T13 Advanced IP Services - and I have indeed created the routing loop just as I described earlier. I am truly talking about a real blackhole/routing loop occurence, not about a hypothetical scenario.

Best regards,

Peter

Marwan ALshawi · ‎06-24-2013

Peter I am in agreement with you :)

I think I need to lab it as well very interesting point