Article

avatar

GNS3 Lab Exercise: Load Sharing Lab Scenario

Written by irom from http:// on November 9th, 2011 | 5 Comments

Scenario: R0 is connected to R1, R2 and R3 through DS3 (or OC3). Additionally R1, R2 And R3 are connected by Metro-Ethernet (simulated by SW1). All interfaces are in EIGRP 1. In case DS3 R0-R1 is broken traffic from R0 (source 100.100.100.100) to R1 (destination 1.1.1.1) should be shared between remaining two DS3s:

1) 1:1, traffic equally distributed between R0-R2 and R0-R3

2) 1:2, twice as much traffic on R0-R2 as on R0-R3

Traffic distribution has to be proven by test with ICMP traffic

Routers Used: Cisco 3640

IOS: c3640-ik9o3s-mz.124-25b, (C3640-IK9O3S-M), Version 12.4(25)

Feature of Topology: EIGRP Metric Weights, EIGRP unequal cost load balancing

Download GNS3 files: http://www.uploadhookup.com/index.php/files/get/luHPhnCS40/load-sharing.zip plus setup vlan 100 as shown below:

SW1#vlan database
SW1(vlan)#vlan 100
VLAN 100 added:
Name: VLAN0100
SW1(vlan)#apply
APPLY completed.
SW1(vlan)#exit
APPLY completed.

Solution:

1) 1:1, traffic equally distributed between R0-R2 and R0-R3
If DS3 between R0-R1 has not be broken traffic would go through this link

R0#sh ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via “eigrp 1″, distance 90, metric 2297856, type internal
Redistributing via eigrp 1
Last update from 10.1.1.1 on Serial1/1, 00:05:49 ago
Routing Descriptor Blocks:
* 10.1.1.1, from 10.1.1.1, 00:05:49 ago, via Serial1/1
Route metric is 2297856, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

But the scenario says that DS3 R0-R1 is broken:

R0#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R0(config)#int s1/1
R0(config-if)#sh
R0(config-if)#
*Mar 1 00:18:54.611: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Serial1/1) is down: interface down
*Mar 1 00:18:56.487: %LINK-5-CHANGED: Interface Serial1/1, changed state to administratively down
*Mar 1 00:18:57.487: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1, changed state to down

Traffic is momentarily distributed between R0-R2 and R0-R3 DS3s (metric 2300416)

R0#sh ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via “eigrp 1″, distance 90, metric 2300416, type internal
Redistributing via eigrp 1
Last update from 10.3.3.3 on Serial1/3, 00:00:28 ago
Routing Descriptor Blocks:
10.3.3.3, from 10.3.3.3, 00:00:28 ago, via Serial1/3
Route metric is 2300416, traffic share count is 1
Total delay is 25100 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
* 10.2.2.2, from 10.2.2.2, 00:00:28 ago, via Serial1/2
Route metric is 2300416, traffic share count is 1
Total delay is 25100 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2

As you can see traffic is distributed equally between R2 and R3 (traffic share count is 1). In order to test it let’s configure access list on input s1/0 interfaces of R2 and R3

access-list 100 permit icmp any host 1.1.1.1 log
access-list 100 permit ip any any
interface Serial1/0
ip address 10.3.3.3 255.255.255.0
ip access-group 100 in

Let’s ping from R0 to 1.1.1.1 (ping 1.1.1.1 repeat 300) and display traffic count on R2 and R3 (don’t forget to do ‘clear access-list counters’ on R2 and R3):

R2#sh ip access-lists 100 | inc icmp
Extended IP access list 100
10 permit icmp any host 1.1.1.1 log (300 matches)

R3#sh ip access-lists 100 | inc icmp
Extended IP access list 100
10 permit icmp any host 1.1.1.1 log

Traffic is not distributed, goes only through one DS3. Why is that? The reason is that traffic is CEF cached on R0 and by default distribution is per-destination.

R0(config-if)#ip load-sharing ?
per-destination Deterministic distribution
per-packet Random distribution

According to Cisco per-packet load balancing allows the router to send data packets over successive equal-cost paths without regard to individual destination hosts or user sessions. Path utilization is good, but packets destined for a given destination host might take different paths and might arrive out of order (could be very risky, not all application like it) . Per-destination load balancing allows the router to use multiple, equal-cost paths to achieve load sharing. Packets for a given source-destination host pair are guaranteed to take the same path, even if multiple, equal-cost paths are available. Traffic for different source-destination host pairs tend to take different paths. So let’s change default distribution to per-packet and switch-off CEF caching on R0 interfaces S1/2 and S1/3:

R0#sh run int s1/2
interface Serial1/2
ip address 10.2.2.100 255.255.255.0
ip load-sharing per-packet
no ip route-cache cef
no ip route-cache

R0#sh run int s1/3
interface Serial1/3
ip address 10.3.3.100 255.255.255.0
ip load-sharing per-packet
no ip route-cache cef
no ip route-cache

