HOW TO: EIGRP unequal cost load balancing traffic-engineering

LinkedIn
Facebook
Facebook
Google+
http://netfixpro.com/eigrp-unequal-cost-load-balancing-traffic-engineering/
RSS
Follow by Email

We often come across the requirement where we have to perform the load sharing in dual-homed network scenario. This article demonstrates the traffic engineering with EIGRP using unequal cost load balancing where one path requires more traffic share than the other.

To best describe, I am using the simple topology as shown in the above-mentioned diagram. All 4 routers are running EIGRP AS 100. They all are connected and configured with IP scheme as shown in the diagram. On the right side,  as you can see R3 has a loopback interface that is configured with network 10.3.3.3/32 also. Right now R1 can reach 10.3.3.3/32 via either R2 or R4 because of ECMP. Here are the initial configuration of all routers as explained.

Click here →

to view initial configuration for this lab.

R1

interface Ethernet0/0
 ip address 10.1.12.1 255.255.255.0
 no shut
end
!
interface Ethernet0/1
 ip address 10.1.14.1 255.255.255.0
 no shut
end
!
interface loopback0
 ip address 10.1.1.1 255.255.255.255
end
!
router eigrp 100
 network 10.1.12.0 255.255.255.0
 network 10.1.14.0 255.255.255.0
 network 10.1.1.1 255.255.255.255
 variance 10
end

R2

interface Ethernet0/0
 ip address 10.1.12.2 255.255.255.0
 no shut
end
!
interface Ethernet0/1
 ip address 10.1.23.2 255.255.255.0
 no shut
end
!
interface loopback0
 ip address 10.2.2.2 255.255.255.255
end
!
router eigrp 100
 network 10.1.12.0 255.255.255.0
 network 10.1.23.0 255.255.255.0
 network 10.2.2.2 255.255.255.255
end

R3

interface Ethernet0/0
 ip address 10.1.34.3 255.255.255.0
 no shut
end
!
interface Ethernet0/1
 ip address 10.1.23.3 255.255.255.0
 no shut
end
!
interface loopback0
 ip address 10.3.3.3 255.255.255.255
end
!
router eigrp 100
 network 10.1.34.0 255.255.255.0
 network 10.1.23.0 255.255.255.0
 network 10.3.3.3 255.255.255.255
end

R4

interface Ethernet0/0
 ip address 10.1.34.4 255.255.255.0
 no shut
end
!
interface Ethernet0/1
 ip address 10.1.14.4 255.255.255.0
 no shut
end
!
interface loopback0
 ip address 10.4.4.4 255.255.255.255
end
!
router eigrp 100
 network 10.1.34.0 255.255.255.0
 network 10.1.23.0 255.255.255.0
 network 10.4.4.4 255.255.255.255
end
NOTE:
In order to perform unequal cost load sharing, the alternate path/s have to meet the EIGRP feasibility condition first. EIGRP uses variance command to perform unequal cost load sharing. The variance command works as a multiplier. e.g. In order to load-balance, the feasible successor requires a lower feasible distance than the successor X multiplier(variance).
Case Study

Now let’s configure the network so when R1 tries to reach out to R3’s networks, it takes the path through R2, 5 times and the path through R4, 2 times. In other words, configure traffic share count of 5 to 2 through R2 and R4 respectively on R1.

Let’s find out first, how R1 is routing for 10.3.3.3/32 network as of now. R1 is doing an ECMP through R2 and R4 and traffic share count is 1.

R1#show ip route 10.3.3.3
Routing entry for 10.3.3.3/32
 Known via "eigrp 100", distance 90, metric 435200, type internal
 Redistributing via eigrp 100
 Last update from 10.1.12.2 on Ethernet0/0, 00:02:25 ago
 Routing Descriptor Blocks:
 10.1.12.2, from 10.1.12.2, 00:02:25 ago, via Ethernet0/0
 Route metric is 435200, traffic share count is 1
 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2
 * 10.1.14.4, from 10.1.14.4, 00:02:25 ago, via Ethernet0/1
 Route metric is 435200, traffic share count is 1
 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2

As we can see from below output right now, R1’s feasible distance to reach R3’s loopback is 435200 and advertised distance is 409600.

