Hi Everyone!
The Challenge
People tend to underestimate the important of IGP routing features in modern network. So here is a small challenge scenario for you to practice OSPF traffic engineering. Take a look at the diagram below for information on the topology and link bandwidth. You may assume that every router has a loopback interface for network testing and OSPF router-id selection.
There is a large cloud of media servers behind R4, and the users behind R1 need to use full 300Mbps of bandwidth when downloading files off the servers. The network is running single-area OSPF for IP routing. Ensure you can accomplish the above goal without using MPLS Traffic Engineering or Policy Based Routing. You are allowed to create additional logical interfaces, but the routing protocol, OSPF areas, physical links and their characteristics should remain unchanged. Keep the amount of changes to minimum and do not introduce new IP addresses.
The first person to provide a working solution will receive 100 rack rental tokens from our partner company GradedLabs. Please use your valid e-mail address when posting a comment, so we can locate your INE account.
UPD
OK I forgot to rule out the “route-via” option
Try solving the task without relying on any “policy-based” routing decisions.
The winner is: Antonie Henning (http://21500.net). Ivan Pepelnjak helped finding a logical “loophole” in my scenario by pointing to the “route-via” option available with GRE tunnels and correctly stating there should be 6 end-to-end tunnels to implement proper load-balancing. Hans Verkerk was close in his idea, but used static routing which was slightly against the rules and not as elegant as Antonie’s solution. Chris Stos-Gale and Nitzan Tzelniker came with the correct solution as well, but Antonie completed the challenge ahead of them. Thanks to everyone for participating in the challenge, it’s been fun!
The Solution:
The problem is that there are three paths with varying minimum bandwidth values (50, 100 and 150, totaling to 300Mbps). Since OSPF does not support unequal-cost load-balancing, it is somewhat challenging to fully use the available bandwidth. There was a lot of ideas posted in the comments, and they mainly fall in three main categories:
1) Modify OSPF costs to create three equal cost paths from R4 to R1. This will result in slow (50Mbps) link oversaturation. Another variation was using three tunnel interfaces between R1/R4 with the same ECMP logic. This results in the same problem.
2) Create six tunnels between R4 and R1 and configure the network so that 3 tunnels go across the fastest path, 2 tunnels take the medium path and one tunnel take the slowest path. This is somewhat similar to MPLS TE. To steer the tunnels you may use either static routes or the “route-via” option (Thanks to Ivan Pepelnjak to pointing me that!!). This solution would work, but violate the “updated” requirement not to use any “policy-based” routing decision, relying purely on OSPF path selection.
3) The solution that I had on mind was splitting the links connecting R4 to it’s neighbors into “sub-channels” proportional to the bandwidth assigned to a given path:
The link labels represent OSPF costs. You only need to split the links at R4, as this is the “source” of the traffic flows. Link splitting could be done in two ways: using logical virtual circuits (e.g. FR PVCs or Ethernet VLANs/VCs) or by using IP tunnels. You will only need to run the IP tunnels between R4 and the directly attached routers, disabling OSPF on the physical link and enabling it on the tunnels. Sample output at R4 for R1′s prefix:
I would like to thank everyone who participated in the “challenge”, I read all your responses but had to stop commenting when I found the right solution. I hope you enjoyed that little scenario as much as I did. Personally, I have some incline toward the “traditional” traffic engineering solutions based on pure IGP metric manipulation. Even though the solution presented does not scale in the real world, where you may resort to a different option (e.g. end-to-end route-via tunnels), it perfectly illustrates the little hacks you can do to a link-state IGP to break the default “ECMP paradigm”.
The Challenge
People tend to underestimate the important of IGP routing features in modern network. So here is a small challenge scenario for you to practice OSPF traffic engineering. Take a look at the diagram below for information on the topology and link bandwidth. You may assume that every router has a loopback interface for network testing and OSPF router-id selection.
There is a large cloud of media servers behind R4, and the users behind R1 need to use full 300Mbps of bandwidth when downloading files off the servers. The network is running single-area OSPF for IP routing. Ensure you can accomplish the above goal without using MPLS Traffic Engineering or Policy Based Routing. You are allowed to create additional logical interfaces, but the routing protocol, OSPF areas, physical links and their characteristics should remain unchanged. Keep the amount of changes to minimum and do not introduce new IP addresses.
The first person to provide a working solution will receive 100 rack rental tokens from our partner company GradedLabs. Please use your valid e-mail address when posting a comment, so we can locate your INE account.
UPD
OK I forgot to rule out the “route-via” option
Try solving the task without relying on any “policy-based” routing decisions.The winner is: Antonie Henning (http://21500.net). Ivan Pepelnjak helped finding a logical “loophole” in my scenario by pointing to the “route-via” option available with GRE tunnels and correctly stating there should be 6 end-to-end tunnels to implement proper load-balancing. Hans Verkerk was close in his idea, but used static routing which was slightly against the rules and not as elegant as Antonie’s solution. Chris Stos-Gale and Nitzan Tzelniker came with the correct solution as well, but Antonie completed the challenge ahead of them. Thanks to everyone for participating in the challenge, it’s been fun!
The Solution:
The problem is that there are three paths with varying minimum bandwidth values (50, 100 and 150, totaling to 300Mbps). Since OSPF does not support unequal-cost load-balancing, it is somewhat challenging to fully use the available bandwidth. There was a lot of ideas posted in the comments, and they mainly fall in three main categories:
1) Modify OSPF costs to create three equal cost paths from R4 to R1. This will result in slow (50Mbps) link oversaturation. Another variation was using three tunnel interfaces between R1/R4 with the same ECMP logic. This results in the same problem.
2) Create six tunnels between R4 and R1 and configure the network so that 3 tunnels go across the fastest path, 2 tunnels take the medium path and one tunnel take the slowest path. This is somewhat similar to MPLS TE. To steer the tunnels you may use either static routes or the “route-via” option (Thanks to Ivan Pepelnjak to pointing me that!!). This solution would work, but violate the “updated” requirement not to use any “policy-based” routing decision, relying purely on OSPF path selection.
3) The solution that I had on mind was splitting the links connecting R4 to it’s neighbors into “sub-channels” proportional to the bandwidth assigned to a given path:
The link labels represent OSPF costs. You only need to split the links at R4, as this is the “source” of the traffic flows. Link splitting could be done in two ways: using logical virtual circuits (e.g. FR PVCs or Ethernet VLANs/VCs) or by using IP tunnels. You will only need to run the IP tunnels between R4 and the directly attached routers, disabling OSPF on the physical link and enabling it on the tunnels. Sample output at R4 for R1′s prefix:
R4#show ip route 10.0.1.1
Routing entry for 10.0.1.1/32
Known via "ospf 1", distance 110, metric 4, type intra area
Last update from 10.0.3.3 on Tunnel341, 00:46:50 ago
Routing Descriptor Blocks:
* 10.0.45.5, from 10.0.1.1, 00:46:50 ago, via Serial0/0/0.45
Route metric is 4, traffic share count is 1
10.0.3.3, from 10.0.1.1, 00:46:50 ago, via Tunnel340
Route metric is 4, traffic share count is 1
10.0.3.3, from 10.0.1.1, 00:46:50 ago, via Tunnel341
Route metric is 4, traffic share count is 1
10.0.1.1, from 10.0.1.1, 00:46:50 ago, via Tunnel142
Route metric is 4, traffic share count is 1
10.0.1.1, from 10.0.1.1, 00:46:50 ago, via Tunnel140
Route metric is 4, traffic share count is 1
10.0.1.1, from 10.0.1.1, 00:46:50 ago, via Tunnel141
Route metric is 4, traffic share count is 1SummaryI would like to thank everyone who participated in the “challenge”, I read all your responses but had to stop commenting when I found the right solution. I hope you enjoyed that little scenario as much as I did. Personally, I have some incline toward the “traditional” traffic engineering solutions based on pure IGP metric manipulation. Even though the solution presented does not scale in the real world, where you may resort to a different option (e.g. end-to-end route-via tunnels), it perfectly illustrates the little hacks you can do to a link-state IGP to break the default “ECMP paradigm”.
0 comments:
Post a Comment