cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9171
Views
15
Helpful
8
Replies

OSPF Route Manipulation

jpdeboer1
Level 1
Level 1

Hi,

 

I have a question about route manipulation in OSPF. See below info / sample topology.

 

- The connection between router A and B is a Gigabit Ethernet Connection and is in Area 0 of OSPF 93 process.

- Between Router A and C i have a IPSEC over GRE tunnel. Same for the connection between Router B and C. These tunnel interfaces are in Area 6 of OSPF process 93.

- When i do sh ip route 10.93.108.1 on Router A (With Tunnel connection shut down between Router A and C ) i get below info.

Routing entry for 10.93.108.0/22
Known via "ospf 93", distance 110, metric 22, type extern 1
Last update from 1.1.1.42 on GigabitEthernet0/2, 00:01:02 ago
Routing Descriptor Blocks:
* 1.1.1.42, from 10.93.108.1, 00:01:02 ago, via GigabitEthernet0/2
Route metric is 22, traffic share count is 1

- Now when i do this with tunnel connection between Router A and C unshut i get below information.

Routing entry for 10.93.108.0/22
Known via "ospf 93", distance 110, metric 25, type extern 1
Last update from 10.93.69.65 on Tunnel20, 00:00:03 ago
Routing Descriptor Blocks:
* 10.93.69.65, from 10.93.108.1, 00:00:03 ago, via Tunnel20
Route metric is 25, traffic share count is 1

- Both routes are externall type one routes, this i configured under the OSPF process configuration on Router C.

O E1 10.93.108.0/22 [110/22] via 1.1.1.42, 00:00:03, GigabitEthernet0/2

O E1 10.93.108.0/22 [110/25] via 10.93.69.65, 00:01:29, Tunnel20

 

sample topo.jpeg

 

Now what i would like to accomplish is that traffic towards 10.93.108.0/22 will always flow over the tunnel between Router B and Router C. So if traffic for example enters Router A then Router A should forward this to Router B and Router B will send it to Router C. 

 

This is currently not the case, when the tunnel between router A and C is enabled Router A prefers to send it to Router C over the tunnel even though the metric for the route to Router B is lower 22 in this case.

 

Now the route selection is as below

 

1. intra-routes over

2, inter-routes over ( Both routes learned are inter area routes)

3. E1 over (Both Routes learned are E1 Routes)

4. E2 over

5. N1 (Not applicable)

6. N2 (Not applicable)

 

So then it would come to metric size wright? Which can be manipulated by using ospf cost on the interface. Which i do. As far as i know the router will only choose the closest egress point if metric is also a tie. Which is not true in this case. 

 

I also tried doing this with E2 routes, According to some posts E2 routes do not count ospf cost per interface (Which is not entirely true) so that will always be a tie metric of 20 is the default. I cannot manipulate this under the OSPF configuration as these routes come from one router. I could do this when the same route was announced from 2 different routers. 

 

I am testing this in Virl, could it be that this is a bug in Cisco Virl or am i missing something?

 

Thanks in advance!

 

Br,

 

JP

1 Accepted Solution

Accepted Solutions

pigallo
Cisco Employee
Cisco Employee

Hello,

 

i would like to expand a little bit more the explanation here since the previous answer was incomplete.

Unfortunately with external route preference, Ospf is little bit more complicated than what we can imagine.
The problem is that in such cases Ospf behavior is also platform dependent, therefore you can see behaviors that in other circumstances you didn't notice and all this can make situation even more complex and frustrating.
By default IOS, for external route preference, follows RFC1583. So as you correctly were expecting, you should be able to manipulate your path by just tweaking the interface costs.
This is not true for example for Nexus technology which is fully compliant with RFC2328 and this is a very important concept to keep in mind when we migrate mixed topologies with both platforms running together.(This is why i asked you in begin which platform you were running)..

With that being said though, in this case, we can enforce this logic for IOS just if we have different ASBRs announcing the same network through different inter/intra-area external prefix or the same ASBR announcing one network through different intra-area external or inter-area external prefix.

 

What this means is that if you already have, like in this case, an ASBR which is router C announcing external network via intra-area external path in area 6, router A cannot recurse also to router C by passing backbone area via router B, and then enter back again into area 6 to reach the same ASBR .

This because it would result in a control-plane loop since router A can natively reach the ASBR via its own area already.

Router A is the SPF root point for its own calculation for intra/inter area nodes.

When it is already in the same area of the destination node it cannot perform the recursion to the same node via another area. This simply is not admitted by Ospf (remember spf calculations are bounded within area domain only), since it is part of antiloop mechanism built in Ospf.


A complete different story would be if the same ASBR was connected to both the areas (0 and 6).

In this case router A will recurse to the ASBR through both the areas and only in that case the cost setting will result in a path manipulation.

Now, going back to your original problem, you can solve it in different ways. For example you could extend area 0 from B to C routers and play with costs on router A.
Or you could extend area 6 from router B to router A.
Or alternatively you could create two ospf process on router A and play with AD and enforcing path selection to reach the external route.

 

View solution in original post

8 Replies 8

pigallo
Cisco Employee
Cisco Employee

Hello,

 

in order to provide some help to you i need to know exactly area boundary within your diagram because from the draw it is not clear which link pertain to which area.

From what i see you have two areas: backbone + area 6, can you indicate which link belong to specific area ?
Second i need to know if you are using IOS and if it's IOS which release.

thank you

Hi,

 

Thanks for the reply.

 