After ‘clear access-list counters’ do ‘ping 1.1.1.1 repeat 300′ on R0:

R2#sh ip access-lists 100 | inc icmp
Extended IP access list 100
10 permit icmp any host 1.1.1.1 log (150 matches)

R3#sh ip access-lists 100 | inc icmp
Extended IP access list 100
10 permit icmp any host 1.1.1.1 log (150 matches)

Bingo !

2) 1:2, twice as much traffic on R0-R2 comparing to R0-R3
Traffic distribution depends on metrics. In the first scenario traffic is distributed equally because metric on both links is the same (2300416). By default metric is calculated using bandwidth and delay (could include also load and reliability).

metric=k1*bandwidth + k3*delay, if k2 & k4 are zero ( k1=k2=1)

To make this task easier I will configure all routers so that only delay is used in the composite metric calculation (will use command ‘metric weights tos k1 k2 k3 k4 k5′)

R0,R1,R2and R3 (the metric must much on all routers in order for EIGRP adjacency to form) :

router eigrp 1
metric weights 0 0 0 1 0 0

On R0
R0#sh ip prot | inc weight
EIGRP metric weight K1=0, K2=0, K3=1, K4=0, K5=0

R0#sh ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via “eigrp 1″, distance 90, metric 642560, type internal
Redistributing via eigrp 1
Last update from 10.3.3.3 on Serial1/3, 00:00:00 ago
Routing Descriptor Blocks:
* 10.3.3.3, from 10.3.3.3, 00:00:00 ago, via Serial1/3
Route metric is 642560, traffic share count is 1
Total delay is 25100 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
10.2.2.2, from 10.2.2.2, 00:00:00 ago, via Serial1/2
Route metric is 642560, traffic share count is 1
Total delay is 25100 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2

Delay is 10s of microseconds scaled by 256, so if delay is 25100, metric=2510 * 256=642560
In order to have twice as much traffic between R0-R2 the metric on S1/2 should be 642560/2=321280. To get this metric delay has to be changed to 745, because:

642560/2=321280=(x+510) x256 -> x=745

Total delay is 25100, with 20000 on R0-R2, see below

R0#sh int s1/2 | inc DLY
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

So after changing delay on R0-R2 to 745 the new metric will be:

metric=(745+510)*256=321280 and new delay=12550

Variance has to be configured to any value as long as the link metric times the variance is greater than the total composite metric
On R0 configure the following:

interface Serial1/2
ip address 10.2.2.100 255.255.255.0
ip load-sharing per-packet
no ip route-cache cef
no ip route-cache
delay 745
router eigrp 1
variance 123

See how the traffic is distributed:

R0#sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 1″, distance 90, metric 321280, type internal
Redistributing via eigrp 1
Last update from 10.3.3.3 on Serial1/3, 00:02:00 ago
Routing Descriptor Blocks:
10.3.3.3, from 10.3.3.3, 00:02:00 ago, via Serial1/3
Route metric is 642560, traffic share count is 1
Total delay is 25100 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
* 10.2.2.2, from 10.2.2.2, 00:02:00 ago, via Serial1/2
Route metric is 321280, traffic share count is 2
Total delay is 12550 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2

As we can see below twice as much traffic went through R2 (clear counters and ‘ping 1.1.1.1 repeat 300′ from R0):

R0#ping 1.1.1.1 repeat 300
Type escape sequence to abort.
Sending 300, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (300/300), round-trip min/avg/max = 4/12/80 ms

R3#sh ip access-lists 100 | inc icmp
Extended IP access list 100
10 permit icmp any host 1.1.1.1 log (100 matches)

R2#sh ip access-lists 100 | inc icmp
Extended IP access list 100
10 permit icmp any host 1.1.1.1 log (200 matches)

Load sharing could be also achieved with OSPF (by default it supports four equal cost paths to a destination – use the maximum-paths command under OSPF). OSPF allows only equal cost load balancing

31,574 views

Tags: ,

5 Responses to “GNS3 Lab Exercise: Load Sharing Lab Scenario”

  1. avatar alex_c

    Excellent lab, very demanding, excellent explained, and extremely practical
     

  2. avatar Pablo

    Web page at "uploadhook.com" is not accesible.
    May anybody upload and give an alternative download link.
    Regards

  3. avatar cumberland hotel londres

    If you would like to grow your experience only keep visiting this web site and be updated with the most up-to-date news posted here.|

  4. avatar Software for Quibids

    This may be the earliest time I have commented here and I should say you give genuine, and quality information for bloggers! Great job.

  5. avatar Dot

    Remember you are wanting to ‘weave’ your content together into the overall fabric of your platform in a way that makes sense and is also of interest to visitors. He’s bound to be making thousands of dollars each day by harnessing the power of just a fraction of these followers.



Subscribe To GNS3-Labs

Subscribe to GNS3 Labs :: Cisco Router Simulator Network Topologies


Show Love!

If you would like to donate for the time it takes to do all of this, feel free to use the link below. Thank you in advance for any contribution you make :)

Categories