R1#sh ip eigrp topology 10.3.3.3/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.1.1.1) for 10.3.3.3/32
 State is Passive, Query origin flag is 1, 2 Successor(s), FD is 435200
 Descriptor Blocks:
 10.1.14.4 (Ethernet0/1), from 10.1.14.4, Send flag is 0x0
 Composite metric is (435200/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 7000 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 10.3.3.3
 10.1.12.2 (Ethernet0/0), from 10.1.12.2, Send flag is 0x0
 Composite metric is (435200/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 7000 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 10.3.3.3

We already have a variance of 10 configured on R1 as part of the initial configuration and now we have a requirement of configuring traffic share count as 5 to 2 through R2 and R4 respectively on R1. That means we have to add an additional metric offset (either through delay or bandwidth) on the interface Ethernet0/1 of an R1 (path through the R4). But how do we find out how much delay or bandwidth we will need to change? Well, the trick is here.

Let’s find out the new offset that we need to apply in order to influence the traffic share.

  • 5 to 2 traffic share count means overall multiplier is 5/2 = 2.5
  • Multiply the current feasible-distance with the multiplier i.e. 435200*2.5 = 1088000
  • Now, subtract the current feasible-distance value from new multiplied value i.e. 1088000-435200 = 652800, That is your offset that needs to be added to make the total offset of 1088000 from 435200.

Apply the offset-list as

R1(config-router)#offset-list 0 in 652800 Eth0/1

Let’s look at the topology detail again on R1.

R1#show ip eigrp topology 10.3.3.3/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.1.1.1) for 10.3.3.3/32
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 435200
 Descriptor Blocks:
 10.1.12.2 (Ethernet0/0), from 10.1.12.2, Send flag is 0x0
 Composite metric is (435200/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 7000 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 10.3.3.3
 10.1.14.4 (Ethernet0/1), from 10.1.14.4, Send flag is 0x0
 Composite metric is (1088000/1062400), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 32500 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 10.3.3.3

As you can see from the output above, the path through R4 is not feasible anymore after applying an offset-list. But don’t worry, we can use this offset-list trick to find out total delay to obtain the desired traffic count.

NOTE:
In older IOS code, offset-list value applies to the feasible distance directly, not to advertised distance.
But in newer IOS code, offset-list values applies to the advertised distance and hence to the feasible distance also.

Let’s rollback the offset-list so we can make traffic share count even for now.Now we know what is the total delay required to influence 5 to 2 traffic share count. As you can see, R1’s total delay to reach R3’s loopback through R4 is 32500 microseconds. That is the overall delay we will need to make traffic share count of 5 to 2.

R1(config)#router eigrp 100
R1(config-router)#no offset-list 0 in 652800 Eth0/1

After the roll-back, the total delay is 7000 microseconds as we have seen on the previous output..Let’s find out the interface delay of Eth0/1.

R1#sh int Eth0/1 | i DLY
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,

That means, the total of 6000 microseconds delay is coming from the neighbor since the interface has 1000 microseconds of delay already. Hence, In order to obtain the total delay of 32500 microseconds, we will need to add 32500-6000=26500 microseconds of delay on interface Eth0/1.

R1(config)#int Eth0/1
R1(config-subif)#delay 2650

R1#sh int Eth0/1 | i DLY
 MTU 1500 bytes, BW 10000 Kbit/sec, DLY 26500 usec,

NOTE: Delays are added in tens of microseconds under the interface.

Let’s verify the topology and traffic share count now.

R1#show ip eigrp topology 10.3.3.3/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.1.1.1) for 10.3.3.3/32
 State is Passive, Query origin flag is 1, 2 Successor(s), FD is 435200
 Descriptor Blocks:
 10.1.14.4 (Ethernet0/1), from 10.1.14.4, Send flag is 0x0
 Composite metric is (1088000/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 32500 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 10.3.3.3
 10.1.12.2 (Ethernet0/0), from 10.1.12.2, Send flag is 0x0
 Composite metric is (435200/409600), route is Internal
 Vector metric:
 Minimum bandwidth is 10000 Kbit
 Total delay is 7000 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 10.3.3.3

R1#show ip route 10.3.3.3
Routing entry for 10.3.3.3/32
 Known via "eigrp 100", distance 90, metric 435200, type internal
 Redistributing via eigrp 100
 Last update from 10.1.12.2 on Ethernet0/0, 00:01:01 ago
 Routing Descriptor Blocks:
 * 10.1.12.2, from 10.1.12.2, 00:01:01 ago, via Ethernet0/0
 Route metric is 435200, traffic share count is 5
 Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2
 10.1.14.4, from 10.1.14.4, 00:01:01 ago, via Ethernet0/1
 Route metric is 1088000, traffic share count is 2
 Total delay is 32500 microseconds, minimum bandwidth is 10000 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 2

As you can see from the above-mentioned output, R1 is using the path through R2 as the primary path and has a traffic share count of 5 while the path through R4 is being used as an alternate path and has a traffic share count of 2 as desired.

Summary
  • An offset-list trick can be used to find out the total delay to obtain the desired traffic share count.
  • Altering delay achieves the desired traffic engineering while keeping the alternate route/s as feasible successor/s.

I hope you enjoyed this article. Please feel free leave a comment or a feedback.

LinkedIn
Facebook
Facebook
Google+
http://netfixpro.com/eigrp-unequal-cost-load-balancing-traffic-engineering/
RSS
Follow by Email

Ashutosh Patel

Ashutosh Patel is the Author and editor of netfixpro.com. He currently works as a Network Security Architect. Follow him on following social media to know more about him.

Leave a Reply

Your email address will not be published. Required fields are marked *

Show Buttons
Hide Buttons

Enjoy this article? Please spread the word :)