Tunnel connection between Router A and Router C is in Area6. Tunnel connection between router B and Router C is in Area 6. Ethernet connection between Router A and Router B is in Area 0.

 

Yes, i am using IOS, version 15.6(2)T. This is a IOSv node as i am testing this in virl.

I simulated it with couple of different ways like changing ASE preference and link cost but being an intra-area (R3 to R1) route it will always be preferred over inter-area routes (R3 to R2 to R1 inter-area).

 

 

Kindest regards,

Uzzi 



Kindest regards,
Uzair
CCENT, CCNA (R&S), CCNP (R&S).

pigallo
Cisco Employee
Cisco Employee

Hello,

 

i would like to expand a little bit more the explanation here since the previous answer was incomplete.

Unfortunately with external route preference, Ospf is little bit more complicated than what we can imagine.
The problem is that in such cases Ospf behavior is also platform dependent, therefore you can see behaviors that in other circumstances you didn't notice and all this can make situation even more complex and frustrating.
By default IOS, for external route preference, follows RFC1583. So as you correctly were expecting, you should be able to manipulate your path by just tweaking the interface costs.
This is not true for example for Nexus technology which is fully compliant with RFC2328 and this is a very important concept to keep in mind when we migrate mixed topologies with both platforms running together.(This is why i asked you in begin which platform you were running)..

With that being said though, in this case, we can enforce this logic for IOS just if we have different ASBRs announcing the same network through different inter/intra-area external prefix or the same ASBR announcing one network through different intra-area external or inter-area external prefix.

 

What this means is that if you already have, like in this case, an ASBR which is router C announcing external network via intra-area external path in area 6, router A cannot recurse also to router C by passing backbone area via router B, and then enter back again into area 6 to reach the same ASBR .

This because it would result in a control-plane loop since router A can natively reach the ASBR via its own area already.

Router A is the SPF root point for its own calculation for intra/inter area nodes.

When it is already in the same area of the destination node it cannot perform the recursion to the same node via another area. This simply is not admitted by Ospf (remember spf calculations are bounded within area domain only), since it is part of antiloop mechanism built in Ospf.


A complete different story would be if the same ASBR was connected to both the areas (0 and 6).

In this case router A will recurse to the ASBR through both the areas and only in that case the cost setting will result in a path manipulation.

Now, going back to your original problem, you can solve it in different ways. For example you could extend area 0 from B to C routers and play with costs on router A.
Or you could extend area 6 from router B to router A.
Or alternatively you could create two ospf process on router A and play with AD and enforcing path selection to reach the external route.

 

Thank you both for the reply, but that's the problem, both are intra area routes according to the routing table (yeah i mixed that up in my original post).

Routes with a 0 are intra area routes, routes with 0 IA are inter area routes. So in both cases they are Intra-area routes and External type 1. So all this is a tie.

O E1 10.93.108.0/22 [110/22] via 1.1.1.42, 00:00:03, GigabitEthernet0/2
O E1 10.93.108.0/22 [110/25] via 10.93.69.65, 00:01:29, Tunnel20

So then it would boil down to metric which is not the same in this case. So does metric come after route selection point 6? Do you maybe have a more detailed route selection list ?
1. intra-routes over (Both routes learned are inter area routes)
2, inter-routes over
3. E1 over (Both Routes learned are E1 Routes)
4. E2 over
5. N1 (Not applicable)
6. N2 (Not applicable)

but like Pigallo explained "When it is already in the same area of the destination node it cannot perform the recursion to the same node via another area. This simply is not admitted by Ospf (remember spf calculations are bounded within area domain only), since it is part of antiloop mechanism built in Ospf.".

Thanks allot for this detailed explanation learned some more details about OSPF :).

I will extend Area 0 to Router C so i can manipulate the routing like i want.

 

Hi,

 

just a little clarification here:

O E1 / O E2 are external type 1 and type 2 LSAs. The "O" stands for Ospf route so in this case it is not a matter of define them as intra-area external or inter-area external because of the "O".

The definition is achieved in other terms:
It is an intra area external route when your root node resides in the same area where the ASBR that performs the redistribution belongs to.

And it is inter-area external when your root node resides in a different area than the one where the ASBR belongs too.

 

Bear in mind that in Ospf the only two certain rules about best path selection are as ospf RFC dictates:

1

Intra-area and inter-area paths are always preferred
                over AS external paths

2

Type 1 external paths are always preferred over type 2
                external paths.

In the middle of this there are so many exception and tiebreakers that you should learn step by step because they can come into play when you deploy Ospf networks. Not to mention different application of RFCs in multi vendor equipment.

Now the metric is a tie when you have an equal LSA type if and only if other previous check marks have been excluded. As you noticed in your scenario we had such an example of this because metric was a tie: We had both E1 routes.

But metric was not used as a discriminant in route selection.

Pigallo thanks again for this detailed explanation and your help in sorting this out!!

  There should be possible solution based on RFC 5185 (as far as I know minimum IOS version for implementation is 15.4.x) - link must be configured as point-to-point link and OSPF area need to be already configured on inetrface. After that you are adding second OSPF area on the same point-to-point link (command is ip ospf multi-area x). Idea is to enable both OSPF areas on point-to-point link so all three links will belong to the same area (and point-to-point link to area 0 of course), and then if you manipulate link cost you can do traffic engineering just based on lower cost intra area  path.

 

For more details please read OSPF with Multi-Area Adjacency Configuration Example.

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: