I know, that my question is like a "first 2 weeks of CCNA training", but I'm a little bit confused and trying to find th optimal solution.
take a look at the picture
it's quite simple OSPF routing domain with 3 Areas. Let say we'd like to reach a network 10.62.10/24 (on the right side on the picture) from the router PE-69 (on the left side)
on the first glance one would say the traffic should go PE-69 --> P-69 --> PE-621
but in the reality the traffic goes PE-69 --> P-228 -->P-69 --> PE-621, which is not optimal and one hope longer.
I understand why: in short the router PE-69 sees the OSPF information from both P-228 and P-69 router, but P-228 announce the smaller metric (41) for the subnet as P-69 does (101), because P-228 get the information via Area0 but for P-69 it a directly connected Area and according the OSPF rule it should use the "intra-area" path first.
The question is, how should I change the topology in order the get optimal traffic flow? Of cource I could set the OSPF cost on the link PE-69 --- P-228 to let say 100, but then all subnets connected to P-228 to a non-Area0 will be follow the sub-optimal path from PE-69 via P-69 and not directly.
the preferd way to 10.62.10/24 from PE-69 is PE-69 --> P-69 --> PE-621
the preferd way to 10.22.8.0/24 from PE-69 is PE-69 --> P-228
Red links are "WAN" links (because the price is per megabyte on those links) and the black are normal LAN. And the goal is to avoid an unnecessary traffic on the red links.
if we look now at the routing path from PE-69 to the sunmet 10.22.8.0/24 (connected to P-228) we see that this path is sub-optinal as wel, it's going the way PE-69 --> P-69 --> P-228, but I'd prefer it will go direclty to P-228.
Kishore Chennupati wrote:
shoudnt the traffic go PE-69->P69->P621-->PE621 and the total metric would be 22??. Hope my calc is correct. its 3.00am ad my vision is a bit blurred.
How about you lower the cost from 100 to say 10 between P69 and PE621 to achieve what you want?
the P-69 is sending the traffic to 10.62.10/24 directly to PE-621, because a router tries to send the traffic directly into the connected Area if possible, and not via the Area0.
if I change the he cost from 100 to say 10 between P69 and PE621 then I need to change the costs overall in Area0, because the link between P69 and PE621 should be only use as failover with the primary link via P-621.
Sorry for the late reply. Been a bit occupied with some other stufff. so coming to your post
"if we look now at the routing path from PE-69 to the sunmet 10.22.8.0/24 (connected to P-228) we see that this path is sub-optinal as wel, it's going the way PE-69 --> P-69 --> P-228, but I'd prefer it will go direclty to P-228."
This is because the cost between Pe69 and PE228 is 30 and the cost via P69 is 21. Increase the cost between Pe69 and P69 to 10 and then it should solve the suboptimal path.
Now, when making changes on the metric in mutliple ospf areas, we have to be very careful about the ramifications as it might fix one and break anothe hence careful desigining should be done.
coming to your original post. I rather create a GRE tunnel between PE69 and PE621 and use the tunnel source as the interface between PE69 and P69 for the traffic destined to 10.62.1.0. This would meann you dont have to muck with the costs in your network.
Idon't think the GRE tunnel is a good option - the problems with MTU and fragmentations will be arised for sure, and the GRE could lead to much more sub-optimal routing, because a router can see only a cost of the "logical" GRE path.
increasing the cost between P-69 and PE-69 to 10, will solve the sub-optimal routing to 10.22.8.0/24,
but the routing to 10.62.1.0/24 will be still sub-optinal.
If I correctly understand the problem - the suboptimal routing appears because of the fact that the routers P-228 and P-69 (the ABR's for the Area 22) see different OSPF information, because P-228 doesn't have an interface in Area11. And such kind of problem is quite difficult to solve just by changing the costs of interfaces.
I remember I've met somewhere in Cisco books the explanation of simular case, but I don't remember exactly where it was and what kind of recomendation was suggested.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...